This may have something to do with the fact that people see most of the things that $50 billion buys as counterproductive. As in, the department of education actively hinders education in many ways.
Now perhaps they should see the $650 billion the same way, since DoD does a bunch of stuff that hurts defense if anything. That's a separate issue, though.
Well... except that on modern high-bandwidth (and often high-latency, on mobile) connections, finishing downloading is often faster than stopping downloading.
> And also, people typically don't look at the life-cycle cost of the things they buy
I think they really do. But total life-cycle cost depends on things like discount rates, which vary widely from person to person even if we pretend we don't. As a result, economic efficiency for a particular actor may not correlate well with overall economic efficiency. The problem is that we're not very good at determining, on a societal level, when this is the case and how best to handle it.
As for the market being broken in this instance, it sure is, since there's so much meddling in it already....
Of course there's the obvious question: are externalities being properly priced into the prices of both kinds of light bulbs?
Or put another way, on the one hand governments subsidize the cost of electricity and on the other they want people to still use the more energy-efficient light bulbs... The net result is counter-regulation to offset the existing regulation.
Er.. how so? Note that this test wasn't even using the JS engine that will be in the next big Firefox release... nor has Mozilla been claiming it would be "faster than everything" on every single test you can throw at it. That would be a daft claim, obviously, just like the equivalent claim for any other browser.
That rate lock only applies if you use the new "let me know when you plan to paint and I'll update my DOM/CSS so the user sees the right thing" API. This benchmark isn't doing that it's just using a "1ms" timer (which is still rate-locked, to 200Hz in Chrome and 100Hz in other browsers).
See, that's the interesting thing. Compared to the IE9 betas, Webkit implements _more_ pieces of CSS, etc (e.g. CSS3 selectors), but the parts that they both implement Webkit gets more wrong in my testing (e.g. various parts of CSS2.1 Webkit "implements" in ways that are totally broken). The IE team has actually done a really good job of implementing the specs they said they would implement. Never thought I'd say that, just a few years ago!
Timers run from the event loop. They have all along; they didn't fire via the branch callback at all. So to get your timers to fire you have to stop whatever you're doing and return to the event loop.
I don't know how often the operation callback runs, sorry.
Having a 10ms timer that actually runs after 10ms (accurate to under a ms) is definitely a goal. But again, you'll have to go to the event loop to get the timer, and if something else is running when the timer is supposed to fire (e.g. if you have 1000 timers all scheduled for the same millisecond), chances are your timer will run late.
I can't make enough sense of the benchmark's obfuscated code so far to say anything useful about its accuracy past what I already said.
> Is it just that it's a new project designed from scratch without the cruft that other > browsers come with?
To some extent, yes. It's easier to write a fast JS engine if you don't have to worry about compatibility with existing applications that rely on your JS engine.
> Does it lack support for significant functionality?
To some extent, yes. Webkit purposefully handles some dynamic changes to a DOM incorrectly in terms of not actually restyling everything that needs to be restyled so that it can do it faster.
In this case there's also the matter of the benchmark just measuring things incorrectly so that the "intra-frame time" (as they call it) is dependent on a browser-specific setTimeout clamping that Chrome happens to set differently from other browsers. So those yellowish bars are all pretty much bogus (except the IE8 one, which is way larger than the 10ms clamping).
Also of interest is that Chrome 7 dev on Mac gets about 4fps for me on that benchmark on a fairly new machine. So I wonder whether the Chrome numbers are very different for 6 vs 7 or Mac vs Windows or what....
There is no such build option anymore. It's on by default. There's a --disable-methodjit to disable it, but if you don't see that in your about:buildconfig then it's compiled in. And at runtime whether it's on is controlled via preferences.
The thing with "real-life" benchmarks is that "based on Webkit" only gets you so far. Safari and Chrome use totally different JavaScript engines, for example. They use totally different drawing libraries. Heck, Chrome on Windows uses totally different drawing library than Chrome on Mac (which makes a difference in "real-life" benchmarks, since drawing is anywhere from 30% to 80% of the total benchmark time).
The less synthetic the benchmark the more silly details (exact browser, not just rendering engine, exact graphics driver version, exact Xorg version on Linux, exact graphics hardware, etc) start to matter...
The way this benchmark measures "intra-frame time" is broken. In particular, it uses a setInterval with a 1ms delay. No browser actually respects that 1ms. Chrome clamps it to 5ms; others clamp it to 10ms, all to avoid the website thrashing the CPU pointlessly.
The upshot is that Chrome's interframe delay in the graph is about 5ms and Firefox 3.6's interframe delay is aboug 10ms. Which this particular benchmark can't tell apart from "no delay at all", given its methodology.
Firefox 4 beta, IE9 beta, Safari, and Opera seem to have delays greater than 10ms, so they're clearly doing some work they can't finish in 10ms.... or have slightly buggy timer implementations. Or both.
Of course in practice frame rates above 60fps or so are pointless since the screen doesn't redraw that often.;)
On the other hand, on Mac, on modern hardware, I get 4.5fps in Chrome 7 dev on a random trial document I just tried, with JS render tiems on the order of 7ms (with a 7ms standard deviation) and "intra-frame time" of 224ms with a 900ms standard deviation (yes, those numbers are nuts). Firefox 4 beta comes in at about 11s for the JS (with 3ms stddev) and 125ms for the "intra-frame time" (with a claimed stddev of 0, which looks really suspicious).
It'd be nice if there were non-obfuscated source for this benchmark so its number-crunching could be evaluated; that 0 stddev is... highly improbable.
IE9 is "commandeering" GPU resources by using Direct3D and Direct2D. Those happen to be APIs the operating system provides through which you can do drawing in a way that makes it easy for the operating system to allocate GPU resources to support the drawing operations. Your other option is to not use those APIs, and either do the work yourself (on the CPU, since your process doesn't have direct access to the GPU, obviously) or call some other OS APIs which may or may not use the GPU for the work, depending on how well the API maps to what the GPU wants to see.
Doesn't seem like there's any confusion of roles here....
Uh... Firefox 4 will run on x86 and x86-64 and ARM. It will also run (but not be officially supported, last I checked), on SPARC and some other architectures, but so far without a JS JIT (though there's work to port the JIT to SPARC by some people who're actually using SPARC). The status of PPC seems to be that it will probably run but not be officially supported, though that hasn't been set in stone. In either case, there will be no JIT on PPC.
Targeting LLVM from a JIT may or may not work depending on the speed of the LLVM compiler; we'll have to see how it goes. In the meantime, as I understand it Chrome has two completely separate compilers with no shared code even for the "simple" cases of x86 and x86-64.... Mozilla has more sharing, with separate codegen backends but a lot of shared logic, but even so some things have to be different on x86 and x86-64 for optimal performance (like the basic in-memory representation of JS values). I can't speak to Opear's code, not having seen it.
Installing Safari on Mac also requires a reboot, and for the same reason. In both cases, the thing being installed isn't just a browser but also an update for the OS-default html-rendering dynamic library. Which means that suddenly any running applications that might be using that library need to be restarted, etc.
Explaining all that to users is a pain, so Apple and Microsoft just force a reboot.
Sure. That's a specific bug from a specific stress-case scenario. It needs to be fixed is all. Unless you're claiming that images like this are all over the web and Firefox users run into them all the time?
I'm not sure why those aren't acceptable arguments. If your argument is that Firefox is not usable without extension (and Windows is not usable without third party drivers), I might buy that, though I've used both of those configurations a fair amount. If you're claiming that Windows should sandbox drivers and Firefox should limit what extensions can do such that they can't possibly leak even when they try (as some do, by "caching" everything forever), I might even be able to buy that. But if you're arguing that there's just no causation there, then I'd like to see data (e.g. similar memory usage in Firefox without extensions). I haven't encountered it so far.
Slashdot Mirror
This may have something to do with the fact that people see most of the things that $50 billion buys as counterproductive. As in, the department of education actively hinders education in many ways.
Now perhaps they should see the $650 billion the same way, since DoD does a bunch of stuff that hurts defense if anything. That's a separate issue, though.
Well... except that on modern high-bandwidth (and often high-latency, on mobile) connections, finishing downloading is often faster than stopping downloading.
> And also, people typically don't look at the life-cycle cost of the things they buy
I think they really do. But total life-cycle cost depends on things like discount rates, which vary widely from person to person even if we pretend we don't. As a result, economic efficiency for a particular actor may not correlate well with overall economic efficiency. The problem is that we're not very good at determining, on a societal level, when this is the case and how best to handle it.
As for the market being broken in this instance, it sure is, since there's so much meddling in it already....
Of course there's the obvious question: are externalities being properly priced into the prices of both kinds of light bulbs?
Or put another way, on the one hand governments subsidize the cost of electricity and on the other they want people to still use the more energy-efficient light bulbs... The net result is counter-regulation to offset the existing regulation.
Firefox doesn't phone home the urls to a server; it just searches your local browser history.
> 1) Mozilla are good at lying about benchmarks
Er.. how so? Note that this test wasn't even using the JS engine that will be in the next big Firefox release... nor has Mozilla been claiming it would be "faster than everything" on every single test you can throw at it. That would be a daft claim, obviously, just like the equivalent claim for any other browser.
That rate lock only applies if you use the new "let me know when you plan to paint and I'll update my DOM/CSS so the user sees the right thing" API. This benchmark isn't doing that it's just using a "1ms" timer (which is still rate-locked, to 200Hz in Chrome and 100Hz in other browsers).
Yes, that's why I said "will". Future tense and all.
See, that's the interesting thing. Compared to the IE9 betas, Webkit implements _more_ pieces of CSS, etc (e.g. CSS3 selectors), but the parts that they both implement Webkit gets more wrong in my testing (e.g. various parts of CSS2.1 Webkit "implements" in ways that are totally broken). The IE team has actually done a really good job of implementing the specs they said they would implement. Never thought I'd say that, just a few years ago!
Timers run from the event loop. They have all along; they didn't fire via the branch callback at all. So to get your timers to fire you have to stop whatever you're doing and return to the event loop.
I don't know how often the operation callback runs, sorry.
Having a 10ms timer that actually runs after 10ms (accurate to under a ms) is definitely a goal. But again, you'll have to go to the event loop to get the timer, and if something else is running when the timer is supposed to fire (e.g. if you have 1000 timers all scheduled for the same millisecond), chances are your timer will run late.
I can't make enough sense of the benchmark's obfuscated code so far to say anything useful about its accuracy past what I already said.
Modern OSes refresh LCD monitors at 60Hz.
> Is it just that it's a new project designed from scratch without the cruft that other
> browsers come with?
To some extent, yes. It's easier to write a fast JS engine if you don't have to worry about compatibility with existing applications that rely on your JS engine.
> Does it lack support for significant functionality?
To some extent, yes. Webkit purposefully handles some dynamic changes to a DOM incorrectly in terms of not actually restyling everything that needs to be restyled so that it can do it faster.
In this case there's also the matter of the benchmark just measuring things incorrectly so that the "intra-frame time" (as they call it) is dependent on a browser-specific setTimeout clamping that Chrome happens to set differently from other browsers. So those yellowish bars are all pretty much bogus (except the IE8 one, which is way larger than the 10ms clamping).
Also of interest is that Chrome 7 dev on Mac gets about 4fps for me on that benchmark on a fairly new machine. So I wonder whether the Chrome numbers are very different for 6 vs 7 or Mac vs Windows or what....
> I'll take works correctly but takes time over doin it rong quickly any day.
You would? Then why are you happy with Webkit, which does some things in CSS purposefully wrong to do them faster?
There is no such build option anymore. It's on by default. There's a --disable-methodjit to disable it, but if you don't see that in your about:buildconfig then it's compiled in. And at runtime whether it's on is controlled via preferences.
The thing with "real-life" benchmarks is that "based on Webkit" only gets you so far. Safari and Chrome use totally different JavaScript engines, for example. They use totally different drawing libraries. Heck, Chrome on Windows uses totally different drawing library than Chrome on Mac (which makes a difference in "real-life" benchmarks, since drawing is anywhere from 30% to 80% of the total benchmark time).
The less synthetic the benchmark the more silly details (exact browser, not just rendering engine, exact graphics driver version, exact Xorg version on Linux, exact graphics hardware, etc) start to matter...
It has been, already. Trunk builds of Firefox have it, as will Firefox 4 beta 7.
The way this benchmark measures "intra-frame time" is broken. In particular, it uses a setInterval with a 1ms delay. No browser actually respects that 1ms. Chrome clamps it to 5ms; others clamp it to 10ms, all to avoid the website thrashing the CPU pointlessly.
The upshot is that Chrome's interframe delay in the graph is about 5ms and Firefox 3.6's interframe delay is aboug 10ms. Which this particular benchmark can't tell apart from "no delay at all", given its methodology.
Firefox 4 beta, IE9 beta, Safari, and Opera seem to have delays greater than 10ms, so they're clearly doing some work they can't finish in 10ms.... or have slightly buggy timer implementations. Or both.
Of course in practice frame rates above 60fps or so are pointless since the screen doesn't redraw that often. ;)
On the other hand, on Mac, on modern hardware, I get 4.5fps in Chrome 7 dev on a random trial document I just tried, with JS render tiems on the order of 7ms (with a 7ms standard deviation) and "intra-frame time" of 224ms with a 900ms standard deviation (yes, those numbers are nuts). Firefox 4 beta comes in at about 11s for the JS (with 3ms stddev) and 125ms for the "intra-frame time" (with a claimed stddev of 0, which looks really suspicious).
It'd be nice if there were non-obfuscated source for this benchmark so its number-crunching could be evaluated; that 0 stddev is ... highly improbable.
If you get a chance to at some point, that would be much appreciated! It definitely sounds like something we should improve...
Please feel free to mail me at "bz at mit dot edu" if you need to send me information you'd rather not post on Slashdot. ;)
IE9 is "commandeering" GPU resources by using Direct3D and Direct2D. Those happen to be APIs the operating system provides through which you can do drawing in a way that makes it easy for the operating system to allocate GPU resources to support the drawing operations. Your other option is to not use those APIs, and either do the work yourself (on the CPU, since your process doesn't have direct access to the GPU, obviously) or call some other OS APIs which may or may not use the GPU for the work, depending on how well the API maps to what the GPU wants to see.
Doesn't seem like there's any confusion of roles here....
> Firefox 4 will run only on x86 and x86-64.
Uh... Firefox 4 will run on x86 and x86-64 and ARM. It will also run (but not be officially supported, last I checked), on SPARC and some other architectures, but so far without a JS JIT (though there's work to port the JIT to SPARC by some people who're actually using SPARC). The status of PPC seems to be that it will probably run but not be officially supported, though that hasn't been set in stone. In either case, there will be no JIT on PPC.
Targeting LLVM from a JIT may or may not work depending on the speed of the LLVM compiler; we'll have to see how it goes. In the meantime, as I understand it Chrome has two completely separate compilers with no shared code even for the "simple" cases of x86 and x86-64.... Mozilla has more sharing, with separate codegen backends but a lot of shared logic, but even so some things have to be different on x86 and x86-64 for optimal performance (like the basic in-memory representation of JS values). I can't speak to Opear's code, not having seen it.
Installing Safari on Mac also requires a reboot, and for the same reason. In both cases, the thing being installed isn't just a browser but also an update for the OS-default html-rendering dynamic library. Which means that suddenly any running applications that might be using that library need to be restarted, etc.
Explaining all that to users is a pain, so Apple and Microsoft just force a reboot.
Hey, if you can tell me the steps to follow to reproduce the slowness, I'd be happy to look into it. Just let me know!
Sure, and that's what Kraken is about: testing the sorts of JavaScript google docs or other actual applications need.
Sure. That's a specific bug from a specific stress-case scenario. It needs to be fixed is all. Unless you're claiming that images like this are all over the web and Firefox users run into them all the time?
I'm not sure why those aren't acceptable arguments. If your argument is that Firefox is not usable without extension (and Windows is not usable without third party drivers), I might buy that, though I've used both of those configurations a fair amount. If you're claiming that Windows should sandbox drivers and Firefox should limit what extensions can do such that they can't possibly leak even when they try (as some do, by "caching" everything forever), I might even be able to buy that. But if you're arguing that there's just no causation there, then I'd like to see data (e.g. similar memory usage in Firefox without extensions). I haven't encountered it so far.