9 ms·
Google Introduces Portable Native Client
- quackerhacker 13y agoSounds kinda like Google's own implementation of WebCL? I guess Google is really trying to push the concept of utilizing the Chrome browser as an OS development environment instead of just a browser... seems cool.
- pekk 13y agoI really wish that someone other than Google would take this up (whatever Google would need to do for that). C has of course been a great choice for performance-sensitive programs for years and it is quite a mature language with mature tools. It doesn't make sense for everyone to be forced to use JavaScript as the only option, forever, just because of convention.
- kevingadd 13y agoOnce it's actually possible to use PNaCL apps in webpages, I think it will see dramatically faster adoption. It's mostly a question at this point of whether they manage to ship it before someone else beats them to the punch (looks like Chrome 30 is projected for August). By then Mozilla could easily have picked up a lot of momentum with asm.js.
- TazeTSchnitzel 13y agoProblem is we'll only ever see PNaCl support in Chrome. The nature of NaCl and PNaCl is that they rely on single implementations by Google which are designed around Chrome's internals, and so they are unlikely to ever be adopted by other browser vendors, aside from perhaps Opera, since it will be Chromium-based.
- mindcrime 13y agoI have really high hopes for PNaCl, but I'm skeptical that it will "get there". Getting other browser vendors to adopt it seems to be an uphill battle so far, and figuring out the tradeoffs between security and power will probably be a sticky point as well.
- venomsnake 13y agoBut it can solve a lot of problems for iOS development if you don't want to go trough the store.
- lttlrck 13y agoYeah when Safari supports it...
- kayoone 13y agoAs a game developer i was pretty excited about Native Client when i first heard about it in 2010, and PNaCL is definately nice. However, nowadays asm.js + emscripten seem to be the right direction and Google should adopt it.
- capisce 13y agoPNaCL seems like a much saner stack, turning JS into assembly never made sense to me if you want to get the most out of the hardware (with resulting power savings and/or performance gains).
- eslaught 13y agoTo be fair, asm.js isn't really JS. It's more like a low-level DSL. The fact that it happens to be a subset of JS is just a convenience for backwards compatibility. At any rate, from the perspective of the developer, it doesn't really make a difference. Either way, developers are interacting with a C/C++ compiler, not directly with the browser engine.
- jackowayed 13y agoIt's the same interface for the developer, but instead of being run directly on the CPU, it's run in a JavaScript virtual machine that interprets it or eventually compiles it to some kind of native code. That's very hard to overcome from a performance standpoint.
- rdw 13y agoasm.js is translated into native code before it's run, which is exactly the same as PNaCL, which is delivered in a non-executable format that has to be translated to the native architecture before it's run. The two technologies are just different standards for the exact same underlying idea.
- capisce 13y ago
- andyl 13y agoI don't see the need for NaCL when there is asm.js and emscripten. For fast lightweight native sandboxing, now we have docker. NaCL seemed like a great idea, but now it has been overtaken by other initiatives.
- dietrichepp 13y agoThe toolchain is better for embedding existing native applications in the browser with PNaCl. There's a lot of code out there which isn't written in JavaScript, and it would be nice to apply the same sandboxing guarantees. Again, it's not that you can't compile C to asm.js (yeah, emscripten does work), but I think the PNaCl toolchain is just better.
- coolsunglasses 13y agoThe worse tool will win.
- deleted 13y ago[deleted]
- solnyshok 13y agoI'd prefer to think that most efficient rather than most advanced tools win. look at hammer, axe, knife, nail. they are pure utility expressed as output divided by complexity of use
- TazeTSchnitzel 13y agoYour comment can be reduced to just its final clause. Could you expand on it?
- kryps 13y agoTheoretically PNaCL code should be executing much faster than emscripten-generated Javascript. Of course we should do real benchmarks, YMMV and so on.
- 13y ago
- alayne 13y agoThis seems like a niche technology. I doubt that many C/C++ developers want to write front end code for the web.
- neilxdsouza 13y agoI want to. I am developing a survey progrmaming compiler. I am currently isolating the runtime (written in c++) and trying to compile to JavaScript using Emscripten. But PNaCl could be a another web delivery option
- pjin 13y agoTo me, the most interesting thing about PNaCl is that it'll be the first real test of LLVM as a portable assembly bitcode, rather than just a compiler IR. There are arguments for why LLVM may not be such a good idea, but given the momentum it's been making, I can only see good things happening for LLVM if more people use it.
- kryps 13y agoThe second real test. Android Renderscript uses LLVM for portable bytecode already.
- dietrichepp 13y agoActually, emscripten does the same thing: LLVM->JS.
- millstone 13y agoRight. I had always thought that LLVM bitcode was unsuitable as a portable representation because it inevitably encoded architecture-specific details. Consider code like this: int lsize(void) { return sizeof(void *); } how would this be compiled portably, so that it returns 4 or 8 as appropriate? What would the LLVM bitcode look like?
- jensnockert 13y agoThis is true for LLVM bitcode in general, but PNaCl specifies an abstract machine that defines pointers as 4 bytes long. It also specifies Little Endian &c. See http://www.chromium.org/nativeclient/pnacl/bitcode-abi#TOC-Data-Types http://www.chromium.org/nativeclient/pnacl/bitcode-abi#TOC-D...
- kodablah 13y agoHow much of a subset of LLVM is it? Can other LLVM frontends target it easily (e.g. Rust or http://terralang.org/ http://terralang.org/)?
- pcwalton 13y agoRust could target it, but not as easily as you might think. LLVM IR is not portable (for example, here's some of the code necessary to get the calling conventions right in the LLVM IR for x86-64 [1]). The runtime and scheduler would have to be ported to the Pepper API if you wanted stuff like GC, I/O, and threads (which most Rust programs will want). [1]: https://github.com/mozilla/rust/blob/master/src/librustc/middle/trans/cabi_x86_64.rs https://github.com/mozilla/rust/blob/master/src/librustc/mid...
- vanderZwan 13y agoAndrew Wilkins is working on a Go frontend that can also target PNaCL[1], but since it's a spare time project and he just had a baby it's slowed down. So if anyone want to help him out... [1] http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-pnacl.html http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-p...
- mratzloff 13y ago> PNaCl, which Google says we should pronounce as "pinnacle" Or as I will call it, "P-salt". As in, take it with a grain of salt that Google will support this technology 18-24 months from now after it fails to gain much traction.
- pekk 13y agoIf you think this kind of technology compares to Google Reader, you are just confused. WebGL would be a better comparison.
- coldtea 13y agoOnly WebGL is a standard, whereas PNaCL is a Google only endeavor. If it doesn't catch up, they might abandon it just as they did anything else of theirs. Whereas they cannot abandon WebGL if they want to have a standards compliant browser.
- TheZenPsycho 13y agoActually google doesn't seem to have much problems with abandoning standards lately.
- TazeTSchnitzel 13y agoPerhaps Google's O3D, their 3D graphics implementation in the browser, which you haven't heard of. Why? Because when WebGL beat it, it was dropped.
- mratzloff 13y agoAt least Google released a final version of O3D that was an implementation on top of WebGL, providing a transition path. When they dropped Gears, they said they said, We realize there is not yet a simple, comprehensive way to take your Gears-enabled application and move it (and your entire userbase) over to a standards-based approach. We will continue to support Gears until such a migration is more feasible...[1] How did that turn out? They filed a Chromium ticket[2] that was moved to an html5rocks.com ticket[3] four months later that was closed as WONTFIX a month after that. My issue is not that they discontinue projects. My issue is how they often go about it. [1] http://gearsblog.blogspot.com/2010/02/hello-html5.html http://gearsblog.blogspot.com/2010/02/hello-html5.html [2] http://code.google.com/p/chromium/issues/detail?id=37180 http://code.google.com/p/chromium/issues/detail?id=37180 [3] http://code.google.com/p/html5rocks/issues/detail?id=73 http://code.google.com/p/html5rocks/issues/detail?id=73
- Irishsteve 13y agoIt's like ActiveX... of the future!
- conradev 13y agoJust an interesting tidbit I'd like to point out: native client was not mentioned in the Chrome portion of the I/O keynote at all, while asm.js was: "And in the last month alone, we’ve gotten over 2.4x speed boost running this asm.js code in V8, and there’s tons more optimization to come." Not only that, but it turns out that the mentioned improvements had nothing to do with asm.js at all: https://twitter.com/mraleph/status/334719725617696768 https://twitter.com/mraleph/status/334719725617696768
- ianetaylor 13y agoWe were going to show a couple of cool Native Client demos during the keynote but we had to cut them at the last minute due to time constraints.