4 ms·

> I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.). I included ones you could, such a NaCL. And I s

by pbsdp 13y ago

> I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.). I included ones you could, such a NaCL. And I should probably have also included the native platforms (Apple, MS, Google), because they're the competition, even if their sandboxing or runtime environment isn't what one might call 'state of the art'. At the end of the day, it's the two-tier universe that bothers me the most. You're content to foist the JS runtime on everyone but yourselves. Once you implement Firefox entirely as an application running in a JS VM, the argument that JS is good enough might carry some weight.

azakai 13y ago
The point is that NaCl is not portable, just like a native platform such as Windows. Nonportable native platforms are there, you can write apps for them. They are even the dominant platforms on mobile. But the web's entire purpose for existing is to be portable. So you do need something like JS or PNaCl or the JVM. And all of those, due to being portable and secure, impose limitations, such as limiting the native operations that you perform. That's unavoidable. But again, if you don't like that, develop directly for a native platform.
- pbsdp 13y ago
  > The point is that NaCl is not portable, just like a native platform such as Windows. So provide fat binaries. Maximize performance on ARM and i386, with fallback to PNaCL for future platforms that are neither. > They are even the dominant platforms on mobile. For a good reason. Adopting their strengths while eschewing their weaknesses (proprietary and single-vendor) would benefit the entire industry greatly.
  - azakai 13y ago
    Fat binaries are limited, and people will simply provide the parts for the platforms they currently care about, without care for future platforms. That's fine for most things, but web content is something that we do want to always be accessible. It is hard to adopt the strengths of native execution using all the lowest-level tweaks specific to one platform, because that inherently limit portability by definition (and often also security). I share your goals, but don't think there is an obvious better compromise than the one we are all already making on the web.
    - slacka 13y ago
      The teams at Mozilla and Google have done an amazing job of improving JavaScript performance. But, I also have to agree with PBS, that Mozilla has a knee-jerk reaction to many of Google’s promising technologies like WebP and PNaCl. Like many HTML5 technologies that are being shoehorned into areas they were not originally designed for, JS was never meant to be a bytecode and likely will never be able to achieve the performance possible with PNaCl. If W3C and WHATWG were competent and delivered a viable web application platform, we wouldn't be hiring Android and iOS developers now. Mozilla needs to be more open to new technologies like PNaCl that enable the web to be competitive.
      - azakai 13y ago
        I don't think "knee-jerk" is a fair description. Consider the collaboration between Google and Mozilla on WebM, WebRTC, and countless others. > JS was never meant to be a bytecode and likely will never be able to achieve the performance possible with PNaCl. LLVM IR was also never meant to be a bytecode. But in both the case of JS and LLVM IR, the question is the final result, not the original intention, even if the two are often connected. > Mozilla needs to be more open to new technologies like PNaCl that enable the web to be competitive. PNaCl is not even shipped, so it is too early to evaluate it. But the last benchmarks I saw for compilation speed and performance were mixed. (NaCl is much more proven, but NaCl is not portable.)
      - pcwalton 13y ago
        > JS was never meant to be a bytecode Neither was LLVM IR, if you mean "portable bytecode". Both asm.js and PNaCl are using the technologies in ways they were not originally designed for.
comex 13y ago
> I included ones you could, such a NaCL. You cannot do it in NaCl, as being able to map pages rwx would break the security model.
- pbsdp 13y ago
  All you need to do is perform NaCL validation of pages before marking them executable; this is what NaCL already does. You can either do this through a high-level "JIT API" that generates safe machine code from a validated IR (aka PNaCL), or through a fancier version of mprotect() that validates the actual machine code (aka NaCL). In a wondrous hypothetical future where processors support a NaCL restricted operating mode, you wouldn't even need to validate; just set the processor state to thumb^Wnacl mode, and define a syscall instruction that switches to direct execution (without actually requiring a context switch to the kernel, just flip an execution flag). This is why NaCL is so damn interesting, and JS/asm.js is not. NaCL has the possibility of turning our design of restricted execution environments on its head, in a very good (for performance) way.
  - comex 13y ago
    You can already do that with NaCl - or even asm.js with eval, I bet it wouldn't be that much slower. But current JITs apparently gain a significant amount of performance with inline caching, which expects code to be able to be rewritten very quickly. Edit to respond to your edit: although it would be cool to be able to have a "sandboxed mode" that can somehow be switched out of more cheaply than an interrupt, the whole thing seems like a massive hack to me. After all, NaCl does not take advantage of its pseudo-ability to do so: NaCl code runs in its own process and already incurs a context switch whenever it communicates with the browser, so there is no inherent hardware reason NaCl couldn't just run directly under the kernel and have the kernel provide the same level of sandboxing as the NaCl runtime currently does. It's just an issue of getting such an approach to work portably with existing kernels... hardware support might be able to make it easier to get that to work, but it's probably unnecessary.
  - azakai 13y ago
    > In a wondrous hypothetical future where processors support a NaCL restricted operating mode If we speculate wildly, why not an "asm.js restricted operating mode"? Not saying that's a good idea, but I'm not sure why a NaCl one would be either. Both PNaCl and asm.js should reach pretty much native speed anyhow. Btw, the L is not capitalized in NaCl.

