5 ms·

> It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. It is most definitely JavaScript. It runs perfectly in other browsers - in fact it o

by azakai 14y ago

> It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. It is most definitely JavaScript. It runs perfectly in other browsers - in fact it often runs faster than non-asm.js compiled code, so it is worthwhile even without new optimizations for it. It is also, in addition, optimizable like a low-level VM. > Maybe on the web we'll get NaCL to serve the same purpose. asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what?

pifflesnort 14y ago
> It is most definitely JavaScript. It runs perfectly in other browsers - in fact it often runs faster than non-asm.js compiled code, so it is worthwhile even without new optimizations for it. It can only run at speed if you interpret it as something that is not JavaScript. In other words, the fact that it's valid JavaScript is essentially pointless, because it's totally useless (relative to actual native applications) unless you interpret it as something that's not JavaScript. > asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what? Stupid bytecode format aside (which incurs a cost for every single VM implementor, tool implementor, and developer that has to use the language, forever) ... Here's a simple example: You can use NEON directly from NaCL/ARM. This matters on mobile. A lot. Is asm.js going to define NEON and SSE intrinsics, too? If so, why the hell isn't asm.js just another output target for (P)NaCL so that people with Internet Explorer can run really really really really slow applications? Or, how about the fact that NaCL can output ARM and x86 binaries directly, such that one doesn't need to AOT compile on every user's system, or introduce the cost, complexity, and overhead of JIT, when targeting standard/popular architectures. How about this one -- I was going to write something up asking about thread-local storage and %gs-relative loads, or architecture-specific atomic operations on shared state, but then I realized -- asm.js doesn't define a threading model. At all. Unless I'm mistaken, it can't, because JavaScript itself doesn't define a shared state threading model.
- azakai 14y ago
  > It can only run at speed if you interpret it as something that is not JavaScript. By that argument any JS JIT is "no longer JS". All JS JITS find cases where JS can be optimized as something simpler. For example CrankShaft and TraceMonkey find areas where variables are simply-typed and heavily optimize those. This isn't surprising - to make JS be fast, you do need to find where you can make it go faster, by avoiding the "normal" JS dynamism where anything is possible. So the JIT optimizes it as something that is "not JS". Again, nothing new with asm.js there, JS JITs have been doing this since 2008 (and JITs in other languages far earlier). > You can use NEON directly from NaCL/ARM [..] NaCL can output ARM and x86 binaries directly Those are not portable, which JS must be. A better comparison might be PNaCl, which is like NaCl but has an intermediary portable format. PNaCl will of course have the same issues asm.js does with not having direct binaries that can just be loaded and run, not allowing use of CPU-specific code, etc. If you don't care for portability, then the web/JS/asm.js/WebGL/etc etc. are likely not the best thing for you. Instead, a native app could make more sense.
  - pifflesnort 14y ago
    > By that argument any JS JIT is "no longer JS". JS JIT is an internal implementation detail. If a JIT exposed its internal bytecode (assuming it has one), you certainly wouldn't call it JavaScript. asm.js's strict requirements expose that implementation detail. To make asm.js useful, you can't treat it as JS, in which case the fact that it's javascript is a pointless burden on the entire target community of developers and users. > Those are not portable, which JS must be. Users don't care about whether a particular application uses non-portable optimization strategies, they care about battery life and application performance. If that means I have to use NEON on ARM, SSE on x86, and provide a portable fallback implementation, then so be it -- as a developer, that's my job. As a platform/OS vendor, your job is to make it possible for me to provide the best available user experience on the market. This isn't the web development space; we can't just tell users to go get faster hardware, the way web developers tell IT to go get faster/bigger servers. > PNaCl will of course have the same issues asm.js does with not having direct binaries that can just be loaded and run, not allowing use of CPU-specific code, etc. You can target x86 and ARM specifically (which are likely to be the only architectures that matter for the next 5 years), and fallback to PNaCL for everyone else. > If you don't care for portability, then the web/JS/asm.js/WebGL/etc etc. are likely not the best thing for you. I don't care about sacrificing user experience for some irrational slavish devotion to JavaScript. Of course I want portability, but not at the cost of providing the best user experience on the market.

