Slashdot Mirror

Did you look at the diffs? The addition of the "true;" operation should make absolutely no difference to the output code. It's a NOP. The fact that it makes a difference indicates that either something fishy is going on, or there is a bug in the compiler that fails to recognise "true;" or "return (at end of function)" as being deadcode to optimise away, and yet the compiler can apparently otherwise recognise the entire function as deadcode. Just to be clear, we are talking about a compiler that can apparently completely optimise away this whole function:

function cordicsincos() {
        var X;
        var Y;
        var TargetAngle;
        var CurrAngle;
        var Step;

        X = FIXED(AG_CONST); /* AG_CONST * cos(0) */
        Y = 0; /* AG_CONST * sin(0) */

        TargetAngle = FIXED(28.027);
        CurrAngle = 0;
        for (Step = 0; Step CurrAngle) {
                        NewX = X - (Y >> Step);
                        Y = (X >> Step) + Y;
                        X = NewX;
                        CurrAngle += Angles[Step];
                } else {
                        NewX = X + (Y >> Step);
                        Y = -(X >> Step) + Y;
                        X = NewX;
                        CurrAngle -= Angles[Step];
                }
        }
}

but fails to optimise away the code when a single "true;" instruction is added, or when "return" is added to the end of the function. Maybe it is just a bug, but it certainly is an odd one.

This shows the dangers of synthetic non-realistic benchmarks. I was amused to read Microsoft's comments on SunSpider: "The WebKit SunSpider tests exercise less than 10% of the API’s available from JavaScript and many of the tests loop through the same code thousands of times. This approach is not representative of real world scenarios and favors some JavaScript engine architectures over others." Indeed.

btw the Hacker News discussion is more informative.

http://blog.mozilla.com/rob-sayre/2010/11/16/reporting-a-bug-on-a-fragile-analysis/

If Microsoft is cheating, why wouldn't they cheat a bit better? Of the five browsers, including betas, IE is second from last. Last place is, of course, Firefox, even with the new JS engine. Oh, and that stats image? Taken from the same blog post that originally discovered the Sunspider IE9 issue over a month ago.

Rob Sayre, the Mozilla Engineer who discovered this, filed a bug with Microsoft to get them to look at this issue. However, he didn't file said bug until today, which is likely why this is in the news now rather than a month ago.

If Microsoft is cheating, why wouldn't they cheat a bit better? Of the five browsers, including betas, IE is second from last. Last place is, of course, Firefox, even with the new JS engine. Oh, and that stats image? Taken from the same blog post that originally discovered the Sunspider IE9 issue over a month ago.

Rob Sayre, the Mozilla Engineer who discovered this, filed a bug with Microsoft to get them to look at this issue. However, he didn't file said bug until today, which is likely why this is in the news now rather than a month ago.

If Microsoft is cheating, why wouldn't they cheat a bit better? Of the five browsers, including betas, IE is second from last. Last place is, of course, Firefox, even with the new JS engine. Oh, and that stats image? Taken from the same blog post that originally discovered the Sunspider IE9 issue over a month ago.

Rob Sayre, the Mozilla Engineer who discovered this, filed a bug with Microsoft to get them to look at this issue. However, he didn't file said bug until today, which is likely why this is in the news now rather than a month ago.

1) If you actually read the article, you may have noticed that the engineer is named. It's
        right there there at the beginning of paragraph 2: "While Mozilla engineer Rob Sayre"
2) The "cheating" stuff is all from the Hacker News thread and the fucking articl. I
        suggest you further read item 1 under "Further Readings" on the fucking article, which
        is what Rob actually wrote. The link is: http://blog.mozilla.com/rob-sayre/2010/11/16/reporting-a-bug-on-a-fragile-analysis/

Just to save you the trouble of reading it, if don't want to, it's pretty clear that IE9 is eliminating the heart of the math-cordic loop as dead code. It _is_ dead code, so the optimization is correct. What's weird is that very similar code (in fact, code that compiles to identical bytecode in some other JS engines) that's just as dead is not dead-code eliminated. This suggests that the dead-code-elimination algorithm is somewhat fragile. In particular, testing has yet to turn up a single other piece of dead code it eliminates other than this one function in Sunspider. So Rob filed a bug about this apparent fragility with Microsoft and blogged about it. The rest is all speculation by third parties.

