IE 9 Beta Strips Down For Speed

CWmike writes "Those who have written off IE as being slow and old-looking are in for a surprise. The just-released Internet Explorer 9 beta is dramatically faster than its predecessor, sports an elegant, stripped-down interface and adds some useful new features, writes Preston Gralla. Even more surprising than the stripped-down interface is IE9 beta's speed. Internet Explorer has long been the slowest browser by a wide margin. IE9 has turned that around in dramatic fashion, using hardware acceleration and a new JavaScript engine it calls Chakra, which compiles scripts in the background and uses multiple processor cores. In this beta, my tests show it overtaking Firefox for speed, and putting up a respectable showing against Safari, Opera and Chrome. It's even integrated into Windows 7. One big problem: It will not work on Windows XP. So, forget the performance and security boost, many enterprises and netbook users."

Re:I know other whores...

[hedwards]

They give you viruses as well if you're not careful.

A Fuller review, with benchmarks

[mikemuch]

Internet Explorer 9 Reviewed, Benchmarked [pcmag.com]

Re:Here's to hoping

[Anonymous Coward]

No, I don't read it the same way as you. From what I understand, they improved their Javascript performance by using a totally new enigne, added multi-core support and a the same time started a new trend, now followed by FF and other browsers, to use GPU to accelerate graphical tasks such as rendering text and bitmaps. To me it sounds that they have spent an incredible amount of time/rersouces and practically rewrote the whole thing from scratch; something everybody just hoped they would someday do.

Re:M$ snubs XP ?

[schnikies79]

XP is supported until 2014. [microsoft.com]

Re:request to the peanut gallery:

[VGPowerlord]

Absolutely do not include Sunspider in the results as Mozilla has caught Microsoft (IE) cheating. They are actively detecting these benchmarks are falsely providing results up to twenty times faster than they are able to actually execute the code. The only reason they got caught was because one benchmark was so much faster than what everyone else was doing and the nature of the benchmark seemed unlikely anyone would have such a significant advantage.

IE + Sunspider = absolute lies. The results are rigged.

The later two are far more likely to provide meaningful results. And Kraken is specifically designed to reflect exactly that.

Did you link to the wrong page or something? The blog entry you linked to says nothing of the sort, and shows IE9 as slower than every browser other than Firefox 4 in Sunspider.

Re:No cross platform support either

[Anonymous Coward]

Sorry, but if Microsoft really wants IE9 to get good uptake, they are going to have to support other platforms. The idea that Mac+Linux is only 2% of the market is largely a myth. Outside of the USA there is HUGE uptake in these platforms (particularly Linux) and in enterprise and corporate environments Linux support in particular is even more critical.

Re:integrated into Windows 7

[AltairDusk]

Which is one of a very long list of things that make me unhappy with Sharepoint, it's everything including the kitchen sink but doesn't seem to do anything very well.

Re:Here's to hoping

[cybrthng]

Efficiencies can be found by optimizing the workflow in which case IE 9 optimally takes advantage of GPU or multiple cores for better performance.

Sure

[Sycraft-fu]

System is a Core i7 860 (2.8GHz) 8GB RAM, a Radeon 5750 1GB. OS is Windows 7 64-bit, all patches current as of today. It is running the browser and Outlook, plus background apps so not a clean benchmark system but a pretty realistic light workload. Safari is not included because I am not willing to install all the system services they want to have.

Sunspider
---------
Firefox 3.6.9: 601.8ms +/- 1.0%
IE9 Beta: 291.6ms +/- 0.6%
Chrome 6.0.472.59: 215.8ms +/- 2.7%
Opera 10.62: 237.0ms +/- 1.5%

Kraken
------
Firefox 3.6.9: 13928.4ms +/- 0.5%
IE9 Beta: Fails to function properly.
Chrome 6.0.472.59: 12343.7ms +/- 0.6%
Opera 10.62: 10114.7ms +/- 0.5%

Peacekeeper
-----------
Firefox 3.6.9: 3612

Rendering 3050
Social networking 3109
Complex graphics 6482
Data 4819
DOM operations 3132
Text parsing 4300

