Announcement

Collapse
No announcement yet.

Chrome 31 Lands Portable Native Client (PNaCl)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.

    Comment


    • #3
      Originally posted by scionicspectre View Post
      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.

      Comment


      • #4
        Originally posted by scionicspectre View Post
        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.
        1.Pnacl is not nacl.
        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.
        4.Asm.js is for compiler not for app/web developers.AFAIK,it is a specialized subset of JavaScript that?s optimized for performance, especially for this use case of c/c++ applications compiled to JavaScript.But you can run native c/c++ code(maybe more language will be supported) directly in browser via pnacl.
        Yup,the web is going,everything is possible.

        Comment


        • #5
          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).

          - ASM.js *is* closely related to all this. It's a special subset of Javascript which maps nicely to concepts usually present in hard-typed low-level language (like C, C++, etc.) and thus is very easy to compile (JIT, etc.) into native code for faster execution on ASM.js aware browsers (like Firefox). While at the same time, its still a valid (subset of) Javascript, so it can also be used as-is on legacy browser.

          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.
          - For mozilla browser, further process the LLVM into ASM.js using emscripten. Mozilla will be able to process the Javascript at nearly native speeds. Just make sure that you have (javascript) libraries providing the necessary API for your environment.
          For other browser, also use the javascript output. Even if those can't run it at native speed, they still can run it because that's still standard compliant javascript. Probably a lot of the - optimisaiton of their javascript engine can work nicely with ASM.js (javascript type tracing will be happy with ASM.js static-like types). That won't be native but that can still be fast (pre-ASM.js Firefoxes where still able to decently run Bananabread, the Emscripten-compiled Sauerbratten) - which isn't surprising as most such games needs most of their power for 3D (handled by OpenGL in pure native application, or WebGL in all these web applications. Not by game code itself).
          - Worst case: the javascript can still be interpreted plain and simple. Although the performance is going to be catastrophic, it can still get executed even on a non-optimising javascript engine.

          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.
          - for all the others: well it's only Javascript and thus limited to only to what Javscript can do (only Javscript APIs). Circumventing is going to be hard too, even for ASM-js-compiling browsers.

          Comment

          Working...
          X