Fear not, for I have RTFA and the original article that the digitizor article is based on.

Fortunately for the ethics of Mozilla, the named Mozilla engineer (Rob Sayre) never claimed that IE9 cheated. Instead, he diplomatically refers to it as a "oddity" and "fragile analysis" and filed a bug w/ MSFT.

http://blog.mozilla.com/rob-sayre/2010/09/09/js-benchmarks-closing-in/M
http://blog.mozilla.com/rob-sayre/2010/11/16/reporting-a-bug-on-a-fragile-analysis/

So, blame Digitizor and ycombinator for putting words in Rob Sayre's mouth.

Fear not, for I have RTFA and the original article that the digitizor article is based on.

Fortunately for the ethics of Mozilla, the named Mozilla engineer (Rob Sayre) never claimed that IE9 cheated. Instead, he diplomatically refers to it as a "oddity" and "fragile analysis" and filed a bug w/ MSFT.

http://blog.mozilla.com/rob-sayre/2010/09/09/js-benchmarks-closing-in/M
http://blog.mozilla.com/rob-sayre/2010/11/16/reporting-a-bug-on-a-fragile-analysis/

So, blame Digitizor and ycombinator for putting words in Rob Sayre's mouth.

It is actually a couple of months old. The thing that makes me doubt the claims of cheating is that nobody has been able to find other examples of performance variations in this benchmark in all the time since this came to light. If they were going to cheat, why limit it to the cordic test? Nobody would base their browser choice on this obscure test.

I don't have the beta installed yet, but what I would like to see is the actual calculation changed and then run the tests again. Don't just put in weird code like "true;" but make the javascript plausible. It could be that the addition of these unusual statements are enough to confuse the optimiser so that it resorts back to a completely unoptimised version.

Are you suggesting that the site necessarily needs a gigantic plain-text bulleted list of things that it can do right in the middle of the page?

Exactly. You're probably using Firefox right now. Their site is guilty as you yourself chose to charge.

I think you're over reacting about Video on the web, and I can't understand how anything about what you've said is insightful. None of those pages really tell me anything about what the browser really does. Most of it is buzz words, but I guess if thats informative for you.. Also it only took me a split second to find the user guide on flock's page.

Introductory videos being your main introduction are a stupid idea, not because of esoteric technical/philosophical reasons (I have and use Flash! I even use Facebook, and Flash in Facebook). They're a stupid way of going about things because they expected to make noise. A lot of people are often already listening to music, or in a room with someone that is listening to music/watching television/having a conversation, and would rather not be interrupted by some stupid video that is done better with pictures and text.

It's not like this is rocket science. Virtually all the major browsers make a damn feature of their features:

Opera has a link to this right in its splash box:
http://www.opera.com/browser/

and Firefox this:
http://www.mozilla.com/en-US/firefox/features/

Chrome has this:
http://www.google.com/chrome/intl/en-GB/more/index.html

Even IE has this:
http://www.microsoft.com/windows/internet-explorer/features/faster.aspx

All these took literally split seconds to locate on the page. The Flock page is a mess.

P.S. I used to use Flock, so I was idly curious about what it does nowadays. I couldn't be bothered tracking that down on their convoluted so I left. Nice going designers!

Try it here or here.

But I believe it uses actionscript.

https://www.mozilla.com/en-US/mobile/4.0b2/releasenotes/ RTFM

Or maybe your experience doesn't match the majority. Firefox crash&hang rate per active daily user on Linux is about 0.02%. Data.

Yeah, it's not like they gave us any reason to mistrust them because of cheating on other tests.

Nightlies are NOT betas. These are two different things.

Beta releases are milestone releases that represent the closing of bugs. Nightlies are buggy as all hell experiments that change, well, every night.

Here are the nightlies:
http://nightly.mozilla.org/

Here are the betas:
http://www.mozilla.com/en-US/firefox/all-beta.html

You could have predicted this lateness because the Firefox folks seem to think "beta" means "Let's add new features every couple of days".

I think you're confusing cause and effect. You could argue that early on they mismanaged the scope of the project and therefore set unrealistic expectations, but so far as I've seen, the build monikers themselves (alpha, beta, nightly, RC, etc.) have proven to have surprisingly little to do with the actual readiness of the code.

