Internet Explorer 9 Caught Cheating In SunSpider
dkd903 writes "A Mozilla engineer has uncovered something embarrassing for Microsoft – Internet Explorer is cheating in the SunSpider Benchmark. The SunSpider, although developed by Apple, has nowadays become a very popular choice of benchmark for the JavaScript engines of browsers."
I would think Microsoft would be used to embarassing by now..
vos nescitis quicquam, nec cogitatis quia expedit nobis ut unus moriatur homo pro populo et non tota gens pereat.
Inconceivable!
No, none what-so-ever.
Welcome to your daily two minutes hate, Slashdot.
This is the nature of benchmarks... whenever people start caring about them enough, software/hardware designers optimize for the benchmark.
Next we're going to be shocked that 8th grade history students try to memorize the material they think will be on their test rather than seeking a deep and insightful mastery of the subject and its modern societal implications.
I could still use Internet Explorer 8. I have 9 right now, but certain websites that my job requires me to go to locks me out of some content. Autotask.net and some other sites that my school has access to is nonfunctional. I know most pages comply, but the few that don't - why are we forced to use Microsoft software?
Microsoft knows that they cannot win on a level playing field. Microsoft knows they are unable to compete without having their finger on the scale. So they cheat.
what can be attributed to stupidity.
1) Microsoft cheated by optimizing Internet Explorer 9 solely to ace the SunSpider Bechmark. To me, this seems like the best explanation.
2)Microsoft engineers working on Internet Explorer 9 could have been using the SunSpider Benchmark and unintentionally over-optimized the JavaScript engine for the SunSpider Benchmark. This seems very unlikely to me.
I see no reason why explanation number one is more likely than explanation number two.
Oh please. Don't overreact. Microsoft is quickly becoming irrelevant. Google and Facebook are the new borg that we should be worried about.
Next we're going to be shocked that 8th grade history students try to memorize the material they think will be on their test rather than seeking a deep and insightful mastery of the subject and its modern societal implications.
Some things to consider: 1) I'm not doing business with the 8th grader. Nor am I relying on his understanding and memorization of history to run Javascript that I write for clients. 2) You are giving Microsoft a pass by building an analogy between their javascript engine and an 8th grade history student.
Just something to consider when you say we shouldn't be shocked by this.
My work here is dung.
Benchmarks are very nice and all, but in the end, users using different browsers for real should decide which *feels* faster or better (which isn't the same as being faster or better). If real-world users can't feel the difference, then benchmarks are just there for masturbation value, and quite frankly, on reasonably modern hardware, I've never felt any true difference in rendering speed between the various "big" browsers out there.
I reckon the only thing that truly matters is the speed at which a browser starts up without prefetching (another semi-dishonest technique used by Microsoft for years to make users believe their products start so much faster than the competition incidentally).
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Everything in italics is unsupported opinion by the author, yet is treated as fact in the summary and title by CmdrTaco and Slashdot. Perhaps if Slashdot would stick to actual news sites (you know NEWS for nerds and all that), this would be a balanced report with a good amount of information. Instead, it is just another Slashdot supported hit piece against MicroSoft.
FTFA:
There are three possible explanation for this weird result from Internet Explorer:
1. Microsoft cheated by optimizing Internet Explorer 9 solely to ace the SunSpider Bechmark. To me, this seems like the best explanation.
2. Microsoft engineers working on Internet Explorer 9 could have been using the SunSpider Benchmark and unintentionally over-optimized the JavaScript engine for the SunSpider Benchmark. This seems very unlikely to me.
3. A third option (suggested in Hacker News) might be that this is an actual bug and adding these trivial codes disaligns cache tables and such throwing off the performance entirely. If this is the reason, it raises a serious question about the robustness of the engine.
I'm not saying if what they have done is right or wrong, but this is a sensationalist headline that offers two other "less evil" alternatives to the outcome.
Meh I think claiming they are cheating with no evidence seems a little too out there. I've never seen MS brag about how fast their browser is on this particular benchmark, and frankly seems more like a bug than a cheat.
did you forget to take your meds?
Here's the google cache:
http://webcache.googleusercontent.com/search?q=cache:http://digitizor.com/2010/11/17/internet-explorer-9-caught-cheating-in-sunspider-benchmark/
Microsoft, cheating? Umpossible!
They ALWAYS cheat because its not in their organisational capacity to deliver something good. They deliver mediocre and then warp the surrounding world into their own desired image.
HTTP/1.1 400
The article clearly states:
There are three possible explanation for this weird result from Internet Explorer:
1. Microsoft cheated by optimizing Internet Explorer 9 solely to ace the SunSpider Bechmark. To me, this seems like the best explanation.
2. Microsoft engineers working on Internet Explorer 9 could have been using the SunSpider Benchmark and unintentionally over-optimized the JavaScript engine for the SunSpider Benchmark. This seems very unlikely to me.
3. A third option (suggested in Hacker News) might be that this is an actual bug and adding these trivial codes disaligns cache tables and such throwing off the performance entirely. If this is the reason, it raises a serious question about the robustness of the engine.
So, what proof do we have that Microsoft actually cheated?
He who knows best knows how little he knows. - Thomas Jefferson
And it leads me to a 500 internal server. Dohohoho, Microsoft.
This needs more cowbell!!!
Since when has IE ever been faster? And why bother cheating when you have 51% of the market share?
Browser share from Dec 2009 to Oct 2010
Embarrassing the article got slashdotted. Try the web site on port 8090.
http://digitizor.com.nyud.net:8090/2010/11/17/internet-explorer-9-caught-cheating-in-sunspider-benchmark/
Also embarrassing that you spelt "embarrassing" incorrectly. ;)
Embarrassing, it's CCed at nyud.net.
Perhaps Microsoft cheated intentionally. Perhaps it's accidental they over-optimised for the benchmark. Either way, their browser is again proven to be inferior than advertised, to the great disappointment and irritation of their developers and users alike. Seriously, I keep giving them the benefit of the doubt and I'm let down every time...
Why would it seem weird to develop TDD where SunSpider is the test. If that is the current best benchmark test, then normal browsing should be simple.
2) You are giving Microsoft a pass by building an analogy between their javascript engine and an 8th grade history student.
Indeed. The student would make a better Javascript engine.
No kidding!!! What do you say at this point?
MS decision makers ARE 8th grade-like.
Win at any cost, even if you have to give all your software away for people to choose it!
http://web.archive.org/web/19981202072738/http://www.mpeg.org/MPEG/mp3-licensing-faq.html
The following letter from Mr. Henri Linde (Thomson) explains the patent and licensing situation for MP3 (aka Layer-3) as of April 1998.
Business Answers MPEG Layer-3 - Version 04.98-3 ...thank you for your interest in our MPEG Layer-3 audio compression technology.
In this document you will find answers to the most frequently asked questions about MPEG Layer-3, the Fraunhofer Gesellschaft, THOMSON multimedia and the licensing of MPEG Layer-3 technology.
The Fraunhofer Gesellschaft.
The Fraunhofer Gesellschaft is the leading organization of applied research in Germany. It operates 47 research centers in Germany with about 9,000 employees, about half of them scientists and engineers. The Fraunhofer Gesellschaft expands to a worldwide Organization, especially in USA and Asia. Home of the Fraunhofer Gesellschaft is Munich.
One of the goals of the Fraunhofer policy is a rapid transfer of innovations into products. The total research expenditure is about US $ 700 million.
The Fraunhofer Institut Integrierte Schaltungen (Fraunhofer IIS), based in Erlangen, is one of the 47 research centers. In the field of high quality low bitrate audio coding, Fraunhofer IIS is the leading international research lab. Fraunhofer IIS has been the main developer of the most advanced audio coding schemes, like MPEG Layer-3 and MPEG-2 AAC (Advanced Audio Coding). Fraunhofer IIS plays a major role in the ongoing work for the MPEG-4 Audio standardization process and contributes to many other standards bodies as well, like ITU-R TG10/4, ITU-R WP10C, AES, MPEG-IPR, and others.
WWW: http://www.iis.fhg.de/audio/
THOMSON multimedia.
The world's fourth-largest consumer electronics group, THOMSON multimedia develops, manufactures and markets: televisions, VCRs, camcorders, audio and communication appliances, satellite decoders, DVD players, as well as color TV tubes and professional television equipment (studio equipment, TV cameras, mixers, etc.).
With its pan-European brands - THOMSON, TELEFUNKEN and SABA - and its American brands - RCA, GE and ProScan - today the group is the leader in the United States, No. 2 in Europe and is strongly increasing its market presence in Asia, Latin America and Eastern Europe.
WWW: http://www.thomson-multimedia.com/ http://www.rca-electronics.com/ or
http://www.nipper.com/
OPTICOM
OPTICOM is a "spin-off" firm from Fraunhofer IIS. OPTICOM was founded in 1995 with the intention to assist you in finding the technical solution best suited for you through consulting and specialized tools.
WWW: http://www.opticom.de/
I) GENERAL
Q. I am interested in source coding technology. What can you do for me?
A. Licensing source code, developing real-time DSP code as well as DSP-based hardware, and developing codec libraries for desktop computers is part of the Fraunhofer IIS activities. The focus is on (mobile) high-quality low bitrate audiovisual communications (e.g. digital broadcasting systems or internet services).
Q. Regarding MPEG Layer-3, do any patent rights exist?
A. As for practically any important technology (and particularly for publicly established standards), you should know that patent rights for MPEG Layer-3 exist. Although others may also hold patents related to the MPEG Layer-3 technology, THOMSON multimedia and Fraunhofer IIS have pooled their interests and grant licenses under their combined patent portfolio.
Q. Who grants licenses under this combined portfolio to use MPEG Layer-3?
A. We have split the licensing activities in three parts:
i) THOMSON multimedia ha
While MS-IE have disclosed a lot of information lately on their blogs, if they're going to discuss Sunspider results (as they did on 28 October with the IE9PP6 tests) then use of sleight of hand to sex them up is fair game for criticism.
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.
Does this part of the benchmark produce a result or output, and if so is it correct?
And if it doesn't produce any output or a result that's checked, there is plenty of scope for innocent explanations. It could be a bug that doesn't arise when the extra statements are added. Or it could be that part of the code is being optimised away (because the result isn't used) and the analysis isn't clever enough to handle it when the extra statements are present.
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.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Really? Are you sure about that that?
Second paragraph of the article:
The parent is not insightful, it is merely a troll.
The real "Libtards" are the Libertarians!
1) I'm not doing business with the 8th grader. Nor am I relying on his understanding and memorization of history to run Javascript that I write for clients.
No, but 5 years later you'll let him vote...
If he explores all forms and substances Straight homeward to their symbol-essences; He shall not die.
I don't know about those of you suggesting that this isn't cheating. I'm going to go ahead and agree with the author of the article on this one: it's most likely cheating, even following Hanlon's Razor.
To me, an order-of-magnitude difference in an interpreted language by adding non-functional statements is most likely due to using a compiled-in functional equivalent of that particular JavaScript function. The engine probably matches the parse tree to determine whether or not to run the (much faster) machine-code version, and the non-functional statements make the parse tree not match, thus reverting back to executing just-in-time.
Sure, it's possible that the reasoning behind this difference isn't to get ahead on this benchmark. But I'm going to use Occam's Razor to suggest that the order-of-magnitude difference is a result of using pre-compiled versions of specific JavaScript functions, rather than assuming that Microsoft engineers who can optimize that JavaScript function down to 1 ms (with, by the way, a 95% confidence interval of +/- 0.0%!!!!!!!) are incapable of optimizing a functionally equivalent but trivially different version of it below 19.5 ms (with a 95% confidence interval of +/- 1.9%)
http://blog.mozilla.com/rob-sayre/2010/11/16/reporting-a-bug-on-a-fragile-analysis/
Do daemons dream of electric sleep()?
... If you no cheat, you a LOOOOOSSSAAAAHHHHH.
Ok, that's just what my old Asian classmate who plays a lot of counterstrike says, whatever, same meaning.
Is this like the old Mac OS days where Apple fine tuned the OS to score better at graphics benchmarks, even though the rest still couldn't compete?
An enterprising Hacker News user has come up with some interesting and pretty conclusive results.
http://news.ycombinator.com/item?id=1913368
I am not really surprised but I refuse to single out Microsoft as the only company that behaves in this manner. I am willing to bet most corporations try and fudge tests and benchmarks here there to get ahead. It is done in the name of capitalism and marketing. Look at the methods by which vehicle fuel efficiency is tested. Fuel efficiency tests are suspect at best. I would leave Microsoft alone on this. In my opinion, all browsers suck equally. I have IE, Firefox, Safari and Chrome installed because there are features from all three that I like for different websites and browsing habits. If you could take the best features from all three, you would have the killer browser. In my sole opinion, Chrome sucks less than the others.
Maybe mozilla should hire 8th graders then :)
Putting a
return;
at the tail of a function is unusual? Are you high?
help me i've cloned myself and can't remember which one I am
Who cares about SunSpider or whatever, how about benchmarking end user expirience, I'm sure Firefox would end up last on those benchmarks (this post is written in FFX as I'm using it as my primary browser, and have been since the days before 256 name changes).
Did you submit it to /. at the time, or do you prefer to sit back and let everyone else do the work while you call them out on something that really has no detriment on your quality of life? Even if you didn't want to put in an iota of effort to spread the news, you could have just skipped the story when you saw it here instead of coming to whine. You're like the lazy guard who, when the villagers start screaming that attackers are only a couple hundred metres away, yawns and says "boring, I saw them when they were kilometres away". Well done.
So, what proof do we have that Microsoft actually cheated?
Since this is closed source, we can not verify what is going on, only MS can.
With FF, we can look at the code and pass judgment on the cheat vs bug question.
Never trust a man wearing a coat and tie!
Too bad TFA didn't link to the original blog post (http://blog.mozilla.com/rob-sayre/2010/09/09/js-benchmarks-closing-in/) nor the update (http://blog.mozilla.com/rob-sayre/2010/11/16/reporting-a-bug-on-a-fragile-analysis/) (in which a bug is allegedly filed, though nobody else can apparently see it).
--
Given enough personal experience, all stereotypes are shallow.
I would not hesitate a second to write code to detect a benchmark and supply optimized behavior.
The people who believe in stupid benchmarks and use them to make important decisions (or, at the very least, asses of themselves in forums) should be embarrassed, not benchmark cheaters.
What is the definition of cheating anyway? If the implementation accepts the benchmarking program and delivers a performance, that is a valid result, no matter how it was achieved. If a benchmark calculates the millionth digit of PI, it is a perfectly valid optimization to recognize that code and turn it into a literal constant which spews out the millionth digit of pi.
Yes, that optimization serves the implementors, not the user. So what? Where is the law that says the implementors of a software should not include code which serves them rather than the user? That is the privilege of the developer.
The dollar store (it's not the chain) next to me sells a full line of typical cables (RCA, HDMI, fibre, ethernet) for good prices and I've had no problems. No recognizable brand name - just "made in China".
Do you seriously see lots of superfluous, empty return statements at the end of functions in javascript? As an example, I just had a quick look at the source to this /. page and didn't find a single example of this. The only time you will ever see a return statement is if there is an early return within a function or a function returns a value. While it is valid to have an empty return statement at the end of a function, nobody ever does it.
In terms of optimising the javascript, the code in question contains a small loop with some straightforward calculations. There were no object handling, memory allocation, string manipulation, or DOM access. There is some array access, but obviously it is able to cope with that. It is a prime candidate for aggressive optimisation, which I suspect is why it performs so well.
Perhaps the mere existence of a return statement in a function is enough of a trigger for the optimiser to go into a conservative mode to ensure that it doesn't inadvertently introduce errors. Remember, the optimisation runs at runtime, and so has to be faster than one from an compiler and therefore must be fairly simple. If the optimisation process is too complicated, then it will end up being slower than just interpreting as you go.
Not unusual, but it makes the function 1 statement longer..
If you knew anything about JIT compilers, you would know that they have simple heuristics on purpose (compile speed is a strict constraint.) Making something 1 statement longer could remove it as a candidate for quite a few optimizations (inlining, static loop evaluation, loop unrolling, dead code elimination, etc..)
These simple heuristics use quickly evaluated metrics once the source is translated into an abstract syntax tree. The number of nodes in the tree.. the depth of the tree.. the number of conditional nodes..
JIT's are not simply compilers that try to produce the best code possible. JIT's make tradeoff decisions between compile time and the resulting code quality.
"His name was James Damore."
Actually MS hosts a huge repository of precompiled javascript snippets gathered by bing crawler and precompiled by M$, then IE just looks up correct snippets as bytecode in local snippet database and executes them fast.
So what they stumbled upon was a published javascript snippet that had a bytecode, so here the fast result.
However modified snippets will be downloaded as soon as bing crawls that discussion, and precompiled again, and pushed into next updates.
However the initial test was written poorly by using dead code. What if Mozilla decides to do deadcode optimization? Good test should actually check if calculated values do match (of course this doesn't exclude option of M$ precompiling actual function results)
so then, why do we tell the children it matters if they cheat? It matters, but not for about 11 more years.
Somebody ought to try simply turning the if-then-else statement around... i.e. instead of
if (TargetAngle > 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];
}
Use:
if (TargetAngle <= 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];
}
That’s perfectly logical. I’d try it myself, but I don’t have IE 9.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
It should first of all be noted that MS is one of the only companies with enough balls not to try to get 100/100 on acid 3 (many of the "requirements" are not part of any official and final specification). I see MS as being the *least* likely to cheat on pointless benchmarks.
Second, adding a return value *does* in fact make a huge difference in run time. There is a very large difference in the way the stack functions, and many optimizations can be made when there is no return value in a function. There are of course some other requirements for this to be possible, but I'm going to go ahead and assume that the JS engine is just being smart about running pointless code. This is not cheating. Perhaps they were encouraged to make this optimization in order to do better on the test, but it could still very well be a valid optimization.
Putting a return at the tail of a function is unusual?
Yes, actually, it is quite unusual. Note that we're not talking about "return x;" here but rather plain "return", which does not make any sense (as function will return anyway once its end is reached).
I don't know about JS, but for C# and Java, many IDEs would actually highlight such a statement as dead code, and prompt to remove.
Hi, we've posted an official response and explanation at the bottom of this post:
http://blogs.msdn.com/b/ie/archive/2010/11/17/html5-and-real-world-site-performance-seventh-ie9-platform-preview-available-for-developers.aspx
Bottom line - we built an optimizing compiler into the Chakra JavaScript engine that eliminates dead code where it finds it.
It's a fun conspiracy theory that we'd somehow 'game' SunSpider in this way, but it doesn't make sense that we'd go to all that risk to cheat on just one test out of 26.
Best wishes, Tim Sneath | Microsoft
Dhrystone went through the same thing. The first version was written not taking into account dead code elimination, and compilers capable of it pretty well eliminated it all, rendering it useless as a benchmark. Dhrystone 2.0 was revised to prevent dead code elimination, so that to run it you actually had to perform the operations the code was intended to perform.
So... when will we see SunSpider 2.0, and results of running it under various web browsers?
A lot of magazines just run all the benchmark tests and print the average of all the tests. Even a single test that comes back a lot quicker can change the average enough to make the overall results much better than your competitors results.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Honest question: where does it stop?
at the point where there's a financial incentive so people to it on their own.
the free market can regulate itself, but is very short-sighted.
people don't have incentive to split medical costs and spread them among a larger population to dampen the effect of a costly to heal/repare accident.
no incentive because nobody needs usually a doctor, not until they run into a problem and start needing one badly.
on the other hand a farmer, a baker, etc have an incentive : earning money by selling it.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
All the comments seem to assume M$ simply submitted to the test without doing any testing to see how they would do for slight changes. If so, we are talking about a FAR bigger problem than a simple cheat.
Any manufacturer, IMO, has a duty to test his product, especially when it is going into a benchmark. I would rather have a careful, conscientious manufacturer who (childishly) cheated a little, than a careless one who simply threw something out there.
But then, M$ has done that in the past. I would like to think they have improved, but maybe I am the careless one for hoping that.
http://blog.mozilla.com/rob-sayre/2010/11/17/dead-code-elimination-for-beginners/
Summary: The Chakra DCE "optimization" handles ++ but not --, > but not >. In short, it handles exactly the set of operators found in math-cordic, and not others. This makes no sense if it's intended to be a general-purpose optimization.
Furthermore, Sayre also points out that the optimization makes assumptions that aren't true for JS, leading to bugs where it incorrectly eliminates code that is not, in fact, dead.
If the IE result is precomputed, then find it in IE's memory footprint or elsewhere in its files. Find the code that matches the benchmark. Then decompile it. Now you have proof positive that it is cheating. That's what should have been done after the discovery, but before the announcement...