5 ms·

I don't see why it's not a fair comparison? V8 doesn't have any specific optimizations for asm.js, opting instead to focus on optimizing JavaScript as a whole

by Drakim 12y ago

I don't see why it's not a fair comparison? V8 doesn't have any specific optimizations for asm.js, opting instead to focus on optimizing JavaScript as a whole (which asm.js also benefits from). That's their choice, and this is the result of that.

coldtea 12y ago
>I don't see why it's not a fair comparison? Because nobody (for large values of "nobody") cares for asm.js. 99.999% of Javascript code out there is not asm.js, and nobody really uses it at the moment for production/business. Some PoC games mainly. So the fact that it beats V8 on something: a) V8 does not implement, b) requires specifically written (actually "compiled" from things like emscripten) JS code, c) is irrelevant at the moment for JS performance on the web, makes it pretty irrelevant itself.
- Drakim 12y ago
  Maybe irrelevant today, but maybe not irrelevant tomorrow. JavaScript is what the web "runs on", and if Firefox might in the future provide the fastest way to run JavaScript. Obviously for most cases that isn't going to be that relevant, but I can imagine a situation where you have Photoshop-in-the-browser and it runs better on Firefox due asm.js.
- sitkack 12y ago
  It isn't irrelevant at all. Anyone is free to write high performance code that does the same things that emscripten does. "use asm"; Is a protocol convention. There isn't anything special about it. Everything is regular javascript and all javascript engines support it. I use it for non-game PoCs. Why do you care about V8 trying to be fast? Looks like JSC and Ion are beating them. JSC has no special "use asm" path.
- cpeterso 12y ago
  JSC does not implement asm.js any more than V8.
- azakai 12y ago
  > Because nobody (for large values of "nobody") cares for asm.js. The most important games companies - Unity, Epic, etc. - care very much about asm.js. Unity is going into beta very soon. Expect to see games after that. > So the fact that it beats V8 on something: a) V8 does not implement jsc also does not "implement" asm.js, in the sense that both v8 and jsc do not detect asm.js code specifically using the asm.js type system. Yet, jsc beats v8. asm.js code is going to matter because games matter. Those games are using plugins now, but plugins are going away, and asm.js is the best option after that - that's why the games industry is adopting it.
  - teacup50 12y ago
    Actually, NaCL is the best option after that, but you fine folks at Mozilla refuse to play ball.
    - azakai 12y ago
      I don't think that's a fair way to describe things - for one thing, NaCl is not portable, and PNaCl (which is) took years to materialize, at a point in time when it is not clear which option is better between PNaCl and JS.
  - mike_hearn 12y ago
    Games are not "using plugins" today. They are either shipped as console games on DVDs/BluRays, or as native apps you download and run either for PC/Mac/tablet OS's. asm.js is a bizarre hack. You're sending someone assembly code for a CPU that doesn't exist, as text. It would have been far superior to just figure out CPU family specific sandboxes as NaCL did, and then accept that only two CPU architectures matter these days: x86 and ARM. If you can sandbox both, you're done and if someone wants to invent some super-duper new ISA they can damn well make code easily sandboxed when they design it.
- indolering 12y ago
  ASM enables developers to run code at an order-of-magnitude as fast as native. This in-and-of-itself is important. While 99.999% of JavaScript may not be transcompiled from LLVM, that doesn't mean it isn't a powerful tool. Apple may not care about such use cases. The fact that they could get ASM speedups for free is pretty cool. : )
- om2 12y ago
  If you care a lot about 99.9999% of web code, as in code found on real webpages, try JSBench <http://jsbench.cs.purdue.edu> http://jsbench.cs.purdue.edu>. It's the only JS benchmark made from JS found in actual real-world production webpages. JavaScriptCore clocks all the other JS engines on it by a ridiculous margin. It's neat that V8 is fast on long-running code that's not asm.js, but it's wrong to extrapolate that to most real-world web code.

by Drakim 12y ago

coldtea 12y ago

>I don't see why it's not a fair comparison? Because nobody (for large values of "nobody") cares for asm.js. 99.999% of Javascript code out there is not asm.js, and nobody really uses it at the moment for production/business. Some PoC games mainly. So the fact that it beats V8 on something: a) V8 does not implement, b) requires specifically written (actually "compiled" from things like emscripten) JS code, c) is irrelevant at the moment for JS performance on the web, makes it pretty irrelevant itself.

Drakim 12y ago
Maybe irrelevant today, but maybe not irrelevant tomorrow. JavaScript is what the web "runs on", and if Firefox might in the future provide the fastest way to run JavaScript. Obviously for most cases that isn't going to be that relevant, but I can imagine a situation where you have Photoshop-in-the-browser and it runs better on Firefox due asm.js.
sitkack 12y ago
It isn't irrelevant at all. Anyone is free to write high performance code that does the same things that emscripten does. "use asm"; Is a protocol convention. There isn't anything special about it. Everything is regular javascript and all javascript engines support it. I use it for non-game PoCs. Why do you care about V8 trying to be fast? Looks like JSC and Ion are beating them. JSC has no special "use asm" path.
cpeterso 12y ago
JSC does not implement asm.js any more than V8.
azakai 12y ago
> Because nobody (for large values of "nobody") cares for asm.js. The most important games companies - Unity, Epic, etc. - care very much about asm.js. Unity is going into beta very soon. Expect to see games after that. > So the fact that it beats V8 on something: a) V8 does not implement jsc also does not "implement" asm.js, in the sense that both v8 and jsc do not detect asm.js code specifically using the asm.js type system. Yet, jsc beats v8. asm.js code is going to matter because games matter. Those games are using plugins now, but plugins are going away, and asm.js is the best option after that - that's why the games industry is adopting it.
- teacup50 12y ago
  Actually, NaCL is the best option after that, but you fine folks at Mozilla refuse to play ball.
  - azakai 12y ago
    I don't think that's a fair way to describe things - for one thing, NaCl is not portable, and PNaCl (which is) took years to materialize, at a point in time when it is not clear which option is better between PNaCl and JS.
- mike_hearn 12y ago
  Games are not "using plugins" today. They are either shipped as console games on DVDs/BluRays, or as native apps you download and run either for PC/Mac/tablet OS's. asm.js is a bizarre hack. You're sending someone assembly code for a CPU that doesn't exist, as text. It would have been far superior to just figure out CPU family specific sandboxes as NaCL did, and then accept that only two CPU architectures matter these days: x86 and ARM. If you can sandbox both, you're done and if someone wants to invent some super-duper new ISA they can damn well make code easily sandboxed when they design it.
indolering 12y ago
ASM enables developers to run code at an order-of-magnitude as fast as native. This in-and-of-itself is important. While 99.999% of JavaScript may not be transcompiled from LLVM, that doesn't mean it isn't a powerful tool. Apple may not care about such use cases. The fact that they could get ASM speedups for free is pretty cool. : )
om2 12y ago
If you care a lot about 99.9999% of web code, as in code found on real webpages, try JSBench <http://jsbench.cs.purdue.edu> http://jsbench.cs.purdue.edu>. It's the only JS benchmark made from JS found in actual real-world production webpages. JavaScriptCore clocks all the other JS engines on it by a ridiculous margin. It's neat that V8 is fast on long-running code that's not asm.js, but it's wrong to extrapolate that to most real-world web code.