4 ms·

I don't see how opinion factors into this. Mozilla estimates a best case of 2x slower than native with asm.js, and that's with a strict JavaScript subset that

I don't see how opinion factors into this. Mozilla estimates a best case of 2x slower than native with asm.js, and that's with a strict JavaScript subset that defines a machine translatable byte-code, coupled with a proprietary runtime to do the translation. They estimate 10x slower without that proprietary translation. That's a ridiculous waste of resources, especially on battery-powered devices.

azakai 14y ago
> Mozilla estimates a best case of 2x slower than native with asm.js No, it's ~2x slower with the early prototype. It will get significantly faster than that. > a proprietary runtime 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. > That's a ridiculous waste of resources, especially on battery-powered devices. ~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.
- pifflesnort 14y ago
  > 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

> Mozilla estimates a best case of 2x slower than native with asm.js No, it's ~2x slower with the early prototype. It will get significantly faster than that. > a proprietary runtime 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. > That's a ridiculous waste of resources, especially on battery-powered devices. ~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.

pifflesnort 14y ago
> 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.