Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on July 16, 2013 3:47 am wrote:
> bakaneko (nyan.delete@this.hyan.wan) on July 16, 2013 2:42 am wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 15, 2013 8:45 pm wrote:
> > > bakaneko (nyan.delete@this.hyan.wan) on July 15, 2013 7:47 pm wrote:
> > > >
> > > > As someone who works for ARM as compiler writer,
> > > > why don't you tell us in more detail how Intel
> > > > cheated?
> > >
> > > Exophase's post to anandtech was quoted here earlier, I think. It has the relevant details:
> > >
> > > http://forums.anandtech.com/showthread.php?t=2330027
> > >
> > > and quite frankly, while optimizing multiple bit operations into a word is a very
> > > valid optimization, the code icc generates there seems a fair bit past that.
> > >
> > > Sure, it could in theory happen with a really smart compiler and lots of generic optimizations.
> > > In practice? It really smells like the compiler actively targeting a very particular code-sequence.
> > > IOW, compiler cheating. The timing that Exophase points out makes it look worse.
> > >
> > > And Wilco is right that it smells pretty bad when AnTuTu seems to be so close to
> > > intel, and seem to have bent over backwards using recent versions of icc etc.
> > >
> > > It's all "explainable". But it doesn't pass the smell test.
> >
> > It's also all besides the point. I would expect a better
> > explanation from someone who claims to know their shit about
> > compilers than a logical fallacy ("Intel improved their
> > compiler recently", "Intel is cheating because it hits one
> > function in a certain benchmark"). Instead he nags like his
> > marriage has gone bad.
>
> If you had actually read the whole thread including the links to various articles I posted
> then you would have found the detailed explanation that makes it obvious that Intel has been
> cheating AnTuTu. Why should I explain all the details again in every post I make?

I read the whole thread, but for some reason don't remember
anything noteworthy.

> > And no, the ICC results aren't that far fetched. Intel
> > actually recommends -O3 -xSSSE3_ATOM* with the NDK. Which
> > could also explain why Exophase saw optimizations which
> > would be counterproductive for bigger programs. (If the
> > flags have similar meaning to gcc, where inlining and loop
> > unrolling have similar problems.)
>
> Given the ICC results already dropped 20% after minor changes in AnTuTu it seems this
> optimization is no longer effective. And that proves it was very specific to the actual
> source code rather than a generic optimization that any compiler does.

How is setting/clearing a range of bits not a useful
optimization?

And how does this - just because this is not an optimization
any compiler does (Or at least gcc with -Os) - suddenly make
this an benchmark busting trick? Oh, yes because the time
frame fits.

Here is my conspiracy theory: It was Linus' fault. He
wanted this optimization because he saw that Microsofts
mobile OS was too good. That's why he made a dirty deal
with Intel to add this optimization after Microsoft released
their mobile version.

The plan succeeded and Windows 8 flopped because dumb
consumer whores or blablabla something. :o)

Meh, writing this is boring. And I don't get paid for the
pain.

> > Smelling is good and all, but doesn't mean you should leave
> > out verifying your claims.
>
> Exophase, Jim McGregor on EETimes and Jeff Bier on BDTI did already provide all the details.
> So if you want to know more, just go and read their articles. If afterwards you have
> specific questions about the optimizations, post them here, and I'll explain.

I read Exophase's post and probably EEtimes (if there was
only one article on EETimes), not yet Heff Bier's blog
entry(?).

Yet, I doubt some of Exophases conclusions (the part about
how useful or hard this optimization is), and the EEtimes
was, AFAIK only about pointing out how AnTuTu is bad and
then everyone was patting each others head for a good job
done (probably, I don't remember anything useful from this
and if I don't get a serious reason to read it again I
won't).