5 ms·

Is this accurate? My understanding was that the V8 team wasn't explicitly optimizing for asm.js, and just optimized V8 in general (and that often asm.js hit fas

Is this accurate? My understanding was that the V8 team wasn't explicitly optimizing for asm.js, and just optimized V8 in general (and that often asm.js hit fast-paths even without explicit optimization). It sounds from the article like Epic announced that Chrome/V8 is fast enough to run the Unreal 3 engine, and Mozilla's trying to spin it as V8 explicitly optimized for a "spec" invented by Mozilla when actually they just made V8 really, really fast. That said, they do include an asm.js benchmark in Octane 2, so it's clearly on their radar. But as far as I've heard they haven't actually implemented special asm.js typecheckers / AOT compilers like Mozilla has.

azakai 13y ago
Not sure where you see "spec" mentioned in there? As you say, Google included asm.js code in Octane 2, and you can see progress on asm.js benchmarks as Google optimizes in ways that help that style of code on arewefastyet, http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=11&view=breakdown&suite=asm... This is also not something new, Google has optimized for asm.js code since the IO keynote much earlier this year where Google reported a 2.4x speedup on an aggregate asm.js benchmark, http://culturemass.com/2013/05/17/google-io-2013-keynote-part-ii/ http://culturemass.com/2013/05/17/google-io-2013-keynote-par... There are many ways to optimize for different types of code. Firefox uses the asm.js type system for asm.js, and does AOT compilation, while Chrome chose a different approach. The two approaches have different benefits. But both browsers certainly optimize for asm.js, they both announced doing so and the numbers are proof that they are succeeding. edit: add link to Octane 2.0 and the asm.js benchmark added there, http://blog.chromium.org/2013/11/announcing-octane-20.html http://blog.chromium.org/2013/11/announcing-octane-20.html
- rictic 13y ago
  Even before asm.js there was emscripten (the primary generator of asm.js and inspiration for much of the spec), which has been used for a number of high profile demos and likely got optimization attention for years before asm.js.
  - cpeterso 13y ago
    I'm sure azakai is familiar with emscripten. ;)
    - girvo 13y ago
      This doesn't happen anywhere except on HN. I check parents profile before I ever reply for this reason ;)
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
- cromwellian 13y ago
  When we released gwtquake it ran poorly on FF and the FF team seems to have spent some time optimizing for it. Imagine a press release boasting how FF optimizes for GWT. This press release is a little heavy on spin trying to market asmjs. While it does appear V8 is speeding up asmjs style code, until we know specifically about what they've done in chrome 31/32, this seems mostly like speculation. What if in fact asmjs was causing a degenerate case in their JIT and what they actually did amounted to fixing some bugs?
  - pcwalton 13y ago
    > What if in fact asmjs was causing a degenerate case in their JIT and what they actually did amounted to fixing some bugs? I don't see how that's any different from optimizing for asm.js. Optimization is often about fixing bugs.
micro_cam 13y ago
I ran the demo in chrome not that long after it was released and recall the frame rate being almost as good as in the recommended firefox nightly builds. There was some visual weirdness (polygons being missing/transparent). I expect Epic's announcement is more about these glitches being resolved then performance increases. Mozilla's is pure spin.
- jlongster 13y ago
  That's not true, if you ran it in Chrome it was extremely laggy, but you must have caught it after they implemented a lot of asm.js optimizations. You can see when they focused on asm.js-style code here in these graphs: http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=11&view=breakdown&suite=asm.... Just look at the drop off of the green line!
  - mraleph 13y ago
    I also suggest zooming into those graphs to see which changes lead to drops (at least those that are currently visible). Then you could try to explain people what asm.js specific is in changes like: https://code.google.com/p/v8/source/detail?r=14658 https://code.google.com/p/v8/source/detail?r=14658 and https://code.google.com/p/v8/source/detail?r=15147 https://code.google.com/p/v8/source/detail?r=15147 [hint: nothing, they have more to do with how Emscripten has a tendency to produce extremely big functions which no human would write, and JIT has to accomodate for that to hit them in correct moment and not give up on them. Once it hits them however the optimizations that were there for ages, optimizations purely based on JavaScript semantics, start doing what they are intended to do --- make JavaScript run fast]
