Slashdot Mirror

← Back to Stories (view on slashdot.org)

Firefox 4 RC Vs. IE9 RC: the First Duel

Posted by CmdrTaco on from the there-will-be-many-more dept.

An anonymous reader writes "Firefox 4 vs. IE9 is going to be an epic battle in a reigniting browser war in which Microsoft wants its IE to be seen as a capable browser again. Mozilla struggled to keep the pace with Chrome and IE9, but is about to release the first release candidate, which is expected to be the final version of Firefox 4 as well. This first review of JavaScript, Flash and HTML5 tests seems to indicate that both browsers are about even at the bottom line, while Firefox has the JavaScript edge and IE is ahead in HTML5 performance."

4 of 176 comments (clear)

  1. Anyone else slightly bored of the browser wars? by Mike+Mentalist · · Score: 5, Insightful

    After a while they just become samey and it's like arguing over which word processor is best - the one that loads 13% faster or the one that runs spellchecker 8% faster.

    --
    I put my books on Amazon, Smashwords, Demonoid, ISOHunt and Pirate Bay. Search for 'Michael Cargill'
  2. I don't use Firefox for performance reasons... by RightSaidFred99 · · Score: 5, Insightful

    Or even compatibility reasons. And I'm definitely not an MS hater. I use it because of the well implemented and widely used plugin system. IE has something similar but it's just not as well done and doesn't have as rich an ecosystem. So I don't really care about a 10% difference here, or an 8.5% difference there that I will never notice anyway.

    1. Re:I don't use Firefox for performance reasons... by Iphtashu+Fitz · · Score: 5, Informative

      I also use it mainly because I use a mix of Windows, Mac, and linux systems in both my day job and at home. I like having one common browser with plug-ins that work well on each platform.

  3. Re:Sunspider and IE9 by Anonymous Coward · · Score: 5, Interesting

    Sunspider is a redundant test -- as are Kraken, V8, and the rest of them. Synthetic benchmarks are inherently flawed and we should all pay far less attention to them, but they happen to be easy to convey and chart (much like flawed compliance "tests" like Acid3 and html5test).

    That said, there was almost certainly no cheating. That was a valid optimization. What was identified was a boundary condition in the JIT, which took two syntactically identical statements, which were not lexically identical, and showed that only one was optimized out. People who don't have any idea how to make an optimizing compiler decided that the only way this could happen was cheating, leaving out mistakes or intentional heuristics.

    The problem with that theory is that it would be more difficult to develop a cheating optimizing compiler with the characteristics it had, for that situation, than to actually come up with an optimization, so it's outright absurd. The guy who discovered the discrepancy never called it cheating.

    The RC scores the same in those tests now. I bet it was something simple like doing a quick one-line dead code elimination pass before the full dead code elimination heuristics decided whether to bother trying.