bakaneko (nyan.delete@this.hyan.wan) on July 16, 2013 5:50 am wrote:
> 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?

Nobody sets multiple adjacent bits in memory one at a time. Even if one did so it would typically be a few bits, certainly not hundreds or thousands. Having seen and written various implementations of bit-sets I know how the typical ones look like.

> 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.

Nobody writes code like this, so no compiler implements this optimization. So yes, ICC gaining this optimization just before AnTuTu switched to ICC is proof that the optimization was added to break AnTuTu. If ICC had implemented this particular optimization for many years then it would be a different matter of course (although that still doesn't explain exactly why AnTuTu switched to a non-standard compiler with options tuned for AnTuTu just for x86).

> 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.

Shame, I really thought you were on to something there...

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

Well if you believe the optimization is commonly used then it wouldn't be hard to find another compiler besides ICC which does it, right?

Wilco