Linked by Thom Holwerda on Thu 23rd Sep 2010 21:36 UTC, submitted by google_ninja
Internet & Networking Now this is a subject sure to cause some discussion among all of you. LifeHacker's Adam Pash is arguing that Chrome has overtaken Firefox as the browser of choice for what he calls 'power users'; polls among LifeHacker's readership indeed seem to confirm just that. He also gives a number of reasons as to why this is the case.
Permalink for comment 442571
To read all comments associated with this story, please click here.
RE[2]: javascript speed
by smitty on Fri 24th Sep 2010 17:42 UTC in reply to "RE: javascript speed"
smitty
Member since:
2005-10-13

Actually, method JITs like v8 will never even approach native speed, and here's why. Native code knows the _type_ of the data it's manipulating, so it can pick the right assembly instruction at compile-time. But in Javascript, which is a dynamic language where types can change at any time during execution, that's not possible. So yes, v8 is an insanely fast method JIT for Javascript, but don't expect it to go at more than 10% of the speed of well-written native (say, C or C++) code.

Yes, as i understand it the way method JITs get around this is by implementing stub code for multiple types. So "x + y" javascript code generates native code for both integer and string addition, and then the correct path is chosen at runtime. A fallback path is present for non-commonly used types.

But it's still worth keeping, especially with the growing importance of doing intensive computation in JS, and the introduction of Typed Arrays, especially in connection with WebGL.

I'm curious, with the typed arrays doesn't the method JIT compiler have all the information it needs? It seems like that would be the one place where Tracemonkey wouldn't be able to improve upon.

Also, i was wondering if Chrome/Webkit have implemented this yet or if their WebGL code was still using standard float arrays?

But on sunspider (Webkit's benchmark) we are only 10-15% slower right now on x86 and we keep improving fast. On other benchmarks that give Tracemonkey a chance to trace, we win.

...

Just wanted to make it clear that right now we're on the verge of winning on sunspider.


Do you work on Firefox? Looking at the gains made on sunspider over the last few weeks from an external perspective it doesn't look like Firefox is improving much there at all, but perhaps that's wrong. I assumed it was an issue of overhead, that Firefox could do well on longer running tests where tracemonkey had a better chance of improving the code, but that short tests like sunspider favored newer javascript architectures with cleaner code and less overhead.

Reply Parent Score: 2