6 ms·

> 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 w

> 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.
  - azakai 14y ago
    > JS JIT is an internal implementation detail asm.js optimizations are also an internal implementation detail. You don't need to do them, and the code still runs fast. Or you can do them in a variety of ways, not just the one being tested in Firefox. In fact I argued for optimizing in a very different way originally. The point of asm.js is that it ensures you don't do things like use multiple types in a single variable, avoid undefined values cropping up, etc. That helps JS JITs in general, both existing ones as well as new optimizations made more feasible by the approach. So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth). > Users don't care about whether a particular application uses non-portable optimization strategies Of course users do. A portable application would be runnable from all the users' devices, that's a huge plus. Just like users want to play their music from their iPod, laptop, TV, etc., they want to run their apps on all their devices as well. Portability makes that possible. > 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. That's a big compromise. If we had done that before the rise of ARM, for example, ARM might never have achieved its current success. But anyhow, of course there are different compromises to be made. The web and JS focus on true portability, with its downsides. If you personally are willing to compromise more to get better performance, then sure, another option might be better for you.
pcwalton 14y ago
Slow is not always "totally useless". It just degrades gracefully. Furthermore, the fact that it's based on JS makes the integration with the DOM much easier. The bytecode format is not as big of a deal as you claim. 1,000 lines of code for the verifier. There's nothing intrinsic to JS that forbids having SIMD support. In fact, it's under active discussion... Having two back ends for PNaCl seems suboptimal. Why force all Web developers to generate two bytecode formats because we don't like the way asm.js looks? AOT compilation isn't a panacea. You still have to verify it. So it's not like the NDK could just be adopted to the Web as is. Besides, caching can mitigate the startup costs a lot. Finally, JS has threading, and it could grow shared state threading in the future. This doesn't strike me as that big of an obstacle.
- pifflesnort 14y ago
  > Slow is not always "totally useless". It just degrades gracefully. Slow isn't graceful, especially when your competitors aren't slow. I look forward to Mozilla advertising Firefox as "only 10x slow as Chrome!". In this case, it's even worse, because if asm.js is successful, then the fallback mechanism will simply become an awkward vestigial limb that's no longer required by any modern browser. Treat a vestigial limb as your first-order target is silly. > Having two back ends for PNaCl seems suboptimal. Why force all Web developers to generate two bytecode formats because we don't like the way asm.js looks? Because it's about users, not about developers. Generating optimized binaries means that users have a better user experience. > Finally, JS has threading, and it could grow shared state threading in the future. This doesn't strike me as that big of an obstacle. "I'll pay you tomorrow for a hamburger today" is getting old.
  - pcwalton 14y ago
    Slower is far better than not running at all. Backwards compatibility is how Web technologies (and, for that matter, most technologies--x86 for example) survive. And asm.js' encoding has no impact on the user experience. That's precisely my point. Using a binary bytecode instead of interoperable JS would maybe make the parsing easier, but that doesn't make up for the costs this would burden developers with (not to mention the difficulties with two VMs sharing data and so forth, something which is terribly important but is always glossed over in these conversations). Finally, regarding threads, we're talking about a new proposed standard here. There will always be work to do, since just taking the NDK and putting it on the Web is not an option. PNaCl isn't shipping yet. So the question is whether asm.js presents a shorter, more straightforward path to success than the alternatives. I believe it does.

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.
- azakai 14y ago
  > JS JIT is an internal implementation detail asm.js optimizations are also an internal implementation detail. You don't need to do them, and the code still runs fast. Or you can do them in a variety of ways, not just the one being tested in Firefox. In fact I argued for optimizing in a very different way originally. The point of asm.js is that it ensures you don't do things like use multiple types in a single variable, avoid undefined values cropping up, etc. That helps JS JITs in general, both existing ones as well as new optimizations made more feasible by the approach. So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth). > Users don't care about whether a particular application uses non-portable optimization strategies Of course users do. A portable application would be runnable from all the users' devices, that's a huge plus. Just like users want to play their music from their iPod, laptop, TV, etc., they want to run their apps on all their devices as well. Portability makes that possible. > 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. That's a big compromise. If we had done that before the rise of ARM, for example, ARM might never have achieved its current success. But anyhow, of course there are different compromises to be made. The web and JS focus on true portability, with its downsides. If you personally are willing to compromise more to get better performance, then sure, another option might be better for you.

pcwalton 14y ago

Slow is not always "totally useless". It just degrades gracefully. Furthermore, the fact that it's based on JS makes the integration with the DOM much easier. The bytecode format is not as big of a deal as you claim. 1,000 lines of code for the verifier. There's nothing intrinsic to JS that forbids having SIMD support. In fact, it's under active discussion... Having two back ends for PNaCl seems suboptimal. Why force all Web developers to generate two bytecode formats because we don't like the way asm.js looks? AOT compilation isn't a panacea. You still have to verify it. So it's not like the NDK could just be adopted to the Web as is. Besides, caching can mitigate the startup costs a lot. Finally, JS has threading, and it could grow shared state threading in the future. This doesn't strike me as that big of an obstacle.

pifflesnort 14y ago
> Slow is not always "totally useless". It just degrades gracefully. Slow isn't graceful, especially when your competitors aren't slow. I look forward to Mozilla advertising Firefox as "only 10x slow as Chrome!". In this case, it's even worse, because if asm.js is successful, then the fallback mechanism will simply become an awkward vestigial limb that's no longer required by any modern browser. Treat a vestigial limb as your first-order target is silly. > Having two back ends for PNaCl seems suboptimal. Why force all Web developers to generate two bytecode formats because we don't like the way asm.js looks? Because it's about users, not about developers. Generating optimized binaries means that users have a better user experience. > Finally, JS has threading, and it could grow shared state threading in the future. This doesn't strike me as that big of an obstacle. "I'll pay you tomorrow for a hamburger today" is getting old.
- pcwalton 14y ago
  Slower is far better than not running at all. Backwards compatibility is how Web technologies (and, for that matter, most technologies--x86 for example) survive. And asm.js' encoding has no impact on the user experience. That's precisely my point. Using a binary bytecode instead of interoperable JS would maybe make the parsing easier, but that doesn't make up for the costs this would burden developers with (not to mention the difficulties with two VMs sharing data and so forth, something which is terribly important but is always glossed over in these conversations). Finally, regarding threads, we're talking about a new proposed standard here. There will always be work to do, since just taking the NDK and putting it on the Web is not an option. PNaCl isn't shipping yet. So the question is whether asm.js presents a shorter, more straightforward path to success than the alternatives. I believe it does.