5 ms·

I 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,

by andyl 13y ago

I 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 ago
The 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 ago
  The worse tool will win.
  - deleted 13y ago
    [deleted]
  - solnyshok 13y ago
    I'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 ago
  Your comment can be reduced to just its final clause. Could you expand on it?
kryps 13y ago
Theoretically PNaCL code should be executing much faster than emscripten-generated Javascript. Of course we should do real benchmarks, YMMV and so on.
- cromwellian 13y ago
  NaCL also supports pthreads.
- TazeTSchnitzel 13y ago
  Should it? Both compile to intermediate representations which are distributed, then compiled to machine code by the browser. I see no reason PNaCl should be any faster.
- zaharpopov 13y ago
  Well you have benchmarks in that talk - PNaCl is 1.2x native speed. asm.js is ~2x. Single threaded. With multiple threads PNaCl will smoke asm.js since the latter has no threads at all. A 2x performance difference means your phone lasts 3 hours instead of 1.5 hours when playing that game. This is a huge, huge difference. Battery-powered devices make performance extremely important.
tomjen3 13y ago
Asm can't do nearly as much code optimizing as pnacl.
- Groxx 13y ago
  this seems like a strange assertion to me. why not? you can do amazing things with static analysis and runtime optimization, and that operates on the AST / some intermediate state, not the source code. if anything, higher-level languages (ie, JS as opposed to bytecode) lend themselves to more automatic-optimizations than lower-level ones because intent is encoded better.
  - jules 13y ago
    Asm.js is lower level than LLVM IR. In LLVM IR the data structures and memory allocation are still visible, in asm.js it's just opaque code working on a giant heap array. For example think how you'd do pointer analysis on asm.js...
    - pcwalton 13y ago
      The optimizations are already done ahead of time, by Emscripten. There is no need to do them on the client, and doing so just increases compilation time for no reason. In fact, shipping the types to the client is harmful, because it increases the download size. This is one of the ways asm.js is, IMHO, a better bytecode than LLVM IR…
      - Zarel 13y ago
        > In fact, shipping the types to the client is harmful, because it increases the download size To be fair, it's probably negligible compared to the download size impact of representing bytecode in a subset of JavaScript.
duaneb 13y ago
I don't see the need for asm.js and emscripten. They seemed like a great idea, but it has now been overtaken by PNaCL. We can all make unsubstantiated claims, and not all of us want to use the ghetto that is modern javascript.
- zobzu 13y ago
  I think one big difference is that if right now I play the GL demo on Firefox using asm.js, it works. If I play the same demo on Chrome.. it works. Now if I play nacl stuff on ANYTHING else than chrome is does NOT work. For me its not about having a nice language, it's about being standardized. Else, I can just provide C binaries, they're faster than nacl anyway.
  - vanderZwan 13y ago
    > Now if I play nacl stuff on ANYTHING else than chrome is does NOT work. That's purely an adoption-by-browser problem. > Else, I can just provide C binaries, they're faster than nacl anyway. The whole point of both nacl and asm.js was sandboxing.
    - zobzu 13y ago
      I don't see where the point of asm.js is sandboxing. In fact, that's pretty much beside the point. Sandboxing in NaCL is just a necessity.
    - karlmdavis 13y ago
      > That's purely an adoption-by-browser problem. ... which is a pretty big problem, right? Especially since I don't think FF is likely to pick up NaCL unless/until hell freezes over.
  - duaneb 13y ago
    This is by far the best argument, but how is the performance of asm.js under browsers other than firefox?
ch0wn 13y ago
I don't see how docker fits in there. Don't get me wrong, it's a great piece of technology, but it's very platform-specific and has nothing to do with the web as a platform in its current state.
- andyl 13y ago
  At one time I was looking at NaCL as a possible solution for lightweight server-side sandboxing.
  - ch0wn 13y ago
    That's an interesting use case. And you chose docker instead?
