It's a bit unfair to mention Chrome performing poorly on these. Both are asm.js, which OdinMonkey is optimised for, V8 not.
That said, I'm very excited about asm.js (using it, in fact) and the performance in FF 22 blows me away as well. The V8 team appears to be working on asm.js optimisations, so soon we can have a fair contest :)
The best thing about asm.js is that the optimisations are really optional, unless your application is actually CPU-bound. The Unreal Engine probably is, to some degree. A simple 2D game like the one I'm working on certainly isn't. Not seeing it run any faster with FF 22, it's already smooth in older versions.
> It's a bit unfair to mention Chrome performing poorly on these. Both are asm.js, which OdinMonkey is optimised for, V8 not.
Actually Chrome has been optimizing for compiled C++ for a long time - Google even added Mandreel code to the Octane benchmark - and for asm.js specifically (which is a particular type of compiled C++) in recent months, as you can track here
From what I can tell, JavaScriptCore has had typed array support since at least as far back as December 2011 (http://trac.webkit.org/r103637, a random change in JavaScriptCore involving typed arrays).
Thanks for the info. Then I am really curious why awfy does not manage to run them properly. Perhaps it does not build JSC correctly somehow? I think that code is here
That looks like everything's being built and run in the correct way for OS X. Is there an easy way to run the benchmarks from that repository against my own WebKit working copy without having to set up all of the server-side support that the main README talks about? If I can run things locally I might be able to spot what's going awry with the asm.js tests for JSC.
I'm not familiar with building just JSC on Linux, but last time I looked in to it the only way to build JSC was as part of building all of WebKit.
Yeah, basically each benchmark there has a python script to run it. For example in benchmarks/asmjs-apps it is possible to run
python harness.py [SHELL_NAME]
and it runs all the benchmarks in that directory using that shell.
Regarding building, I've tried to build all of the Qt port on Linux (what the online guides mention), but always fail in the dependencies. Perhaps I'll try the gtk port.
Thanks for the pointer on running the tests. I noticed two big issues:
1. Some of the tests use shell functions like "read" that jsc doesn't provide. This is easy enough to address.
2. I was mistaken about the quality of the typed array support in JavaScriptCore. While the interpreter has knowledge of typed arrays, the actual implementation that's used when running in-browser lives in WebCore rather than in JavaScriptCore. When running in the shell only a bare minimum typed array implementation, primarily intended for JSC-only regression tests, is available. This trips up some tests since the implementation is much less complete than the one in WebCore.
Hmm, I am guessing the minimum implementation is also less performant (if it's just meant for regression tests)? So probably it would be unfair to measure on it.
I'm not sure about that. I'll follow up with some of my colleagues to see why typed arrays are in such an state.
Am I correct in assuming that if JavaScriptCore starts successfully executing the tests, it'll automatically start showing up on the relevant part of arewefastyet.com?
I am not sure about automatically showing up, but that would be my guess. I can ask dvander (who runs awfy) for more details if that would be useful. In any case probably it is very easy to change (disable/enable).
That said, I'm very excited about asm.js (using it, in fact) and the performance in FF 22 blows me away as well. The V8 team appears to be working on asm.js optimisations, so soon we can have a fair contest :)
The best thing about asm.js is that the optimisations are really optional, unless your application is actually CPU-bound. The Unreal Engine probably is, to some degree. A simple 2D game like the one I'm working on certainly isn't. Not seeing it run any faster with FF 22, it's already smooth in older versions.