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.
Thread beginning with comment 442524
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: javascript speed
by jacquouille on Fri 24th Sep 2010 14:12 UTC in reply to "javascript speed"
jacquouille
Member since:
2006-01-02

You have to remember that the faster a browser gets, the harder it is to keep improving. V8 is getting closer and closer to running at native speed, and every millisecond they improve is an accomplishment.


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.

The only way to get closer to native speed is to know the types at hand, and that was the goal of Tracemonkey, which is a loop tracing JIT. Tracemonkey analyses the actual types in hot loops and generates type-specialized code for them. When it succeeds, it goes closer to native speed than what any method JIT can ever hope to get. The disappointment is that it doesn't succeed all that often, because of the way that actual real-world Javascript behaves. 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. So in Firefox 4, we keep Tracemonkey, and in addition we add a new method JIT, Jaegermonkey. We try to trace (Tracemonkey) and when we fail, we have a second chance with Jaegermonkey.


That said, there's no way FF4 is going to be faster than Chrome when it comes out. It should be about on par with Webkit, which is plenty competitive. V8 will maintain a lead.


Even if we restrict attention to JS performance only, that's not so clear. On v8's own benchmark, v8bench, indeed we're unlikely to beat them. 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.

I know that Google has more workforce and more motivation to keep a lead on JS performance (to us, it's just one out of many goalsl; to them it's more crucial) so even if we beat them for a while they're likely to reclaim the lead shortly after. Just wanted to make it clear that right now we're on the verge of winning on sunspider.

Reply Parent Score: 2

RE[2]: javascript speed
by smitty on Fri 24th Sep 2010 17:42 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

RE[3]: javascript speed
by jacquouille on Fri 24th Sep 2010 18:06 in reply to "RE[2]: javascript speed"
jacquouille Member since:
2006-01-02

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

... but just choosing this at runtime can easily kill performance ;) Also, if you have N variables and they can each have P different types, you have P^N cases to compile code for.

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.


You might have a good point there :-) At least for code manipulating only typed arrays. But when an arithmetic operations involves both typed arrays and other JS variables, my concern is that the lack of typing of the JS variable would hurt performance.

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


Typed arrays (and WebGL) are definitely already implemented in WebKit.

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.


Have you tried since Jaegermonkey was merged 2 weeks ago? See http://arewefastyet.com for benchmark results.

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.


Sunspider is indeed too short running to give Tracemonkey a good chance. Good thing we have Jaegermonkey :-)

Reply Parent Score: 2