jules 13y ago
Asm.js doesn't have (as far as I know): 1. Good primitive data types (e.g. full width machine integers) 2. SIMD 3. Tail calls 4. Threads 5. Structs 6. Gotos 7. Memory management Once you add these you lose the supposed advantages of asm.js in practice. You lose the light weight. You lose realistic backwards compatibility because programs using these features will run so slow on normal JS VMs that they're unusable, or in the case of tail calls the program will stackoverflow on a normal JS VM.
- alexchamberlain 13y ago
  What does it have then?
  - nly 13y ago
    Explicit numeric types. Integers in particular.
    - deleted 13y ago
      [deleted]
- RandallBrown 13y ago
  Why do you want Gotos? There is a small set of problems that is best solved by Gotos and even those can be solved with a less error prone method.
  - jules 13y ago
    Asm.js is a target language for compilers. That small set of problems that are best solved by gotos includes target languages for compilers.
    - pcwalton 13y ago
      The Relooper solves this problem for compilers, and it is extremely effective in practice. Besides, you can always solve the lack of goto with code duplication, with no loss in performance.
nly 13y ago
NaCL still outperforms asm.js
zaharpopov 13y ago
Oh no, please please NO. asm.js is a nice hack and a commendable technical feat, but it's an absolutely horrible way moving forward. Do we really want to look back 10 years from now and see that we picked some crooked-n-twisted subset of JS to be the bytecode to which native code is compiled, just because "hey it's JS and it already works". Have we learned nothing from decades of horrible backwards-compatibility laden platforms? If one would design a portable bytecode today, would he come up with asm.js? Not in a lifetime (or two). PNaCl is way, way closer to a sane design for such a bytecode. Yes, it has its problems, but these appear to be incremental and can be solved with investment of time and effort (which Google seem to be willing to invest). In its _core_, PNaCl is the right approach to this problem. It uses a subset of the hugely successful and important LLVM IR to represent bytecode. IR that's way more suitable for the task than a subset of JS. And the sandboxing model PNaCl uses also makes way more sense than asm.js's use of typed arrays to represent the heap. Where is your memory model, asm.js? Do you think it's an easy problem to solve? I don't see threads with shared memory coming to asm.js in _years_, while PNaCl already has them. Say what you will, but threads are important. Games use them all over the place, and other applications too. Remember, speed means battery life for phones and tablets (it's only a matter of time until PNaCl runs on Android, who doubts it?) So 2x native vs. 1.15x native is a huge difference. Again, as a hacker I can see the coolness of asm.js and kudos to Mozilla for creating it. It's a great interim approach to ensure that native code can truly run everywhere, in all browsers. But looking into the future, I hope it will die and PNaCl (or some derivative of PNaCl) will take over. Even today it lets you compile C++ code and run at nearly native speed with threads on several architectures and several OSes, in a secure way! Other browsers should definitely adopt it. Although I understand if Google doesn't worry much about it - Chrome is the most popular browser today, and its lead is growing. Lack of adoption from other browsers may end up being _their_ problem, not Google's.
- pcwalton 13y ago
  > It uses a subset of the hugely successful and important LLVM IR to represent bytecode. IR that's way more suitable for the task than a subset of JS. Speaking as someone who works with LLVM IR on a daily basis, I really dislike the idea of shipping compiler IR to users. Believe it or not, asm.js is actually significantly closer to the ideal bytecode that I would ship, except for surface syntax. LLVM IR is a compiler IR: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... > And the sandboxing model PNaCl uses also makes way more sense than asm.js's use of typed arrays to represent the heap. Where is your memory model, asm.js? Do you think it's an easy problem to solve? You could implement asm.js in the exact same way. There's nothing stopping you from doing that. > I don't see threads with shared memory coming to asm.js in _years_, while PNaCl already has them. Years? Not according to any discussions I've been privy to. > So 2x native vs. 1.15x native is a huge difference. I have not verified the PNaCl performance numbers, but I would be surprised if they counted compilation time. The asm.js performance benchmarks do count compilation time. So I suspect the apples-to-apples gap is actually much smaller.

