2 ms·

I don’t see how asmjs/wasm’s marketing would be much different to the one of pnacl/nacl. It’s just fundamentally better and that’s why people are excited.

pjmlp 7y ago
So much better that PNaCL still outperforms WASM. https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/ https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/ And it doesn't offer any significant security improvements, in spite of its marketing, compiling Heartbleed into WASM is still possible.
- the_mitsuhiko 7y ago
  The reason people are excited about WASM is neither security nor performance.
  - pjmlp 7y ago
    So what is so exciting about a bytecode format, created out of the political war between PNaCL and asm.js, without any big news for anyone that actually cares about bytecode formats invented since 1958 with the introduction of UNCOL and subsequent attempts?
    - comex 7y ago
      Compared to other bytecode formats, it has lots of advantages. Browsers support it, LLVM targets it, people are using it. I don't really see the point of using WebAssembly (or any other bytecode format) outside the browser, though. It just seems like a way to throw away performance for no benefit.
      - pjmlp 7y ago
        Browsers support it because Mozilla refused to adopt PNaCL, which was also targeted by LLVM, WebAssembly is a political compromise, not any kind of technical achievement as it keeps being celebrated for. Mainframes and midrange computers have used bytecode formats since the early 60's as hardware independence mechanism, where you AOT compile at installation time, or have an hardware interpreter implemented as part of a micro-coded CPU. It has allowed those kind of computers to advance their hardware to modern times, while keeping the applications unchanged. The same idea is widely used on embedded platforms, as it gives OEMs flexibility designing hardware, while reducing software development costs even further.
        comex 7y ago
        Not a technical achievement so much as a different point in the design space. Two key differences. First, NaCl was originally designed to run in its own process, for a few different reasons: - The original 32-bit x86 implementation fundamentally required it because, due to how it used %ss, a crash in the sandboxed code would crash the whole process. [1] Avoiding that issue would have required a different model that had performance overhead (and was more complicated). Ironically, the 64-bit version had no such requirement, but by then NaCl's design was already well-established. - AFAIK it was originally developed separately from Chrome, so there was less motivation to deeply integrate it with JS. - It was apparently conceived as a replacement for plugins (originally using NPAPI, before PPAPI was invented), which Chrome had run in a separate process anyway. But WebAssembly is designed to run in the same process as DOM/JS, giving it two key advantages: it can reuse Web APIs rather than needing a whole separate set of APIs (PPAPI), and it can directly call and be called from JS. Both make life easier for developers; reusing web APIs also makes life easier for implementers. The second key difference is that NaCl leaks much more information about the native environment than WebAssembly. Even with PNaCl, the native text segment, the native stack, and certain bits of implementation code were all accessible within the sandboxed address space. If you were up to shenanigans, you could even do things like jump into the middle of a native function, completely breaking the portability abstraction. Was that a problem? I don't know. It was conceptually secure; you couldn't break out of the sandbox without finding a vulnerability, just like WebAssembly. But it was a lot less isolated. In contrast, WebAssembly makes none of those things accessible and enforces full control flow integrity. You can't even tell which architecture you're running on, aside from indirect observations by benchmarking instructions or checking for memory ordering violations. That difference is certainly responsible for some of the performance gap between NaCl and WebAssembly. Is it responsible for all of it? I don't know. I don't even know how big the gap is in the first place; the PDFTron benchmark makes it look major, but I haven't seen any other benchmarks, and I'm not sure if anyone has investigated what exactly is causing the overhead in the PDFTron benchmark, especially since the code isn't open source. [1] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c...
        afiori 7y ago

pjmlp 7y ago

So much better that PNaCL still outperforms WASM. https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/ https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/ And it doesn't offer any significant security improvements, in spite of its marketing, compiling Heartbleed into WASM is still possible.

the_mitsuhiko 7y ago
The reason people are excited about WASM is neither security nor performance.
- pjmlp 7y ago
  So what is so exciting about a bytecode format, created out of the political war between PNaCL and asm.js, without any big news for anyone that actually cares about bytecode formats invented since 1958 with the introduction of UNCOL and subsequent attempts?
  - comex 7y ago
    Compared to other bytecode formats, it has lots of advantages. Browsers support it, LLVM targets it, people are using it. I don't really see the point of using WebAssembly (or any other bytecode format) outside the browser, though. It just seems like a way to throw away performance for no benefit.
    - pjmlp 7y ago
      Browsers support it because Mozilla refused to adopt PNaCL, which was also targeted by LLVM, WebAssembly is a political compromise, not any kind of technical achievement as it keeps being celebrated for. Mainframes and midrange computers have used bytecode formats since the early 60's as hardware independence mechanism, where you AOT compile at installation time, or have an hardware interpreter implemented as part of a micro-coded CPU. It has allowed those kind of computers to advance their hardware to modern times, while keeping the applications unchanged. The same idea is widely used on embedded platforms, as it gives OEMs flexibility designing hardware, while reducing software development costs even further.
      - comex 7y ago
        Not a technical achievement so much as a different point in the design space. Two key differences. First, NaCl was originally designed to run in its own process, for a few different reasons: - The original 32-bit x86 implementation fundamentally required it because, due to how it used %ss, a crash in the sandboxed code would crash the whole process. [1] Avoiding that issue would have required a different model that had performance overhead (and was more complicated). Ironically, the 64-bit version had no such requirement, but by then NaCl's design was already well-established. - AFAIK it was originally developed separately from Chrome, so there was less motivation to deeply integrate it with JS. - It was apparently conceived as a replacement for plugins (originally using NPAPI, before PPAPI was invented), which Chrome had run in a separate process anyway. But WebAssembly is designed to run in the same process as DOM/JS, giving it two key advantages: it can reuse Web APIs rather than needing a whole separate set of APIs (PPAPI), and it can directly call and be called from JS. Both make life easier for developers; reusing web APIs also makes life easier for implementers. The second key difference is that NaCl leaks much more information about the native environment than WebAssembly. Even with PNaCl, the native text segment, the native stack, and certain bits of implementation code were all accessible within the sandboxed address space. If you were up to shenanigans, you could even do things like jump into the middle of a native function, completely breaking the portability abstraction. Was that a problem? I don't know. It was conceptually secure; you couldn't break out of the sandbox without finding a vulnerability, just like WebAssembly. But it was a lot less isolated. In contrast, WebAssembly makes none of those things accessible and enforces full control flow integrity. You can't even tell which architecture you're running on, aside from indirect observations by benchmarking instructions or checking for memory ordering violations. That difference is certainly responsible for some of the performance gap between NaCl and WebAssembly. Is it responsible for all of it? I don't know. I don't even know how big the gap is in the first place; the PDFTron benchmark makes it look major, but I haven't seen any other benchmarks, and I'm not sure if anyone has investigated what exactly is causing the overhead in the PDFTron benchmark, especially since the code isn't open source. [1] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c...
      - afiori 7y ago