18 ms·

> No, it's ~2x slower with the early prototype. It will get significantly faster than that. And we just need hardware XML accelerators and then XML will be gre

> No, it's ~2x slower with the early prototype. It will get significantly faster than that. And we just need hardware XML accelerators and then XML will be great. This is not a new refrain from people who promote a subpar technology stack. Quality is just around the corner! We swear! I'll believe it when I see it, and I'll be happy, because it'll mean that we're finally that much closer to the next step of dropping JavaScript as a first-order target entirely. > The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js. It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. The bytecode is an inefficient ASCII representation which happens to be interpretable as JS, but can't be interpreted as JS to actually be implemented efficiently -- which is to say, it's not really useful JS at all. You may as well write a shell-script based ARM interpreter and call your ARM assembly "shell script". True, in a fashion, but also a totally pointless distinction. Everybody else will just call it "slow". > ~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point. Android has the NDK for a reason, and even they are starting from a better position than trying to eek out runtime+rendering performance from an in-browser bytecode. Maybe on the web we'll get NaCL to serve the same purpose. It'll be great if it all works out and we wind up with a cross-platform efficient and useful development target, with robust view management and event systems and common widget toolkits. Of course, at that point the web will look pretty much like the application development environments that we've been targeting for decades: operating systems.

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.

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.