Portable Native Client | Hacker News Reader

Portable Native Client

blog.chromium.org

179 pointsamaks135 comments

http://en.wikipedia.org/wiki/ActiveX - 1996 is knocking… yes, I know - it's very, very different this time, but still can't help remembering the horrors of ActiveX :)

PS. From Wikipedia article: In principle it [ActiveX] is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator

PPS. I'm not really trying to compare them, just pointing out that obsessive idea to run Photoshop in browser is almost as old as browser and photoshop themselves. And so is the idea for a grand platform that will let us "write once, run everywhere". Uncountable attempts were made, yet somehow they all fall short of expectations. Is the idea itself flawed? Perhaps we have different operating systems for a reason?..

The comparison to Active X, while intriguing, is really a Mu since the two are so different (http://eli.thegreenplace.net/2012/11/10/native-client-vs-act...)

Consider this as a much safer Multi-OS native application development platform that happens to work in a browser and all (ok, most of) your fears will disappear.

I agree, that's the thought I've had ever since learning of native client. These native, proprietary solutions have come and gone, such will be the fate of NaCl. As far as I'm concerned the future of high-performance webbrowser computing will be javascript-based through projects like asm.js or remote cloud architectures (eg https://brendaneich.com/2013/05/today-i-saw-the-future/)

How is this proprietary? Isnt there an open spec?

Is there a PNaCl spec or just Google's implementation?

There's a bitcode spec [1] and a stability doc [2].

1 - https://developers.google.com/native-client/dev/reference/pn...

2 - http://www.chromium.org/nativeclient/pnacl/stability-of-the-...

The code is open source, but last I heard there isn't a spec for PNaCl/PPAPI.

The PNaCl ABI is defined here: https://developers.google.com/native-client/dev/reference/pn... - and it's definitely a work in progress we'll be trying to improve. As for Pepper, it's also all documented here and below - https://developers.google.com/native-client/dev/pepperc/

Granted, this is documentation, not a standards-body spec.

Yes, certainly has had effort put into proper documentation. Do you know if there is also work being done to spec it formally?

We're definitely considering it.

For Pepper? There is not, in fact. There's some developer documentation, but nothing resembling an actual implementation spec.

Sounds more like Java to me. Let's replace a few words in the article:

"Under the hood, Java Applets work by compiling Java source code to an intermediate representation, rather than architecture-specific representations as in Native Client. The Java bytecode is wrapped into a portable jar file, which can be hosted on a web server like any other website asset. When the site is accessed, Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers don’t need to recompile their applications multiple times to run across x86, ARM or MIPS devices."

It is a "Java" that Google controls, that is the main point.

It is not open source, then?

And Java is controlled by whom?

It is not open source, then?

It's open source, but all committers are Googlers and/or have to sign a copyright assignment. It's controlled by Google (which isn't a bad thing necessarily).

And Java is controlled by whom?

Oracle. They own the Java trademark, so any fork cannot be called Java unless they certify it.

> It's open source, but all committers are Googlers and/or have to sign a copyright assignment. It's controlled by Google (which isn't a bad thing necessarily).

Very importantly it's a copyright (and patent) license, not assignment. And it's the same thing required for any contribution to Chromium[1], and just about every competently run open source project out there, so it's not really an interesting distinction. The important aspect is more that the only "spec" for PNaCl is the documentation, which means that it can be changed by them...but then you break everyone's already compiled apps, so there are some incentives against that. Regardless, it's still open source, and you can still fork it, etc.

[1] http://dev.chromium.org/developers/contributing-code#TOC-Com...

I agree 100% that proper handling of copyright is important (and yes, I was wrong about the license/assignment thing), and I think Google is doing the right thing here.

My point was that Google controls the project (so far as it is possible to control an open source project). I don't see that as a bad thing.

> Sounds more like Java to me. Let's replace a few words in the article:

Winner, winner, chicken dinner.

After seeing all the web developers of the 90s dump on Java applets all the time, it's fascinating to see the same functionality being reimplemented piecemeal in Javascript.

PNaCl isn't Javascript.

We dumped on Java applets because they ran isolated in rectangles on the window and took ages to start and then proceeded to slow our machines to a crawl, and most of what it was used for was mundane stuff that could be done without Java, or that we didn't want.

The ultimate indictment of just how bad a fit java applets was is exactly that people shunned it despite the horrible alternatives.

It seems like every time someone tries to replace javascript with a better solution someone has to bring up vendor lock-in. Are we supposed to just live with javascript for eternity? When javascript was introduced it only worked on netscape browsers than other browsers adopted it later. It wasn't made a spec until later.

Indeed. Every trial to replace "standards" is called "evil". From this perspective, the web platform is far from open. The result is we all are in a local optimum trap. I already gave up expecting cool future and decided to stick to the native development for a while (for a decade or more).

BTW, as a game developer, it would be nice if this rendering latency issue will be fixed soon.

- http://phoboslab.org/log/2012/06/measuring-input-lag-in-brow...

- https://code.google.com/p/chromium/issues/detail?id=168459

I think this response time issue is a real show-stopper than JavaScript performance.

This along with the fact that you can't avoid GC when handling browser events makes it really hard to hit a consistent framerate for sure.

Because it is never done in collaboration between browser vendors.

Well, asm.js gets around this by piggybacking on JavaScript's syntax. So that's one approach.

Adoption really is a big issue, and I think it kind of misses the point to handwave it by saying, "Oh, adoption is such a big issue that it's insurmountable, so let's ignore it." Google hasn't really done a lot to work with anyone else on PNaCl, or even really to address any issues anyone's brought up with PNaCl. They're just sort of creating an island so far. If PNaCl is going to be a thing, they're going to need to get past that.

Chrome provides pepper.js, which converts PNaCl into JS using Emscripten, so it will run anywhere.

Ugh. Sounds like the next IE6 is here...

Can't wait to log into a bank that demands I installed Chrome to use their new 'security' or some web apps that won't run in anything but Chrome.

This seems like more of a ChromeOS move to me, so that you can run native code on Atom and X86 machines. The knock on ChromeOS is always that it's "just a browser". I seriously doubt anyone is going to write their Etsy storefront in NaCl. The benefit here, of course, is that if someone does write the next Photoshop for ChromeOS machines, it should also run fine in OS X, Windows and Linux. Seems like a win for portability to me.

On the other hand, I can imagine that there is a set of people that want to run client side and yet not expose even obfusticated javascript.

PNaCL and asm.js are roughly the same in terms of "exposing" the code in this sense. Both can be easily disassembled/prettified using readily tools readily available today.

That worked out well for Java.

No, but it did for Flash.

Let's just say I'm pretty happy I'm not maintaining any products built with Flex/Air.

No, but it did for LLVM.

Ah yes. No one ever remembers JavaOS and what a shit crock that was.

Web apps that won't run in anything but chrome? There are already plenty. Picasa/Google+ photo editing for a start.

Which is actually literally done by hardcoding "plus.google.com" into Chrome:

https://code.google.com/p/chromium/codesearch#chromium/src/c...

I doubt Google wants to keep this Chrome-only. Just like SPDY, there isn't initially support on all platforms/browsers so you have to have a fallback. But if it catches on then you will see broader support over time.

there is actually a fallback -- mentioned in the post: pepper.js (http://trypepperjs.appspot.com/)

Having taken a good hard look at adding this to a non-chrome browser I can tell you it would not be a trivial task. You can't just take the code and re-use it elsewhere and re-inventing it would require constant catch up.

It seems that writing browsers is hard. Oh well, let's just continue using exactly the same javascript stack forever then.

IE6 did not have an open source implementation that others could adopt.

You can't adopt the implementation of PNaCL either. It depends on PPAPI, which itself depends on vast amounts of implementation details of Chromium. There's no real attempt to decouple them.

People have in fact looked at what it would take to adopt PPAPI. The answer so far seems to be "you have to use Chromium, not another rendering engine".

The big difference, of course, is that you can be on any operating system with Chrome/Chromium. It's not ideal but that is huge. The "lockin" is no longer at the operating system.

PNaCl has been in development for a while, I'm having trouble understanding just what is being announced here. Is PNaCl now enabled by default in Chrome?

I also hadn't seen pepper.js before, is that new?

> http://codepen.io/lbebber/pen/xrwja

I think so. I just updated to Chrome 31 and it brought up a UAC in windows, which probably means that it was installing the PNaCl runtime since it usually doesn't require a UAC.

Or it could be Chrome asking to switch to installing in Program Files instead of User profile.

> Is PNaCl now enabled by default in Chrome?

I just updated, and in chrome://flags, the "Enable Portable Native Client" option has changed to "Disable Portable Native Client".

So yes, apparently.

It was NaCL which was previously available. This one is Portable NaCL which presumably can run the code built from the same intermediate machine code on various platforms (ARM, x86/64, etc). The immediate winner here is which runs on ARM and x64.

The news is that PNaCl has been enabled on the web in the latest release of chrome. Previously it shipped but ran only on the chrome web store and whitelisted sites like plus.google.com.

Also pepper.js is a fairly recent thing, yes.

Be interesting to see if this becomes a target for other languages, e.g. allowing browser applications to be written in Python.

http://gonativeclient.appspot.com/demo has a Lua interpreter demo. There's also Python, but you'll have to build it yourself (naclports).

I really really hope that this+pepper.js will allow you to deploy Ruby/Python/Go as client-side languages for the Web. Does anyone know how (P)NaCl interfaces with the DOM?

You don't have direct access to the DOM inside of NaCl, but you can pass messages back to JS via PostMessage.

We've had other languages running in browsers for quite a while now. eg.:

http://mozakai.blogspot.com/2013/05/lua-in-javascript-runnin...

What would be really great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application. This is after all how things ought to be: ideally you implement your DSL/document viewer inside your general-purpose runtime, instead of kludging your document-format specification up into an application runtime. None of the big browser vendors (including Mozilla and Google itself) is going to welcome such an idea though, as it threatens their de facto control over Web standards.

instead of kludging your document-format specification up into an application runtime

So glad to see somebody else saying this. I think you are absolutely correct. The current state of web applications / web browsers is an absolute kludge. Whatever happened to "separation of concerns" or the idea of building tools that do one thing and do it well?

But what "one thing" does a web browser do these days? One might think "browsing hypermedia content" but what does that have to do with becoming the universal application runtime?!?!??

Actually, the more I think about it, the more I think "clusterfuck" would be an even more apt term than "kludge" for what we have now. But I largely blame Sun: IF they had bothered to ship something like the Consumer JRE about 7 or 8 years sooner, and IF they hadn't screwed the pooch so badly on security, we could have something like Java / JNLP for hosting "applications" while the actual browser could stick to, well, browsing.

I'm actually waiting for something to come along and become "the next Java / Flash" but done right. :-(

I'm curious to see to what extent PNaCL can fulfill some of that.

> What would be really great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application.

Yes! We'd need a bunch of tooling re-built for each platform, but we could do it with static compilation :)

> instead of kludging your document-format specification up into an application runtime.

Seriously. It's a mess.

You mean WPF?

I assume that the content-to-presentation stack would include something XAML-ish (or indeed XUL-ish) near the presentation end, sure.

This is a similar idea to the MSR Embassies project: http://research.microsoft.com/en-us/projects/embassies/

Looks like it. It's also similar to ideas which were (iirc) prevalent in the mid-to-late '90s about a modularised/componentised browser as the future of the Web.

There are apps that use Canvas to such extent that it's kind of like a distinct UI layer.

Very good news! A lot of developers don't like JavaScript and HTML. Google started to listen. I really hope the rest of big players will follow the suite.

Be careful what you wish for because it might come true. A lot of people don't like the Open Web and are clamoring for something obfuscated. Longer term is lose-lose for everyone.

I don't understand how Web can be "Open" if your choice of language is limited to JS, HTML and CSS that are changing as quickly as standards committee is managing to react. And transpilers are just a second-class-citizen hack trying to make the best of situation.

Just write native applications and use normal network communications.

Plenty of choice available with 100% full hardware use.

Everyone can read the source code for the pages and applications. It's been a boon for the web, so far.

So PNaCl + llgo means Go in the browser, right? Now that is something to think about right there.

Indeed, something I have been thinking about for over a year ;)

http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-p...

Sadly I don't have a lot of time, so progress is quite slow. The PNaCl support isn't working at all at the moment, as I'm going through a fairly major refactoring to make things a bit more solid.

The demos are cool, but are there any among them that can't be done in JS? I know I've seen Voronoi polys in JS that were way less janky than the one in the PNaCL demo.

the voronoi is the only one that i think is competitive in JS.

js has plenty of 2d physics sims but i have yet to see a decent 3d one like this.

Are you saying that some of these can't be done in JS, or just that they're more efficient in PNaCl?

They can all be done in JS (modified to remove threading, of course). In fact, many of them already run in emscripten/pepper.js (see http://trypepperjs.appspot.com).

Which is a pretty big deal imo considering Voroni goes from 3.3 fps with 1 thread to 12 fps with 8 threads on my laptop with an intel quad core with hyperthreading.

Well, presumably you could implement a language with bignums in PNaCL with reasonable efficiency, something which is evidently not possible in JS.

Why is that evidently not possible? :) Serious question, I would guess anything that can be done in C - and bignums can - could be done well in JS, because typically C code compiled to JS runs at about half the speed of native.

If you have results showing otherwise for bignums, I would be very interested. Anything special about that particular problem?

> Why is that evidently not possible? :)

Because Mozilla assured us that it was not. Central to Mozilla's case against Dart was the assertion that parts of it - including bignums - could not be implemented efficiently by compiling to JS, leaving native Dart runtimes at a strong advantage.

Link?

Here we are: https://news.ycombinator.com/item?id=3094072

Thanks, reading that it says that native bignum support can speed things up. That's probably true - the only question is how much. If it's 25% vs 2,500% then that's what matters. I don't see an actual debate about numbers in that thread there, just generalities?

As I said above, I would expect JS to reach about half of the speed of C. It's possible that having native bignums would have removed some of that difference.

More importantly, the context here is PNaCl. Do you see a reason bignums could be emulated better in PNaCl vs JS? I assumed that's what you were implying, but perhaps I misunderstood you? Sorry if so.

I'm not sure the poster meant "bignum" as in huge numbers like GnuMP handles, or if he meant exact 64-bit integers, which JS doesn't have (natively).

I think true arbitrary-size bignums, because that's what Dart has?

The former - afaik, in computing 'bignums' has always been taken to mean arbitrary-precision integers.

It says 'LLVM style intermediate code'; why not actual LLVM intermediate code? What would be the reason for an alternative? If it would be actual LLVM code it would be easier to compile from programming languages and to different backends, right?

LLVM bitcode is quite large and not really suited to being a transport format. The bytecode they did come up with is probably a LLVM frontend.

Any reference to support your claim that LLVM bit code is quite large ?

It's quite obvious if you look at the spec. It retains very large amounts of information that is simply not needed merely for executing programs, but is quite useful for compiler backends and tools.

It's quite smart to write a LLVM backend and frontend for a custom (compact) bytecode.

"Finalized" and gzipped PNaCl code is about the same size as gzipped x86 or gzipped emscripten-generated JS code. PNaCl code seems to have a static overhead of about 400kByte, probably statically linked code which is either handled through Web APIs in emscripten, or dynamically linked CRT in native executables.

It is based on LLVM, but presumably they have to modify it for their particular needs. The PNaCl bitcode reference manual goes into more detail: https://developers.google.com/native-client/dev/reference/pn...

More details on the design process are available here: http://www.chromium.org/nativeclient/pnacl/stability-of-the-... (there's a link to a nicely formatted PDF in the bottom).

TL;DR: a lot of thought went into it :)

"The PNaCl bitcode is a restricted subset of LLVM IR."

https://groups.google.com/forum/#!msg/llvm-dev/lk6dZzwW0ls/J...

For anyone who works on Chrome: does this mean that Chrome won't move to support asm.js? I tried searching the bug tracker and discussion group and couldn't find anything.

In general I'm really happy that we're getting faster (no-gc) runtimes, but I think I favor asm.js's approach due to its backwards compatibility (though I admit I am not aware of the nuances of each implementation).

Chrome has taken the approach of working on improving their V8 engine to (hopefully) achieve similar performance to Firefox's specialized asm.js AOT codepath but without any special handling of the "use asm" directive (which gives Firefox guarantees about variable types & stuff like that). See https://news.ycombinator.com/item?id=6553794 for a discussion on the subject.

Great, thank you for the link!

They provide pepper.js, which does a similar trick for PnaCl stuff.

> backward compatibility

IMO NaCl is much more backwards compatible, letting you recompile old code-bases for the web with minimal changes. The javascript approach (even with the speed gains of asm.js) does not have threads/native instructions/etc.

I want chrome to support asm.js, and firefox to support NaCl. Winning all around.

> though I admit I am not aware of the nuances of each implementation

Perhaps a neutral discussion page is needed... I'll see about making one.

You don't have native instructions in PNaCl, which is what this is about.

Here is the V8 (Chrome) bug for asm.js support: http://code.google.com/p/v8/issues/detail?id=2599

In a way NaCl offers better backwards compatibility as the code can be compiled to both NaCl and Javascript simultaneously. asm.js javascript offers subpar performance on non asm.js platforms as it is optimised to a specific subset that would have no benefit on those. Also long run asm.js sounds like a terrible format when you consider the extra overhead of massive javascript files that could be concisely encoded like NaCl.

> asm.js javascript offers subpar performance on non asm.js platforms

What kind of browser do you consider a "non-asm.js platform"? Chrome for example is not detecting asm.js specifically, but still optimizes for the types of patterns in asm.js code. As a consequence it can run asm.js code very well, on par with Firefox in many cases, for example

https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0A...

Why do people keep saying that PNaCL is like ActiveX, when it's nothing of the sort? Is this a failing on Google's PR?

Because lots of people are narrow minded apparently

Great news for zerovm too! Will this mean apps that run seamlessly on ARM and X86 boxes?

Anyone know why it takes so long to load any of the demos on http://gonativeclient.appspot.com/demo/bullet ? They simply take way to long.

The PNaCl translator takes time to optimize the bitcode to highly-efficient machine code (which is almost on par with native performance). This only happens the first time you load the demo - afterwards the output is cached and the load should be instantaneous.

Translation time is one of the highest priorities of the PNaCl team and it should become significantly better in the future.

Wow, that's a flashback to the <applet> days!

Sadly even after it loads and hitting refresh I still see a progress bar.

As google knows loading time really really matters and for such small demos it does not look good that it takes 10(?) seconds to load. Makes me wonder about larger applications.

I am not having that problem, after the first load it is instant for me.

Does it take the same amount of time to load on subsequent runs as on the initial run? This should not happen. Are you running in incognito mode, perhaps? (in that case, caching doesn't happen for obvious reasons). Feel free to submit a report on the native-client-discuss mailing list or through the bug tracker.

It is faster, say less than a half second and not the 10 seconds it was the first time, but still very noticeable. Normal latest chrome on a Windows 2008 box.

One thing I am concerned about is, since PNaCl is essentially yet another platform, how Google (or anyone) is going to manage the host of supporting tools required. Tools like dependency management, libraries, process control etc.

By the way, Google has already proven their "platform-creation" skills with Android.

How is this different to Javascript? They both get jitted to native code (v8, llvm)...what's the benefit?

> what's the benefit?

I don't have to write JavaScript.

It also adds the ability to have, for example, multi-threaded code. That's especially nice when it lets you avoid having to port old code from threads to an event-driven model.

PNaCl bitcode is (mostly) statically-typed and has a C-like memory model, as opposed to dynamically-typed JavaScript. Dynamic typing has a run-time performance cost, and so does garbage collection.

Are you sure that PNaCl bitcode is typed at all?

It's kind-of typed. They kept the basic integer and floating-point types from LLVM (i8, i32, i64, double) and pointers, but removed structures and arrays. It's "more typed" than JavaScript, but less than C++. This still means that numeric code (working with integers and floats) is going to be at least an order of magnitude faster than on JS.

I am actually looking at saying good bye to browser (html / css / js and all the madness) and hello to apps that connect to dropbox or s3 or some such cheep server.

Isn't it better to ship uncompiled C++ code directly, instead of decompiling and recompiling already compiled code?

Honest question, I'm a noob at compilers :)

Bytecode (whether x86, Java class files or this) is a far more compact and (arguably) more complete representation of the program's logic than the input source code.

Also, you haven't experienced pain until you've tried to compile C or C++ on a machine other than the author's.

When this is supported natively in Safari on iOS it will be interesting.

Why only then?

Apple's developer guidelines prohibit compiling and running anything that came over the wire, for security reasons as well as competitive ones. They could add this ability to Safari themselves, but why would they?

What do you think will be the evolution here? Surely mobile won't stay behind native-webapps forever, at some point asm.js/pnacl/something else will come in. But what?

I'll be interested to see how pepper.js performs on mobile. Certainly plenty of people have skin in the game and want to see this stuff work.

For the same reasons, Safari has JavaScript support, I presume.

I think it's just a sarcasm.

asm.js is a better answer.

What's the question?

a platform neutral compiler target

How many layers of indirection can we put between the developer and the machine?

I'm sure there is some space left for fancy named design patterns and a template library with lambda support. You know you can't write a website without lambdas, don't you ?

Something that is standard and vendor neutral.

Reply on news.ycombinator.com