- bad_user 13y ago
  Not sure what computer you ran the demo on, but the Unreal Engine demo on top of Chrome was unusable on my laptop (talking about 2-5 fps), whereas in Firefox it was extremely smooth and this was when Firefox 22 was released (so it was the stable release, not the nightlies). EDIT: I just ran that demo in Chrome, on the same computer as before and it did improve a lot (getting 50-60 fps in full screen HD), though it still seems smoother in Firefox. Competition is great.

azakai 13y ago

Not sure where you see "spec" mentioned in there? As you say, Google included asm.js code in Octane 2, and you can see progress on asm.js benchmarks as Google optimizes in ways that help that style of code on arewefastyet, http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=11&view=breakdown&suite=asm... This is also not something new, Google has optimized for asm.js code since the IO keynote much earlier this year where Google reported a 2.4x speedup on an aggregate asm.js benchmark, http://culturemass.com/2013/05/17/google-io-2013-keynote-part-ii/ http://culturemass.com/2013/05/17/google-io-2013-keynote-par... There are many ways to optimize for different types of code. Firefox uses the asm.js type system for asm.js, and does AOT compilation, while Chrome chose a different approach. The two approaches have different benefits. But both browsers certainly optimize for asm.js, they both announced doing so and the numbers are proof that they are succeeding. edit: add link to Octane 2.0 and the asm.js benchmark added there, http://blog.chromium.org/2013/11/announcing-octane-20.html http://blog.chromium.org/2013/11/announcing-octane-20.html

rictic 13y ago
Even before asm.js there was emscripten (the primary generator of asm.js and inspiration for much of the spec), which has been used for a number of high profile demos and likely got optimization attention for years before asm.js.
- cpeterso 13y ago
  I'm sure azakai is familiar with emscripten. ;)
  - girvo 13y ago
    This doesn't happen anywhere except on HN. I check parents profile before I ever reply for this reason ;)
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
cromwellian 13y ago
When we released gwtquake it ran poorly on FF and the FF team seems to have spent some time optimizing for it. Imagine a press release boasting how FF optimizes for GWT. This press release is a little heavy on spin trying to market asmjs. While it does appear V8 is speeding up asmjs style code, until we know specifically about what they've done in chrome 31/32, this seems mostly like speculation. What if in fact asmjs was causing a degenerate case in their JIT and what they actually did amounted to fixing some bugs?
- pcwalton 13y ago
  > What if in fact asmjs was causing a degenerate case in their JIT and what they actually did amounted to fixing some bugs? I don't see how that's any different from optimizing for asm.js. Optimization is often about fixing bugs.

micro_cam 13y ago

I ran the demo in chrome not that long after it was released and recall the frame rate being almost as good as in the recommended firefox nightly builds. There was some visual weirdness (polygons being missing/transparent). I expect Epic's announcement is more about these glitches being resolved then performance increases. Mozilla's is pure spin.

jlongster 13y ago
That's not true, if you ran it in Chrome it was extremely laggy, but you must have caught it after they implemented a lot of asm.js optimizations. You can see when they focused on asm.js-style code here in these graphs: http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=11&view=breakdown&suite=asm.... Just look at the drop off of the green line!
- mraleph 13y ago
  I also suggest zooming into those graphs to see which changes lead to drops (at least those that are currently visible). Then you could try to explain people what asm.js specific is in changes like: https://code.google.com/p/v8/source/detail?r=14658 https://code.google.com/p/v8/source/detail?r=14658 and https://code.google.com/p/v8/source/detail?r=15147 https://code.google.com/p/v8/source/detail?r=15147 [hint: nothing, they have more to do with how Emscripten has a tendency to produce extremely big functions which no human would write, and JIT has to accomodate for that to hit them in correct moment and not give up on them. Once it hits them however the optimizations that were there for ages, optimizations purely based on JavaScript semantics, start doing what they are intended to do --- make JavaScript run fast]
bad_user 13y ago
Not sure what computer you ran the demo on, but the Unreal Engine demo on top of Chrome was unusable on my laptop (talking about 2-5 fps), whereas in Firefox it was extremely smooth and this was when Firefox 22 was released (so it was the stable release, not the nightlies). EDIT: I just ran that demo in Chrome, on the same computer as before and it did improve a lot (getting 50-60 fps in full screen HD), though it still seems smoother in Firefox. Competition is great.