Yet Firefox 4 is faster in both Sunspider and Kraken. (And V8 if you discount silly things like raytracing and process scheduling- why would anyone do those in javascript?)

Yet Chrome is still far faster if you have a multi-core system and are actually running more than one tab. FF4 can be as fast as it wants in processing Javascript, but it still can't scale that performance like Chrome can.

Actually, after initially starting it up and liking the speed, I found that Chrome quickly approached Firefox like performance levels once I started using more and more tabs.

And then Chrome tries to render some complex Canvas or SVG and grinds to a halt.

The things that lead to the most innovation are the things that don't seem sensible to do at first. For example, if you mean raytracing in the sense of computer graphics, improving its performance would lead to a possible greater presence of 3d applications on the web.

Doing raytracing in javascript is a bad idea. Period. There are many ways to do 3d on the web with greater flexibility and WAY more performance. WebGL is one, CUDA support in javascript is another: http://mozillalabs.com/jetpack/2010/01/25/elevating-javascri.... There is no reason to do that type of computation in the interpretation layer of javascript. (This is akin to saying you would prefer a pure python implementation of disk io, as opposed to the built in method which is implemented in C.)

I don't see why fast Javascript should equal frequent CPU wakeups.

No, but getting lower latency javascript with tab-level independent parallelism makes a lot more CPU available.

Firefox simply runs all javascript in one physical thread, so it can only ever use about 100% CPU, while Chrome can use N00% CPU.

If the same amount of overall work is getting done, that shouldn't matter. At any rate, these wakeups will be when chrome is idle in the background, so I doubt it will be using more than one whole CPU.