by azakai 14y ago

pifflesnort 14y ago

> It is most definitely JavaScript. It runs perfectly in other browsers - in fact it often runs faster than non-asm.js compiled code, so it is worthwhile even without new optimizations for it. It can only run at speed if you interpret it as something that is not JavaScript. In other words, the fact that it's valid JavaScript is essentially pointless, because it's totally useless (relative to actual native applications) unless you interpret it as something that's not JavaScript. > asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what? Stupid bytecode format aside (which incurs a cost for every single VM implementor, tool implementor, and developer that has to use the language, forever) ... Here's a simple example: You can use NEON directly from NaCL/ARM. This matters on mobile. A lot. Is asm.js going to define NEON and SSE intrinsics, too? If so, why the hell isn't asm.js just another output target for (P)NaCL so that people with Internet Explorer can run really really really really slow applications? Or, how about the fact that NaCL can output ARM and x86 binaries directly, such that one doesn't need to AOT compile on every user's system, or introduce the cost, complexity, and overhead of JIT, when targeting standard/popular architectures. How about this one -- I was going to write something up asking about thread-local storage and %gs-relative loads, or architecture-specific atomic operations on shared state, but then I realized -- asm.js doesn't define a threading model. At all. Unless I'm mistaken, it can't, because JavaScript itself doesn't define a shared state threading model.

azakai 14y ago
> It can only run at speed if you interpret it as something that is not JavaScript. By that argument any JS JIT is "no longer JS". All JS JITS find cases where JS can be optimized as something simpler. For example CrankShaft and TraceMonkey find areas where variables are simply-typed and heavily optimize those. This isn't surprising - to make JS be fast, you do need to find where you can make it go faster, by avoiding the "normal" JS dynamism where anything is possible. So the JIT optimizes it as something that is "not JS". Again, nothing new with asm.js there, JS JITs have been doing this since 2008 (and JITs in other languages far earlier). > You can use NEON directly from NaCL/ARM [..] NaCL can output ARM and x86 binaries directly Those are not portable, which JS must be. A better comparison might be PNaCl, which is like NaCl but has an intermediary portable format. PNaCl will of course have the same issues asm.js does with not having direct binaries that can just be loaded and run, not allowing use of CPU-specific code, etc. If you don't care for portability, then the web/JS/asm.js/WebGL/etc etc. are likely not the best thing for you. Instead, a native app could make more sense.
- pifflesnort 14y ago
  > By that argument any JS JIT is "no longer JS". JS JIT is an internal implementation detail. If a JIT exposed its internal bytecode (assuming it has one), you certainly wouldn't call it JavaScript. asm.js's strict requirements expose that implementation detail. To make asm.js useful, you can't treat it as JS, in which case the fact that it's javascript is a pointless burden on the entire target community of developers and users. > Those are not portable, which JS must be. Users don't care about whether a particular application uses non-portable optimization strategies, they care about battery life and application performance. If that means I have to use NEON on ARM, SSE on x86, and provide a portable fallback implementation, then so be it -- as a developer, that's my job. As a platform/OS vendor, your job is to make it possible for me to provide the best available user experience on the market. This isn't the web development space; we can't just tell users to go get faster hardware, the way web developers tell IT to go get faster/bigger servers. > PNaCl will of course have the same issues asm.js does with not having direct binaries that can just be loaded and run, not allowing use of CPU-specific code, etc. You can target x86 and ARM specifically (which are likely to be the only architectures that matter for the next 5 years), and fallback to PNaCL for everyone else. > If you don't care for portability, then the web/JS/asm.js/WebGL/etc etc. are likely not the best thing for you. I don't care about sacrificing user experience for some irrational slavish devotion to JavaScript. Of course I want portability, but not at the cost of providing the best user experience on the market.