Search |
The battle for the title: the fastest ARM JavaScript Engine. Round one.There was a time, when Internet Explorer ruled the word, and browser developments were nearly stopped. Fortunately, Mozilla Foundation has brought us the Firefox and big waves appeared on the silent ocean. A fierce war has started since then: both in terms of speed and features. After some time other big names joined like Apple and Google. Using these new tools, the human creativity has changed the internet into a rich and beautiful place. (OK, it has dark sides as well). Well, this place is not only for desktop PC users, but for other people as well, who use mobile phones, handhelds, and other embedded devices. Those devices mostly run on ARM-based processors. And their users want not only the new shiny features, but the speed as well. Recently, we have developed an ARM-JIT engine for WebKit. (JIT means Just-In-Time compilation, a dynamic compiler which produces machine code instructions during runtime.) Now, the work is almost done, the engine runs smoothly. The next question is: was it worth the efforts? To decide this qestion, we should compare our JavaScript performance for other ARM-JIT engines. We chose the v8-engine first, which was developed by Google, and is now used in Google Chrome. The measurements were performed on a Nokia N810 Internet Tablet, with an OMAP ARM processor inside. We need only one more thing: choosing benchmark sets. We selected SunSpider (included in WebKit), v8 tests (included in v8), and WindScorpion (you can download it from here.)
Right now: v8-arm vs WebKit ARM-JIT : 0 - 1 |
Monthly archive
|
tonikitoo (not verified) - 05/07/2009 - 16:45
it'd be good to have it compared to mozilla's tracemonkey. it is supported on arm, and builds fine for the n810.
zoltan.herczeg - 05/11/2009 - 14:46
I have successfully compiled TraceMonkey (latest trunk checked out), but there was about 40 regression errors on ARM. I tried to run the benchmark sets: unfortunately, only the SunSpider was executed successfully, its runtime was 82323.7ms
Anonymous (not verified) - 05/14/2009 - 15:40
Great work, would you expect significant variance in results with either JITC given different amounts of RAM available?
zoltan.herczeg - 05/15/2009 - 10:03
I think the answer is no since jit only allocates memory for compiling, the generated code itself does never allocate any extra memory during runtime. Perhaps more momory would allow us to generate more inline functions, but I don't think the code would be that much faster. However, more cache memory does have a significant runtime difference, but that is independent from the jit compiler.
ufgop.org (not verified) - 06/09/2015 - 02:59
Love it! Very interesting topics, I hope the incoming comments and suggestion are equally positive. Thank you for sharing this information that is actually helpful.
ufgop.org
ufgop.org
Post new comment