Rather I would say you could have predicted this lateness based on a quick gander at a historical trend showing the number of bugs that are being found, fixed and remain on a daily basis. You tend to get a rather predictable bell curve from release to release when you track such things. We appear to have just recently started building horizontally over the crest of the bell curve for Firefox 4, as you can see here. As a fairly clued-in nightly tester, and based on what I see in the bugzilla database and the movement of the trend graphs over the past several months (and also assuming a nearly 3 week dead time for winter holidays) I would not at all be surprised to see a mid-late March final release.

the result of this select query is .... (insert beavis voice from B+B) "uh uhuh huh chrome runs javascript 10 ms faster huh huhuhuh"

Chrome used to be faster, but isn't anymore. Firefox 4 beats Chrome on the Kraken and SunSpider benchmarks. See Mozilla's http://arewefastyet.com for some charts. Firefox 4 doesn't yet beat Chrome on Google's own V8 benchmark. I imagine Firefox 4 will close the gap to Chrome a bit more on V8 before it is released.

Jesus guys, can't you just congratulate the Firefox devs on the great job they're doing? Just look at the rate of improvement over the past few months and give the JaegerMonkey/TraceMonkey guys kudos for a really impressive job of software engineering. Have a look at David Mandelin's recent post to get an idea of how much work and planning has gone into this project.

Please clarify, try the nightly build and tell us if you also run AVG

Read the article, they were free and trying to monetize the collected bookmark data. A number of responses to the blog post suggest willingness to pay... but they never approached the users before deciding to close up shop. A shame.

Firefox 4 comes with one built in, there's an extension for Firefox 3:

http://support.mozilla.com/en-US/kb/What+is+Firefox+Sync

I'll use it, but not being cross browser may leave some people without a good option.

It used to be called, Mozilla Weave and was an add-on, which will now be included in Firefox 4 proper.

Changed your "not" to "now".

As per

http://www.mozilla.com/en-US/firefox/sync/

That's stupid. My browser does malware protection, I don't need Google or Facebook getting involved. And as @spazdor says, do that before presenting the link to me.

You're crazy if you think Google and Facebook intercept links for your benefit. They're doing it to track you, pure and simple.
At least I can infer their outbound links. Link shorteners are Russian roulette. If services like Twitter wanted a better user experience, they would unshorten links when they present a feed to browsers.

Firefox already has.