by pbsdp 13y ago

azakai 13y ago

The point is that NaCl is not portable, just like a native platform such as Windows. Nonportable native platforms are there, you can write apps for them. They are even the dominant platforms on mobile. But the web's entire purpose for existing is to be portable. So you do need something like JS or PNaCl or the JVM. And all of those, due to being portable and secure, impose limitations, such as limiting the native operations that you perform. That's unavoidable. But again, if you don't like that, develop directly for a native platform.

pbsdp 13y ago
> The point is that NaCl is not portable, just like a native platform such as Windows. So provide fat binaries. Maximize performance on ARM and i386, with fallback to PNaCL for future platforms that are neither. > They are even the dominant platforms on mobile. For a good reason. Adopting their strengths while eschewing their weaknesses (proprietary and single-vendor) would benefit the entire industry greatly.
- azakai 13y ago
  Fat binaries are limited, and people will simply provide the parts for the platforms they currently care about, without care for future platforms. That's fine for most things, but web content is something that we do want to always be accessible. It is hard to adopt the strengths of native execution using all the lowest-level tweaks specific to one platform, because that inherently limit portability by definition (and often also security). I share your goals, but don't think there is an obvious better compromise than the one we are all already making on the web.
  - slacka 13y ago
    The teams at Mozilla and Google have done an amazing job of improving JavaScript performance. But, I also have to agree with PBS, that Mozilla has a knee-jerk reaction to many of Google’s promising technologies like WebP and PNaCl. Like many HTML5 technologies that are being shoehorned into areas they were not originally designed for, JS was never meant to be a bytecode and likely will never be able to achieve the performance possible with PNaCl. If W3C and WHATWG were competent and delivered a viable web application platform, we wouldn't be hiring Android and iOS developers now. Mozilla needs to be more open to new technologies like PNaCl that enable the web to be competitive.
    - azakai 13y ago
      I don't think "knee-jerk" is a fair description. Consider the collaboration between Google and Mozilla on WebM, WebRTC, and countless others. > JS was never meant to be a bytecode and likely will never be able to achieve the performance possible with PNaCl. LLVM IR was also never meant to be a bytecode. But in both the case of JS and LLVM IR, the question is the final result, not the original intention, even if the two are often connected. > Mozilla needs to be more open to new technologies like PNaCl that enable the web to be competitive. PNaCl is not even shipped, so it is too early to evaluate it. But the last benchmarks I saw for compilation speed and performance were mixed. (NaCl is much more proven, but NaCl is not portable.)
    - pcwalton 13y ago
      > JS was never meant to be a bytecode Neither was LLVM IR, if you mean "portable bytecode". Both asm.js and PNaCl are using the technologies in ways they were not originally designed for.

comex 13y ago

> I included ones you could, such a NaCL. You cannot do it in NaCl, as being able to map pages rwx would break the security model.

pbsdp 13y ago
All you need to do is perform NaCL validation of pages before marking them executable; this is what NaCL already does. You can either do this through a high-level "JIT API" that generates safe machine code from a validated IR (aka PNaCL), or through a fancier version of mprotect() that validates the actual machine code (aka NaCL). In a wondrous hypothetical future where processors support a NaCL restricted operating mode, you wouldn't even need to validate; just set the processor state to thumb^Wnacl mode, and define a syscall instruction that switches to direct execution (without actually requiring a context switch to the kernel, just flip an execution flag). This is why NaCL is so damn interesting, and JS/asm.js is not. NaCL has the possibility of turning our design of restricted execution environments on its head, in a very good (for performance) way.
- comex 13y ago
  You can already do that with NaCl - or even asm.js with eval, I bet it wouldn't be that much slower. But current JITs apparently gain a significant amount of performance with inline caching, which expects code to be able to be rewritten very quickly. Edit to respond to your edit: although it would be cool to be able to have a "sandboxed mode" that can somehow be switched out of more cheaply than an interrupt, the whole thing seems like a massive hack to me. After all, NaCl does not take advantage of its pseudo-ability to do so: NaCl code runs in its own process and already incurs a context switch whenever it communicates with the browser, so there is no inherent hardware reason NaCl couldn't just run directly under the kernel and have the kernel provide the same level of sandboxing as the NaCl runtime currently does. It's just an issue of getting such an approach to work portably with existing kernels... hardware support might be able to make it easier to get that to work, but it's probably unnecessary.
- azakai 13y ago
  > In a wondrous hypothetical future where processors support a NaCL restricted operating mode If we speculate wildly, why not an "asm.js restricted operating mode"? Not saying that's a good idea, but I'm not sure why a NaCl one would be either. Both PNaCl and asm.js should reach pretty much native speed anyhow. Btw, the L is not capitalized in NaCl.