Google Details PNaCl Native Client LLVM Bitcode | Hacker News Reader

Google Details PNaCl Native Client LLVM Bitcode

phoronix.com

64 pointsGravityWell27 comments

A couple of notes:

"Google has begun making public the details concerning their Portable Native Client (PNaCl) implementation."

To be completely fair, PNaCl is part of Chromium, and hence an open source project from the start. The code is freely available for anyone to see, check out and build, and has always been.

"Portable Native Client comes down to compiling Google Native Client applications to a subset of LLVM bitcode that can then basically run anywhere that Native Client is supported. "

I suppose Michael Larabel meant to say "compiling C and C++ applications" instead of "Google Native Client applications" here.

Well, it started internally, it was mostly working when the code was open sourced. Not really an "open source project from the start", even if it has been for, well, years.

I think it's correct saying NaCl apps, since the same API restrictions are imposed by PNaCl.

Once you compiled and published it, it's a NaCl app. Saying "compiling NaCl apps" is misleading because NaCl is a platform, not a language. The PNaCl toolchain can compile C and C++ (and theoretically other frontends can be added, as long as they lower to the PNaCl IR) to a blob that the browser can execute in a secure manner on all supported platforms and CPU architectures.

> To be completely fair, PNaCl is part of Chromium, and hence an open source project from the start. The code is freely available for anyone to see, check out and build, and has always been.

I think the most important thing here is not the code, but rather the refinements to LLVM IR bitcode to make it more portable. Most of LLVM IR is already CPU/platform agnostic but parts of it are closely tied to the target architecture (which makes sense since LLVM IR was originally targeted at compilers).

A standard portable subset of LLVM IR would be very welcome.

Well, there's a portable subset of LLVM IR there, for sure. Comments are welcome - we are very interested in feedback.

Blogspam?

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064394....

Worse, it's Phoronix.

Hate all you want on Phoronix, but I still don't know any other good "news aggregator" for X11, Linux GPU drivers and optimization news. It's not like everything on Phoronix comes from -announce mailing lists, they do a pretty good job at filtering noise from development mailing list and providing fresh news. They also always link to the original source if you're not happy about the quality of their articles.

Is me alone who sees NaCl as another kind of flash? It is just a blob running into a rectangle. No js accesible, almost no browser control over it. How web is this?

Is HTML5 Canvas also another kind of Flash? Is your objection that NaCl is not a DOM manipulation API?

tbh, I see it as (possibly) a better java applet. with better OpenGL support, so "real" games are actually feasible, and not even that hard.

Chrome is positioning itself very, very strongly as a platform, not just a browser, and this is a necessary part of that. I'm not a fan of this ever-widening set of things browsers have to do (separate from each other / external libs / etc) since it just raises the bar for any competitors, but I must admit it is nicer for the user than all the past attempts.

> Chrome is positioning itself very, very strongly as a platform, not just a browser

That makes no sense, because the browser is by definition a platform.

I don't know your definition of a browser, but in my opinion, a browser used to be mainly a document viewer. This is changing now, but the original statement does make sense in this context.

When? In 1995?

"Chrome is positioning itself very, very strongly as a platform"

This is terrible and I wish they'd stop doing this and stick to working with Mozilla more.

NaCl is actually designed to interoperate with JS in a fairly rich way and this interoperability is designed to be provided entirely by the browser. The idea is that you pick the runtime that you want -- probably the one provided by your browser -- and it pokes (hopefully secured) holes in the safe box that native client guarantees. This includes a sort of networking API that JS can call in to.

Gmail is basically just a blob of js. A lot of modern web apps are. If your definition of the Web is "View Source" capable JS, that battle was lost a long time ago.

NaCL does permit web apps, the Pepper API allows calling browser APIs just like JS, unlike Flash.

The way I look at the browser is, it's a layout engine that manages a Render Tree built by DOM and CSS. It has external bindings for APIs to manipulate DOM, CSS, plus canvas, audio, storage, et al. These APIs may be called from JS, Dart, NaCl. It's the APIs that define the platform, not the programming language.

Too many people are fixated on JS. Really, all that truly matters is having a portable, secure mechanism for distributing code that can call into these bindings. Right now, JS is the only game in town, but there's no reason that has to be the dominant mechanism for the next decades.

If the Web is to be around for another 20-30 years, it needs to avoid stagnation via language zealotry.

Neither Flash nor Java applets had access to the DOM, I think that was the point of the comment.

Flash and Java applets do have access to the DOM.

Interesting, didn't know that. I think some of the bad perception of Java/Flash pages is because most of them didn't access the DOM, they just dumped their own graphics on the page (AFAIK, you could even use AWT/Swing in applets).

Yes they do, but ExternalInterface and Common DOM suck. Pepper has a more direct-binding feel.

It is js accessible through the rpc api:

http://www.chromium.org/nativeclient/how-tos/simple-rpc

Yes, there is some overhead involved in shipping bytes back and forth to another process, but there has been a good amount of work put into the process to making it so (p)nacl isn't in its own box in the corner, and you can have calls thrown back and forth as needed.

Things like this mean that you don't have to reinvent wheels just because you want to push processing to the client side. There's a considerable amount of c/c++/everything else code out there, and it is rather pointless to have to maintain two codebases just so you can have something web-enabled.

> Is me alone who sees NaCl as another kind of flash?

It may be yet another rectangle in a browser but there are unquestionable advantages in native code versus JavaScript or Flash (but comes with its own problems too). As such, NaCl is a worthwhile effort even if it never catches on big time and remains a Google research project.

There are important differences from flash. For example, built-in strong security from the ground up. Another example - open source. Another is performance - NaCl is near native speed, Flash (to the best of my knowledge) is not.

NaCl can actually interoperate with the DOM and JS quite well - there are examples in the SDK. It is not aimed solely at "disconnected rectangle"-like applications.

Almost the speed of native.

As secure as possible.

As portable as possible.

It's definitely an interesting feature set. I personally hope ASM.JS is able to "catch up" to NaCl, but if it doesn't, then I hope PNaCl becomes widely available.

I hope this approach wins instead of asm.js

Reply on news.ycombinator.com