by andyl 13y ago

dietrichepp 13y ago

The 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 ago
The worse tool will win.
- deleted 13y ago
  [deleted]
- solnyshok 13y ago
  I'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 ago
Your comment can be reduced to just its final clause. Could you expand on it?

kryps 13y ago

Theoretically PNaCL code should be executing much faster than emscripten-generated Javascript. Of course we should do real benchmarks, YMMV and so on.

cromwellian 13y ago
NaCL also supports pthreads.
TazeTSchnitzel 13y ago
Should it? Both compile to intermediate representations which are distributed, then compiled to machine code by the browser. I see no reason PNaCl should be any faster.
zaharpopov 13y ago
Well you have benchmarks in that talk - PNaCl is 1.2x native speed. asm.js is ~2x. Single threaded. With multiple threads PNaCl will smoke asm.js since the latter has no threads at all. A 2x performance difference means your phone lasts 3 hours instead of 1.5 hours when playing that game. This is a huge, huge difference. Battery-powered devices make performance extremely important.

tomjen3 13y ago

Asm can't do nearly as much code optimizing as pnacl.

Groxx 13y ago
this seems like a strange assertion to me. why not? you can do amazing things with static analysis and runtime optimization, and that operates on the AST / some intermediate state, not the source code. if anything, higher-level languages (ie, JS as opposed to bytecode) lend themselves to more automatic-optimizations than lower-level ones because intent is encoded better.
- jules 13y ago
  Asm.js is lower level than LLVM IR. In LLVM IR the data structures and memory allocation are still visible, in asm.js it's just opaque code working on a giant heap array. For example think how you'd do pointer analysis on asm.js...
  - pcwalton 13y ago
    The optimizations are already done ahead of time, by Emscripten. There is no need to do them on the client, and doing so just increases compilation time for no reason. In fact, shipping the types to the client is harmful, because it increases the download size. This is one of the ways asm.js is, IMHO, a better bytecode than LLVM IR…
    - Zarel 13y ago
      > In fact, shipping the types to the client is harmful, because it increases the download size To be fair, it's probably negligible compared to the download size impact of representing bytecode in a subset of JavaScript.

duaneb 13y ago

I don't see the need for asm.js and emscripten. They seemed like a great idea, but it has now been overtaken by PNaCL. We can all make unsubstantiated claims, and not all of us want to use the ghetto that is modern javascript.

zobzu 13y ago
I think one big difference is that if right now I play the GL demo on Firefox using asm.js, it works. If I play the same demo on Chrome.. it works. Now if I play nacl stuff on ANYTHING else than chrome is does NOT work. For me its not about having a nice language, it's about being standardized. Else, I can just provide C binaries, they're faster than nacl anyway.
- vanderZwan 13y ago
  > Now if I play nacl stuff on ANYTHING else than chrome is does NOT work. That's purely an adoption-by-browser problem. > Else, I can just provide C binaries, they're faster than nacl anyway. The whole point of both nacl and asm.js was sandboxing.
  - zobzu 13y ago
    I don't see where the point of asm.js is sandboxing. In fact, that's pretty much beside the point. Sandboxing in NaCL is just a necessity.
  - karlmdavis 13y ago
    > That's purely an adoption-by-browser problem. ... which is a pretty big problem, right? Especially since I don't think FF is likely to pick up NaCL unless/until hell freezes over.
- duaneb 13y ago
  This is by far the best argument, but how is the performance of asm.js under browsers other than firefox?

ch0wn 13y ago

I don't see how docker fits in there. Don't get me wrong, it's a great piece of technology, but it's very platform-specific and has nothing to do with the web as a platform in its current state.

andyl 13y ago
At one time I was looking at NaCL as a possible solution for lightweight server-side sandboxing.
- ch0wn 13y ago
  That's an interesting use case. And you chose docker instead?

jules 13y ago

