Portable Native Client

http://blog.chromium.org/2013/11/portable-native-client-pinnacle-of.html

by amaks • 13 years ago

179 135 13 years ago

blog.chromium.org

bsimpson• 13 years ago

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

eliben8• 13 years ago

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

pedrocr• 13 years ago

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?

duhroach• 13 years ago

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

cliffbean2• 13 years ago

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

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

leoc7• 13 years ago

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.

mindcrime• 13 years ago

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.

_prometheus4• 13 years ago

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.

pjmlp5• 13 years ago

You mean WPF?

wmf• 13 years ago

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

ianbicking• 13 years ago

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

tluyben2• 13 years ago

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?

lucian19002• 13 years ago

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.

drp4929• 13 years ago

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

mccr82• 13 years ago

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...

eliben8• 13 years ago

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 :)

kenferry• 13 years ago

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

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

icefox4• 13 years ago

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.

eliben8• 13 years ago

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.

0x03• 13 years ago

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

icefox4• 13 years ago

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.

cia_plant2• 13 years ago

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?

devrelm• 13 years ago

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.

mavhc• 13 years ago

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

mistercow• 13 years ago

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.

amaks• 13 years ago

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.

azakai8• 13 years ago

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.

thrownaway24243• 13 years ago

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.

spot2• 13 years ago

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.

thrownaway24243• 13 years ago

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

leoc7• 13 years ago

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

azakai8• 13 years ago

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?

RyanZAG• 13 years ago

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.

pkulak2• 13 years ago

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.

vertis• 13 years ago

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.

0x03• 13 years ago

That worked out well for Java.

chully• 13 years ago

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

pcwalton2• 13 years ago

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

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

scottmp10• 13 years ago

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.

_prometheus4• 13 years ago

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

icefox4• 13 years ago

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.

spot2• 13 years ago

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

bzbarsky2• 13 years ago

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".

melling• 13 years ago

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.

willvarfar• 13 years ago

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

_random_2• 13 years ago

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.

oblio2• 13 years ago

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.

_random_2• 13 years ago

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.

cgh• 13 years ago

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

axw• 13 years ago

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.

djvu9• 13 years ago

asm.js is a better answer.

general_failure• 13 years ago

What's the question?

querulous• 13 years ago

a platform neutral compiler target

cia_plant2• 13 years ago

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

pjmlp5• 13 years ago

Something that is standard and vendor neutral.

peterhunt3• 13 years ago

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).

elisee• 13 years ago

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.

peterhunt3• 13 years ago

Great, thank you for the link!

misuba3• 13 years ago

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

_prometheus4• 13 years ago

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.

pcwalton2• 13 years ago

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

sry_not4sale• 13 years ago

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

asdfaoeu• 13 years ago

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.

azakai8• 13 years ago

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...

azov• 13 years ago

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?..

eliben8• 13 years ago

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...)

afsina• 13 years ago

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.

pvnick• 13 years ago

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/)

axelf2• 13 years ago

How is this proprietary? Isnt there an open spec?

qznc• 13 years ago

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."

pjmlp5• 13 years ago

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

ArbitraryLimits• 13 years ago

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.

axelf2• 13 years ago

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.

NinjaWarrior• 13 years ago

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.

pjmlp5• 13 years ago

Because it is never done in collaboration between browser vendors.

chc• 13 years ago

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.

niutech• 13 years ago

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

augustl• 13 years ago

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 :)

mdaniel• 13 years ago

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.

cek• 13 years ago

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

eliben8• 13 years ago

Why only then?

misuba3• 13 years ago

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?

_prometheus4• 13 years ago

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?

drdaeman• 13 years ago

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

eonil• 13 years ago

I think it's just a sarcasm.

smegel• 13 years ago

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

trentmb• 13 years ago

what's the benefit?

I don't have to write JavaScript.

trothamel• 13 years ago

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.

ahomescu13• 13 years ago

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.

eru• 13 years ago

Are you sure that PNaCl bitcode is typed at all?

Fr0styMatt• 13 years ago

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?

BitMastro• 13 years ago

Because lots of people are narrow minded apparently

pritambaral• 13 years ago

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.

ThinkEzy• 13 years ago

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.

Portable Native Client

Related Stories