Chrome 31 Lands Portable Native Client (PNaCl)
Phoronix: Chrome 31 Lands Portable Native Client (PNaCl)
Chrome 30 was just made stable this week but Google has already released the Chrome 31 Beta. There's several user-facing changes for Chrome on Android while in the desktop version the major change is the arrival of Portable Native Client...
So that's all good and nice, but we all know NaCl's as doomed to fail as ActiveX if it doesn't become a web standard. It would be quite interesting if something like that were proposed as a standard, since it would make the web a far different platform than even HTML5 proposes.
I would like to see some benchmarks eventually on how native code runs between NaCl, Duetto, and asm.js (presumably before and after optimizations). I personally think the JS-based solutions are more promising in the short term simply due to the potential for every browser to use them. However, seeing where the web is going, it wouldn't be surprising if we were having a much different conversation three years from now.
I think PNaCl is interesting for development targeted at Chrome OS. Or am I thinking of NaCl? I always forget what the differences are between NaCl and PNaCl.
Originally Posted by scionicspectre
1.Pnacl is not nacl.
Originally Posted by scionicspectre
2.Pnacl is not ActiveX. ActiveX is close sourced,windows-only and unsafe.Pnacl is cross platform,open sourced and more safer with built-in sandbox in it.
3.There were some benchmarks appeared on hacker news and asm.js was half of native c/c++ speed, pnacl was 80% of native c/c++ speed at that time.
Yup,the web is going,everything is possible.
Still, PNaCl can be regarded as "one step above" NaCl.
- NaCl is compiled to x86 and/or ARM machine code, while targetting a special sand-boxed environment (and thus running at nearly native speeds).
- The comparison to ActiveX isn't completely out-of place, as both are methods to deliver binary code over internet. (Though we can expect Google to provide better sandboxing, whereas microsoft was more relying on signing (almos-) pureley native executables as a security).
- PNaCl on the other side, keeps the code represented as intermediate form (already parsed, not already compiled). That make it much more cross platform (it's up to the browser to decide what to do with the code. Compiling to binary like Chrome does is only 1 possibility). It's thus much more similar to virtual-machine and/or bytecode based software, like Java (and Flash ?).
Notice that the intermediate form is LLVM's bytecode. (It's important later) also this make building native library almost trivial (just finish compiling into native using LLVM).
Now the interesting part is : ASM.js is targetted by compilers like emscripten (and duetto). The best part? Those use LLVM to.
That means we're getting closer to a more or less portable AND secure way to get native speed out of low-level code on browser, by putting all the pieces together (C/C++, LLVM, PNaCl, ASM.js).
That means that in the future, a software developper could create a software in the low-level language of his/her choosing (like C/C++). The only thing to watch out is to target the correct environment.
Then use LLVM to compile it.
- For google browser, output LLVM IL to by provided as a PNaCl. Just make sure that the environment used at compile time matches closely the sandbox of Google.
The security can be expected to be better:
- for Google, they use a special sandbox. They only allow a special subset of API, and scan the binaries for illegal APIs and/or unallowed CPU instructions/memory accesses. (Still better than as-is ActiveX). Although some circumvention might be possible under certain buggy circumstances.