In fact, you can probably dig up a few posts of mine where I responded to some of Ashraf's articles, and cautioned him that the AnTuTu score seemed a bit "too good to be true", relative to my own expectations for the product.
Absolutely you did, and if we were running in power unconstrained situations, there's no way I would have expected a quad A15/Krait to underperform a 2C/4T Saltwell. However, in a phone setting with a fixed power budget and essentially equal process technologies, it seemed plausible for CT+ to keep up. I was wrong, however, and will be writing a follow-up piece soon (I am out of town and have limited time, but will be back tomorrow, hopefully with a detailed analysis written).
That being said, CT+ will be phased out during Snapdragon 800/Tegra 4's life-time in exchange for Bay Trail in Q4, and then Merrifield hits in Q1 (but will be shipping in Q4), so I'm not sure if this Clover Trail "fiasco" will matter for much longer.
I know, I read that part. But while you might have missed the subtlety, this would evoke a "well, no shit" kind of statement from anyone who knows how this stuff works.
In other words, compilers are *supposed to* reduce unnecessary instructions, because that's how they improve performance. Fewer instructions means faster executing code. Now, if they had implied that ICC was eliminating *functionality* rather than instructions, that would be a different story, and potentially imply something more sinister.
But the reason I responded incredulously to this article is that they seem to be as naive about how compilers work as you and Andy are. There's a long history in compute benchmarks of using more efficient compilers to generate faster performance, and it was always most beneficial for companies to provide their own compilers to generate more efficient code - and the technical world had accepted that for a long time as a legitimate way of selling a full software/hardware solution.
Not sure why you are resorting to ad hominem attack on me, since you have little to no knowledge of my background with respect to compilers or any other field.
Having said that, there is also a difference between optimizations that are intended for real-world application improvements (which are supposed to do what you describe above) and optimizations that are intended purely to improve benchmark results. Without knowing how/why this particular compiler optimization arose, it is not possible to determine which case applies here. As others have suggested though, the timings of the compiler change raise suspicions.
But of course, that has an explanation, too. All the usual suspects who wait for the opportunity to pounce on a potential scandal for Intel are the ones coming out of the woodwork today. But once reality sets in and people realize there's no story, this too will be a part of history that no one remembers.
If you are including me as "usual suspects" in this case, you clearly have no idea of my background and motivation.