Well said.

George Hotz ("geohot") tried his hand at it, given that he had been rather successful at cracking Apple's iStuff. He found an exploit that gave hypervisor access, and in response, Sony removed OtherOS in a firmware update, as geohot's hack required use of OtherOS.

So this can all be traced back to geohot getting involved... though in my opinion, Sony shouldn't have responded by removing OtherOS, causing all the collateral damage. It inevitably was going to result in a lot of really serious people getting involved and, by extension, more stories like this.

Nearly every legal expert who has spoken on this topic has argued that Wikileaks has not violated US law.

Publishing classified documents is not illegal, unless the documents fit certain criteria that (so far) these leaks do not. The person or organization who leaks the documents does have some liability, but not Wikileaks. As has been said many times before, Wikileaks is analogous to the New York Times in the Pentagon Papers incident.

Thank you for a comprehensive, readable explanation of the supply-and-demand model as it applies to digital (and other) sales. May this post be modded up to +5 Informative.

It makes for a pretty fun day at the museum, though.

Perhaps because it was very informative and well-supported with links.

Here's one that I'm particularly OK with. If I recall correctly, this was the first time that I had heard about ACTA.

Graham Syfert, the "Copyright Defense Lawyer", is an EFF-listed lawyer.

Do you think that the EFF accidentally mistook the manager of a "phoney storefront" for a lawyer credible enough to refer people to?

Interesting. After installing the platform preview and confirming the results of the article (1.0 ms, +/- 0%, exactly the same as Sayre and the author, even though the other times were different), I am also getting the same results when looking at your test.

Yeah, bit twiddling makes things faster, but I can think of a logical explanation for that one.
After you run "n += i" 92682 times, n can no longer fit in 32 bits, whereas all the bitwise operations fit comfortably within that range for all values of i, so you can avoid using the "much slower" bigints.

A more far-fetched but powerful explanation is that it could be optimizing certain kinds of iterated bitwise operations on vectors. Iteratively applying |=, ^=, and &= all can be done in O(1) time. Bitwise AND: all zeroes. Bitwise OR: ceil(log-base-2 of 50000000) == 26 binary ones at the end. Bitwise XOR: complicated, but doable. (i XOR n) is the current value. If i is even, then (i XOR n) XOR (i+1) == (n-1 if n is odd, or n+1 if n is even). (i XOR (n-1 if n is odd, or n+1 if n is even)) XOR (i+1) == (n). So, you can get any value of n for any odd value of i using modulo division, as it cycles between n and n +/- 1 on every odd value of i. Do another XOR if you need to figure it out for an even value of i.

I say this is "far-fetched", because it seems like this kind of optimization would rarely be worth the cost.

Next test (also helps to explain what changes when "g = n" is commented out):
"n += 1; n -= 1;" This adds 1 to and subtracts 1 from n each loop, which could hypothetically be optimized away. Observe what it does for commented and uncommented "g = n". I'd recommend increasing the max value of i by a factor of 100 to try and reduce the noise. It should take about a minute and a half or so for each on the machine that you got ~1600 ms for your code.

Hope this helps.

You're right. I should have narrowed the scope of my claim. My apologies.

That's how I would do it, too. Microsoft has a lot of smart people -- I'm sure many of them would have thought of that too.
But that didn't happen here. For some reason, it runs too quickly, quickly enough to warrant further scrutiny.

Actually, when you ignore the anomalous 1.0 ms, it runs around 2x longer than Chrome and between 2x-3x longer than Opera. I won't install FF4 to try it out, so I'll have to give you the benefit of the doubt on that one.

Of course. This is circumstantial, so it can't, by itself, prove that they cheated. I also haven't installed the preview to run it myself, yet. But, assuming that the benchmark times are accurate, it'll be hard argue that a benign explanation is more likely than cheating. That's all I'm saying.

Particularly, the 95% confidence interval of +/- 0.0% strikes me as the most suspicious. It's way too convenient that the test ends up taking the same amount of time, to a certain resolution, at least 95% of the time it is run, whereas the alternate spellings of it are much less consistent. Also... the same 1.0ms on different hardware (Sayre's testing machine as well as the author's laptop), all while keeping a 95% confidence interval of +/- 0.0%? That's... dare I say it... inconceivable!

The "roundness" of 1.0ms is convenient, too, but I'm not going to count that as a strike against them. Even though this whole thing is already circumstantial... sometimes, numbers are round.

When writing my post, I went by what Wikipedia said about that term, which conveniently accounts for JIT compilation in its description. Turns out there is such a thing!
I don't suggest that there are languages that must be interpreted, only languages that are interpreted (in this case, "interpreted" meaning "not directly executed", which includes JIT compilation).

That's why I'm suspicious about this: dead code probably should not cause an order of magnitude increase in running time.

Wow, you're absolutely correct. I just assumed that SunSpider actually checked to make sure that the engine came up with the correct values to catch this kind of thing. So it now seems more likely to me that it just says "if the code matches the cordic function, then sleep for 1 ms, and return." That actually makes more sense with the numbers we see.
So in this case, that code is probably just stubbed out. Why have a stub for a function used in a benchmark test if you're not treating the benchmark specially (which, I believe, is an example of cheating)?

That's what I was trying to say... it is more likely a symptom of cheating (at least some level of catering to the benchmark rather than to the JS code) than it is a symptom of a botched optimizer that can consistently (95% confidence interval: +/- 0.0%) optimize some code down to exactly 1.0 ms, but "somehow" manage to perform far, far worse than other existing browsers when changing the source in a trivial way, and "all of a sudden" become way more inconsistent (95% confidence interval: +/- 1.9%).

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%)

Interstate freeways in Michigan, USA carry a 70 MPH speed limit.

GM is based in Detroit, Michigan. Coincidence?

Just now, I searched, and it isn't.