Hacker News Reader

Comment by azakai | Hacker News Reader

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

View on HN

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?

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

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

Reply on news.ycombinator.com