By: bakaneko (nyan.delete@this.hyan.wan), July 16, 2013 2:42 am
Room: Moderated Discussions
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.
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.)
Smelling is good and all, but doesn't mean you should leave
out verifying your claims.
(I have forgotten why I wrote the reply to Wilco in the
first place, but I will leave it here.)
* http://software.intel.com/en-us/articles/intel-for-android-developers-learning-series-7-creating-and-porting-ndk-based-android
> 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.
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.)
Smelling is good and all, but doesn't mean you should leave
out verifying your claims.
(I have forgotten why I wrote the reply to Wilco in the
first place, but I will leave it here.)
* http://software.intel.com/en-us/articles/intel-for-android-developers-learning-series-7-creating-and-porting-ndk-based-android