IE9 Beta:3256 Has compatibility issues with their software to test the system which might cause results problems.

Rendering 2534
Social networking 1703
Complex graphics 7941
Data 6834
DOM operations 2530
Text parsing 4893

Chrome 6.0.472.59: 10988 Canvas results were visibly different from other browsers.

Rendering 7051
Social networking 6863
Complex graphics 21211
Data 23624
DOM operations 8173
Text parsing 17145

Opera 10.62: 11510

Rendering 11900
Social networking 8471
Complex graphics 18830
Data 8937
DOM operations 10291
Text parsing 21797

I would caution against taking any of this too seriously for actual browser performance. The first two tests are 100% synthetic, no rendering at all, and the Futuremark test is rather strange and artificial, as their tests usually are (their graphics card benchmarks are notorious for not reflecting how GPUs work in the real world).

For useful tests you need something that is testing actual pages rendering how someone would actually use things. Video playback, an interactive game, etc. All these benchmarks strike me as contrived, not realistic.

Re:tabs on the same row as address bar

[AsmordeanX]

It handles multiple tabs about as poorly as you can expect it to. http://arstechnica.com/microsoft/news/2010/09/inside-internet-explorer-9-redmond-gets-back-in-the-game.ars/2 [arstechnica.com] (scroll about 1/2 way down)

Basically it just crowds out until the tabs are rendered useless then if helpfully puts scroll arrows after you can't read what's inside the tab anymore.

Re:No cross platform support either

[LocalH]

The Apple version of Webkit (Safari) of course only runs on OSX, or OSX+iOS if you count Mobile Safari as the same browser.

Really? So the software I'm running isn't actually Safari?

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5

Re:request to the peanut gallery:

[Blakey Rat]

Ok, I can't speak for the grandparent, but I read the whole thing. The blog entry mentions it with kind of a "huh, that's odd" attitude-- it definitely doesn't accuse Microsoft of cheating. Nor do any of the comments. So I think you're blowing it out of proportion.

Look, if Microsoft wanted to cheat on a benchmark, would they:
1) Only bother to add the cheat in to a single small test out of hundreds
2) Make the result instant, or close to it, instead of a realistic execution time, thus making it easy to detect?

No, of course not. What you're looking at is a bug, either in the test, or in IE9.

It doesn't help that the entire rest of the blog article focuses on:
1) How crappy these benchmarks are
2) How they don't take into-account caching, which is exactly the kind of thing that could produce a 1ms response when you're expecting a 20ms response

Maybe the only "problem" is that IE's JS engine saw though the test, said, "hm, this code doesn't do jack" and skipped it.

Re:Here's to hoping

[groslyunderpaid]

This word "efficiency" ... it does not mean what you think it means.

Arguing that making more efficient use of existing hardware doesn't constitute making your browser more efficient is mere semantics. This is one of those points that is relative to where you are standing.

Re:Here's to hoping

[KarmaMB84]

The behavior is reproducible with different code. If you insert the return. It jumps to about 40ms on my machine. If you modify one of the branches to not modify any variables outside of for loop (modify a new variable inside the loop instead), it drops to 16ms. The code *should* still be doing the same amount of work but because one branch has no effect, it probably doesn't even get compiled. If you modify both branches in the same way, the result drops to 8ms which appears to be just the time it takes to loop through 12 times multiplied by the 25000 times the function is called since it modifies the Step variable. Without a return, it seems to drop the entire loop but not the assignment of local variables. Not calling the function at all would cause the loop which normally counts to 25000 to also not do anything and the test would complete instantly.

I've tinkered with it enough to say it's more than likely nothing but the pre-compiler optimizing things by dropping statements that don't really do anything (can't be returned or aren't going to be because the function doesn't return at all). Inserting a true statement probably just causes it to not do the optimization for whatever reason (perhaps just any built-in statement will cause it). Also most of the speed up can still be gained even if the return statement is there if the branches in the loop are just written differently to have no effect on the function's local variables.

Re:No cross platform support either

[BZ]

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