Mozilla are good at lying about benchmarks (actually, we already knew that, they've been claiming the next big firefox release would be faster than everything for a while now)

What are you talking about? The Mozilla team caught the IE team cheating at benchmarks, whereby minor code changes which should result in zero internally generated code results in code which runs 22x slower. And even if MS were to fail horribly at the obvious optimization of producing a nop, at worst which can possibly be imagined would be something like a 1ms; whereby a fraction thereof is extremely more likely. In other words, it appears IE specifically detects some benchmarks and returns a predetermined value rather than actually compiling and executing the code. There is no legitimate reason for a nop instruction to slow a benchmark 22x times. None. Zero. And if its a bug, it would be practical impossible for IE to perform nearly as well at any other benchmark. They'd likely return results at least an order of magnitude slower. The only reasonable, plausible explanation is they are cheating; blatantly!

In other words, how can placing code which results in a nop instruction result in running 22x slower in any language whereby the implementation is supposed to be so good it runs many times faster than is theoretically possible. You can't without smoke a mirrors and blowing lots and lots of smoke up your ass - and yet that's exactly what Microsoft is doing here.

With cheat, benchmark = 1ms.
Without cheat, benchmark = 22.5ms.

Which in fact suggests MS's optimizer fails to identify and optimize some of the more common and easiest forms of optimization which in turn hints they are cheating across the board to be close to the results indicated by common benchmarks.

IE = bullshit, smoke, and mirrors.

You may wish to try Minefield, (4.0 beta) if you can stomach using a beta. I've actually been using the nightlies for months and they're generally stable. You may want to try a release beta, however. (4.0b6 is good). There are 64-bit linux, Mac, and Windows versions.

Keep in mind that it's a beta, though and not intended for general consumption quite yet.

http://www.mozilla.com/en-US/firefox/all-beta.html

Because I hate Flash, I have a separate Firefox profile specifically for using the plugin. (Yes, there are other ways to block flash, but that isn't helpful if you're trying to find which of 200 tabs started autoplaying on startup)

... and now, Firefox wins in their test! (which has yet to be disassembled to reveal how they dodge Opera and Chrome from winning, when they use to in all others, including independent tests like Peacekeeper)

I'm guessing from the number of crypto and imaging components that this is related to their recent JS math optimizations.

The only decent benchmark I've ever seen for browsers is something someone made which simply loaded local copies of sites like facebook to show how fast the browser really is at true "realistic workloads".

The current Firefox 4 nightlies and soon the beta releases will have compositing acceleration enabled by default. Compositing acceleration uses Direct3D 9 and works on Windows XP:

http://blog.mozilla.com/joe/2010/09/15/testing-hardware-acceleration/
http://hacks.mozilla.org/2010/09/hardware-acceleration/

For comparison same setup with Firefox 4 Beta 6 got 17568.9ms +/- 0.3%

Setup:
Windows 7 64-bit
Intel Core 2 Duo E8400 @ 3.00GHz
4.00 GB RAM
Intel SSD 80GB G2

I just ran the new Kraken benchmark released by Mozilla, result 48979.0ms +/- 2.8%.

Machine: Lenovo ThinkCentre with an Intel Core i5 660 (3.33GHz), 8GB DDR3 RAM, Windows 7 Profession x64, and nVidia Geforce GT310
Kraken Benchmark Results:
Microsoft Internet Explorer 9 Beta
Google Chrome 6.0.472.59 Beta
Mozilla Firefox 4 beta 6

Machine: Lenovo ThinkCentre with an Intel Core i5 660 (3.33GHz), 8GB DDR3 RAM, Windows 7 Profession x64, and nVidia Geforce GT310
Kraken Benchmark Results:
Microsoft Internet Explorer 9 Beta
Google Chrome 6.0.472.59 Beta
Mozilla Firefox 4 beta 6

Machine: Lenovo ThinkCentre with an Intel Core i5 660 (3.33GHz), 8GB DDR3 RAM, Windows 7 Profession x64, and nVidia Geforce GT310
Kraken Benchmark Results:
Microsoft Internet Explorer 9 Beta
Google Chrome 6.0.472.59 Beta
Mozilla Firefox 4 beta 6

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.

And it doesn't help that the mozilla team recently identified IE as detecting various benchmarks to make IE look up to twenty times faster than it really is.

Until Microsoft stops purposely misleading people with their completely bogus benchmark results, their stigma of poor quality and low performance is nothing but well deserved.

Someone with Windows 7, a decent 3d graphics card, and a dual or quad-core CPU please benchmark this new IE9 beta vs. the currently released versions for FF, Chrome, Safari and Opera, using:

• Sunspider
• Kraken
• Peacekeeper

And, if you could, break out the scores on the individual Peacekeeper tests. I intentionally omitted V8 in the list of benchmarks since its so inconsistent between runs.

I'd do it myself but I don't have a Win7 installation to use.

14196.9ms +/- 0.8% in Opera 10.61 (run 'as is', tabs etc.) on a macbook pro w/ 8GB of ram

> So yeah, I'd expect FF 3.6 to be the slowest of the bunch.

Right. Which is consistent with other JS tests, so no mysteries or benchmark-skewing by Mozilla needed there... ;)

> Actually, there are probably several empty leagues between FF/Chrome/Safari/Opera and IE

That may or may not be the case with the IE9 betas, depending on which benchmarks you use. Though there's some weirdness; see http://blog.mozilla.com/rob-sayre/2010/09/09/js-benchmarks-closing-in/ the paragraph starting "One last issue that can crop up".

FF 3.6.9 on MacBook Pro '08: 24930.0ms +/- 0.4%

(not testing under ideal conditions - other tabs open, other programs running, etc, in an attempt to reflect "real conditions")

Google wins in their test! (that curiously heavily exploit recursion and other good parts of the V8 engine)

Microsoft wins in their tests! (that curiously heavily test only DirectX acceleration)

... and now, Firefox wins in their test! (which has yet to be disassembled to reveal how they dodge Opera and Chrome from winning, when they use to in all others, including independent tests like Peacekeeper)

Latest Opera Snapshot: 15603.7ms

