Hacker News Reader

Comment by niutech | Hacker News Reader

The OdinMonkey engine performance is impressive. The Lua VM benchmark[1] jumped from 110 points in Firefox 21 to 318 points in Firefox 22! Not to mention poor performance of Chrome.

Next, have a look at the Epic Citadel[2], which runs very smoothly in Firefox 22. Well done!

[1] http://kripken.github.io/lua.vm.js/lua.vm.js.html [2] http://www.unrealengine.com/html5/

View on HN

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

http://arewefastyet.com/#machine=11&view=breakdown&suite=asm... http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...

It's a bit odd that arewefastyet.com stops showing results for JavaScriptCore when switching to the asm.js view.

JSC is also missing on Mandreel in Octane. Maybe the JSC shell lacks typed arrays?

If memory serves, JSC does not have typed arrays. The developer of Impact had to add them manually.

Safari does have typed arrays though. I guess added in the browser, not in JSC itself?

Nope, they work just fine from the `jsc` shell.

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

https://github.com/dvander/arewefastyet/blob/master/driver/b...

edit: btw, is there a simple way to build just the JSC shell on Linux? I can't find one.

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?

Thanks, that information would be very helpful.

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).

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).

On my laptop, I got 419 points for Firefox 22 and 120 points for Chrome 28.

Of course, the Lua VM test is compiled to asm.js, so of course Firefox does really well right now. Exciting nonetheless - this opens so many possibilities.

The Lua VM benchmark seems to be compiled to asm.js though, how does chrome fare when not targeting asmjs?

• Chrome 29.0.1546.0 canary: 91 points

• Firefox nightly 25.0a1 (2013-06-26): 403 points

MBP i7 2.2Ghz

It would probably be slower with emscripten in non-asm.js mode (asm.js format is more careful to not change types at runtime, etc.), based on benchmarks I've tested in the past. Have not tested on this particular one, though, if you check it out please let us know.

Reply on news.ycombinator.com