4 ms·

Native Client also supports SSE on x86, and NEON on ARM.

hosay123 14y ago
And will binaries compiled for Native Client today support SSE6 (released Q1 2014), ARMv15 (Q3 2016), and so on? Of course, if the authoring party still exists to recompile it, and they have a commercial reason for doing so..
- pifflesnort 14y ago
  This is a problem no matter what your target is. Web apps written in 1997 do not take advantage of modern browser features. Browsers written in 1997 can not render modern web pages. At least with NaCL, you have the option of taking maximum advantage of the available hardware. I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing, the way we've seen CPU vendors add support for virtualization-specific extensions. At the end of the day, I don't see this as a death blow for NaCL. Rather, it pushes us farther into a post-JS/HTML/CSS platform. We'll start seeing new languages take off, and the underlying platform target itself (browser, native, or otherwise) will matter less and less. asm.js can be just another compilation target, along-side NaCL and iOS. Once you go in that direction, the HTML/JS/CSS monstrosity start to become less relevant outside of hypertext documents.
  - comex 14y ago
    > I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing A bit off topic, but this already exists, in the sense that there is no difference between NaCl-style sandboxing and what every OS kernel already provides for its processes, except that NaCl is generally locked down tighter. All that would need to happen is for OSes to provide support for containers with arbitrarily restricted syscalls (as Linux already does) and NaCl could give up on the software fault isolation without any real loss in security.
    - zobzu 14y ago
      kernels provided this feature since forever. selinux, trustedbsd, you name it, provided this. seccomp on linux is just a "in code, per process" version, while selinux, or earlier things like RSBAC or LIDS provide more flexibility (but apparently, nobody understood how to use any of this in the past :)
    - pifflesnort 14y ago
      The major difference is that I can run a NaCL process(es) inside my own userspace process without kernel support, and that a failure in my sandboxing won't also be a failure inside the kernel.
  - kayoone 14y ago
    i also believe this to be true mostly for real apps and games. I dont see alot of benefits for normal web development though.
  - Millennium 14y ago
    That would be true if asm.js were just a faster interpreter, but it isn't. It's not even really a separate language: "use asm" is just a hint to the JavaScript runtime that the code follows a particular set of conventions that, it so happens, are very easy to optimize. An asm.js-supporting runtime which sees this hint can run that code through a different compiler that takes maximum advantage of the available hardware (i.e. whatever it's running on, with the asm.js code doesn't need to know or care about). A runtime that doesn't support asm.js will just run the code like it did before. My point is that asm.js is every bit as capable of fully optimizing for the host as NaCl. It has two big advantages over NaCl, though. One is that it's architecture-independent: the host knows what architecture it uses, and (assuming it has the compiler, which an asm.js-supporting runtime has by definition) can act accordingly, taking full advantage of its own features. The other advantage is that there's a fallback even in case the runtime doesn't support asm.js: it's no faster than ordinary JavaScript in this case, but at least it does no harm.
- rayiner 14y ago
  See: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test...
- mtgx 14y ago
  ARMv15? Is that a new architecture after ARMv8? Do you have a link on it?

And will binaries compiled for Native Client today support SSE6 (released Q1 2014), ARMv15 (Q3 2016), and so on? Of course, if the authoring party still exists to recompile it, and they have a commercial reason for doing so..

pifflesnort 14y ago
This is a problem no matter what your target is. Web apps written in 1997 do not take advantage of modern browser features. Browsers written in 1997 can not render modern web pages. At least with NaCL, you have the option of taking maximum advantage of the available hardware. I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing, the way we've seen CPU vendors add support for virtualization-specific extensions. At the end of the day, I don't see this as a death blow for NaCL. Rather, it pushes us farther into a post-JS/HTML/CSS platform. We'll start seeing new languages take off, and the underlying platform target itself (browser, native, or otherwise) will matter less and less. asm.js can be just another compilation target, along-side NaCL and iOS. Once you go in that direction, the HTML/JS/CSS monstrosity start to become less relevant outside of hypertext documents.
- comex 14y ago
  > I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing A bit off topic, but this already exists, in the sense that there is no difference between NaCl-style sandboxing and what every OS kernel already provides for its processes, except that NaCl is generally locked down tighter. All that would need to happen is for OSes to provide support for containers with arbitrarily restricted syscalls (as Linux already does) and NaCl could give up on the software fault isolation without any real loss in security.
  - zobzu 14y ago
    kernels provided this feature since forever. selinux, trustedbsd, you name it, provided this. seccomp on linux is just a "in code, per process" version, while selinux, or earlier things like RSBAC or LIDS provide more flexibility (but apparently, nobody understood how to use any of this in the past :)
  - pifflesnort 14y ago
    The major difference is that I can run a NaCL process(es) inside my own userspace process without kernel support, and that a failure in my sandboxing won't also be a failure inside the kernel.
- kayoone 14y ago
  i also believe this to be true mostly for real apps and games. I dont see alot of benefits for normal web development though.
- Millennium 14y ago
  That would be true if asm.js were just a faster interpreter, but it isn't. It's not even really a separate language: "use asm" is just a hint to the JavaScript runtime that the code follows a particular set of conventions that, it so happens, are very easy to optimize. An asm.js-supporting runtime which sees this hint can run that code through a different compiler that takes maximum advantage of the available hardware (i.e. whatever it's running on, with the asm.js code doesn't need to know or care about). A runtime that doesn't support asm.js will just run the code like it did before. My point is that asm.js is every bit as capable of fully optimizing for the host as NaCl. It has two big advantages over NaCl, though. One is that it's architecture-independent: the host knows what architecture it uses, and (assuming it has the compiler, which an asm.js-supporting runtime has by definition) can act accordingly, taking full advantage of its own features. The other advantage is that there's a fallback even in case the runtime doesn't support asm.js: it's no faster than ordinary JavaScript in this case, but at least it does no harm.
rayiner 14y ago
See: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test...
mtgx 14y ago
ARMv15? Is that a new architecture after ARMv8? Do you have a link on it?