One of Mozilla's longstanding issues with some of the other benchmarks is that they test toy problems that take longer to set up than to run. Yes, that favors browsers with JS engines that set up for execution quickly, and that portion of the engine is important. It doesn't show the real speedups for intensive applications in the browser, though. Optimizing the slow parts is the priority of most people right now, and getting the application set up a little faster at the beginning isn't as big a deal unless you have a lot of small scripts in one page.

An earlier blog post by Sayre and some of the comments to it display some of the issues.

Latest Mozilla Central 64 bit: 9409.6ms

Latest Chromium 32 bit 18766.2ms

Latest Mozilla Central 64 bit: 9409.6ms

Latest Chromium 32 bit 18766.2ms

Here are my results.

Latest Mozilla Central nightly on Mac OS X 32 bit: 9339.5ms

Latest Webkit nightly. 64 bit: 15736.5ms

I'll run a Mozilla Central 64 bit in a moment.

Here are my results.

Latest Mozilla Central nightly on Mac OS X 32 bit: 9339.5ms

Latest Webkit nightly. 64 bit: 15736.5ms

I'll run a Mozilla Central 64 bit in a moment.

IE9 cheats on popular benchmarks (scroll to the bottom). And they still come second-to-last.

have you ever heard of disposable email addresses?

Sure, but putting up barriers and making things difficult doesn't help their cause. As I've stated, why bother registering for a disposable email address and then registering for "free" music when I can just use the Pirate Bay, or Apple iTunes (99 cents isn't a lot of money to overcome inconvenience).

Most people will go for the path of least resistance.

On a side note, and another example of the groups lack of thoughtful insight:

There is no way to "create" a work into the public domain. Work only enters the public domain upon expiration of the copyright term.

It's one of the last comments, but I also had a similar notion, and that is, why don't these people put the music into a Creative Commons license, like the "Public Domain" license CC0.

It's sort of like Slashdot is pressuring me to register, send them an email address, turn on cookies and turn on Javascript, and more indirectly (mainly through the Idle section) install and turn on Flash, because I'm supposed to wait HOURS!! until I get to reply to a person like you otherwise. Of course they KNOW that I'm not a Troll poster because they keep track of me through other things besides cookies (like IP address and browser ID and settings etc). I know this because I've experimented with things. It's all a big Bullshit game with these companies, and something that I REFUSE to play along with. So I don't register with ANY "free" service, NOT Facebook and not even with Slashdot. People tell me I'm an idiot and a Luddite, including the arrogant "freeware", and "non-profit" [see note] programmers at Firefox):

You have JavaScript disabled or are using a browser without JavaScript. This Plugin Check page does not work without the awesome power of JavaScript. Please enable this Content Preference and reload the page.

Or disable all your plugins and keep JavaScript disabled... you'd be in good company, that's how RMS rolls...

From: Richard Stallman
To: "Edd Barrett"
Subject: Re: Real men don't attack straw men
Date: Sat, 15 Dec 2007 16:37:06 -0500
Message-ID:
Cc: misc-AT-openbsd.org
Archive-link: Article, Thread

For personal reasons, I do not browse the web from my computer. (I
also have not net connection much of the time.) To look at page I
send mail to a demon which runs wget and mails the page back to me.
It is very efficient use of my time, but it is slow in real time.

- This reference is straight from the Mozilla Web site.

Note: Did you know that executives at "non-profit" companies and charities on average make more money than executives at for-profit companies? [Ref: Mark J. Penn, from the book micro trends].

Also note, "Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment. It's been 2 hours, 14 minutes since you last successfully posted a comment". I might try again later to post a reply, or maybe do something more useful with my time. Sometimes I get the impression that Management at these companies and Websites think that people are fools.

The JaegerMonkey team understands why it's currently slower on 64-bit than on 32-bit. One reason is that the larger pointers on 64-bit systems don't play well with the value representation. If that can be fixed, perhaps by using a different value representation in 64-bit versions, it might end up faster on 64-bit than on 32-bit.

They're working on speeding up the 64-bit version. They have to, because of the plan to ship Firefox 4 as a 64-bit application for Mac OS X 10.6 ;)

(Btw, arewefastyet.com shows speeds of naked JavaScript engines, which are usually slightly faster than JavaScript engines inside web browsers.)