Asm.js doesn't have (as far as I know): 1. Good primitive data types (e.g. full width machine integers) 2. SIMD 3. Tail calls 4. Threads 5. Structs 6. Gotos 7. Memory management Once you add these you lose the supposed advantages of asm.js in practice. You lose the light weight. You lose realistic backwards compatibility because programs using these features will run so slow on normal JS VMs that they're unusable, or in the case of tail calls the program will stackoverflow on a normal JS VM.

alexchamberlain 13y ago
What does it have then?
- nly 13y ago
  Explicit numeric types. Integers in particular.
  - deleted 13y ago
    [deleted]
RandallBrown 13y ago
Why do you want Gotos? There is a small set of problems that is best solved by Gotos and even those can be solved with a less error prone method.
- jules 13y ago
  Asm.js is a target language for compilers. That small set of problems that are best solved by gotos includes target languages for compilers.
  - pcwalton 13y ago
    The Relooper solves this problem for compilers, and it is extremely effective in practice. Besides, you can always solve the lack of goto with code duplication, with no loss in performance.

nly 13y ago

NaCL still outperforms asm.js

zaharpopov 13y ago

Oh no, please please NO. asm.js is a nice hack and a commendable technical feat, but it's an absolutely horrible way moving forward. Do we really want to look back 10 years from now and see that we picked some crooked-n-twisted subset of JS to be the bytecode to which native code is compiled, just because "hey it's JS and it already works". Have we learned nothing from decades of horrible backwards-compatibility laden platforms? If one would design a portable bytecode today, would he come up with asm.js? Not in a lifetime (or two). PNaCl is way, way closer to a sane design for such a bytecode. Yes, it has its problems, but these appear to be incremental and can be solved with investment of time and effort (which Google seem to be willing to invest). In its _core_, PNaCl is the right approach to this problem. It uses a subset of the hugely successful and important LLVM IR to represent bytecode. IR that's way more suitable for the task than a subset of JS. And the sandboxing model PNaCl uses also makes way more sense than asm.js's use of typed arrays to represent the heap. Where is your memory model, asm.js? Do you think it's an easy problem to solve? I don't see threads with shared memory coming to asm.js in _years_, while PNaCl already has them. Say what you will, but threads are important. Games use them all over the place, and other applications too. Remember, speed means battery life for phones and tablets (it's only a matter of time until PNaCl runs on Android, who doubts it?) So 2x native vs. 1.15x native is a huge difference. Again, as a hacker I can see the coolness of asm.js and kudos to Mozilla for creating it. It's a great interim approach to ensure that native code can truly run everywhere, in all browsers. But looking into the future, I hope it will die and PNaCl (or some derivative of PNaCl) will take over. Even today it lets you compile C++ code and run at nearly native speed with threads on several architectures and several OSes, in a secure way! Other browsers should definitely adopt it. Although I understand if Google doesn't worry much about it - Chrome is the most popular browser today, and its lead is growing. Lack of adoption from other browsers may end up being _their_ problem, not Google's.

pcwalton 13y ago
> It uses a subset of the hugely successful and important LLVM IR to represent bytecode. IR that's way more suitable for the task than a subset of JS. Speaking as someone who works with LLVM IR on a daily basis, I really dislike the idea of shipping compiler IR to users. Believe it or not, asm.js is actually significantly closer to the ideal bytecode that I would ship, except for surface syntax. LLVM IR is a compiler IR: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... > And the sandboxing model PNaCl uses also makes way more sense than asm.js's use of typed arrays to represent the heap. Where is your memory model, asm.js? Do you think it's an easy problem to solve? You could implement asm.js in the exact same way. There's nothing stopping you from doing that. > I don't see threads with shared memory coming to asm.js in _years_, while PNaCl already has them. Years? Not according to any discussions I've been privy to. > So 2x native vs. 1.15x native is a huge difference. I have not verified the PNaCl performance numbers, but I would be surprised if they counted compilation time. The asm.js performance benchmarks do count compilation time. So I suspect the apples-to-apples gap is actually much smaller.