Google Details PNaCl Native Client LLVM Bitcode

http://www.phoronix.com/scan.php?page=news_item&px=MTQyNTE

by GravityWell • 13 years ago

64 27 13 years ago

eliben4• 13 years ago

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.

gsnedders• 13 years ago

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.

lucian1900• 13 years ago

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

eliben4• 13 years ago

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.

exDM692• 13 years ago

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.

eliben4• 13 years ago

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

est• 13 years ago

Blogspam?

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

tadfisher• 13 years ago

Worse, it's Phoronix.

delroth• 13 years ago

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.

mcosta• 13 years ago

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?

pekk• 13 years ago

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

Groxx• 13 years ago

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.

bad_user2• 13 years ago

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.

RyanZAG• 13 years ago

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

Derander• 13 years ago

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.

cromwellian2• 13 years ago

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.

ahomescu12• 13 years ago

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

Sanddancer• 13 years ago

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.

exDM692• 13 years ago

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.

eliben4• 13 years ago

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.

ksec• 13 years ago

I hope this approach wins instead of asm.js

VikingCoder• 13 years ago

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.

Google Details PNaCl Native Client LLVM Bitcode

Related Stories