By: none (none.delete@this.none.com), July 16, 2013 6:34 am
Room: Moderated Discussions
bakaneko (nyan.delete@this.hyan.wan) on July 16, 2013 6:25 am wrote:
> anon (no.delete@this.email.com) on July 16, 2013 1:07 am wrote:
> > bakaneko (nyan.delete@this.hyan.wan) on July 15, 2013 2:03 am wrote:
> > > Steve (sberens.Throwaway.delete@this.gmail.com) on July 14, 2013 8:10 pm wrote:
> > > > > > No. It shows that Intel's optimization is still superior to others. (Closest one is VC not GCC/CLANG)
> > > > >
> > > >
> > > > Actually Intel's optimization is still superior in one way. Removal of code
> > > > that is actually needed in benchmarks thus inflating benchmark results to beat
> > > > the competition then post said tainted results or hire a lacky to do it.
> > >
> > > No, it's not lackeys, or evil conspiracies.
> > >
> > > The compiler does it because this is what expected
> > > from it while compiling normal programs.
> > >
> > > The opposite could be made out: Programming
> > > languages don't have anti-optimization features
> > > for writing benchmarks. But that hits all
> > > compilers.
> >
> > What a lot of blinkered BS..
> >
> > Care to explain then why a non standard android compiler was used with selected high
> > optimisation flags (ICC does none of this by default..) for the intel path, and the completely
> > default gcc was used for the arm path with zero attempt to even set a flag?
>
> Actually, gcc's flag are set to
>
> CFLAGS = -s -static -Wall -O3
>
> in nbench-byte-2.2.3/Makefile
>
> Until now I haven't seen anybody actually talk
> about this here.
>
> > The compilers abilities means nothing here, the methodology of building the
> > benchmark is where the 'cheating' happened. Do you not understand that?
>
> My problem is the methology how some people
> come to conclusions. Even you didn't look
> at the f*cking Makefile but just assumed there
> was no attempt to even set a flag.
>
> Wilco didn't know about that you can use ICC
> with NDK, but claims to have worked at ARM
> half a decade ago. (And it took me 10 seconds
> on google to find it as first link).
>
> Anybody can come up with the connection
> "pretty graph" -> "weird benchmark results"
> -> "Intel is evil", but how you got there
> matters.
Proving that -O3 wasn't used to build AnTuTu is trivial. If you're not even able to check that yourself, I don't understand why you keep posting and ridiculing yourself. You simply seem to have no clue what you are talking about, but you insist.
For people interested, getting to it is easy: compile nbench with the NDK flags which were already given in that thread, and compare the disassembly of ToggleBitRun. Changing a single option to increase optimization completely changes the code and removes the use for ABI mul/mod function when constants are used (e.g. in DoBitfieldIteration).
> anon (no.delete@this.email.com) on July 16, 2013 1:07 am wrote:
> > bakaneko (nyan.delete@this.hyan.wan) on July 15, 2013 2:03 am wrote:
> > > Steve (sberens.Throwaway.delete@this.gmail.com) on July 14, 2013 8:10 pm wrote:
> > > > > > No. It shows that Intel's optimization is still superior to others. (Closest one is VC not GCC/CLANG)
> > > > >
> > > >
> > > > Actually Intel's optimization is still superior in one way. Removal of code
> > > > that is actually needed in benchmarks thus inflating benchmark results to beat
> > > > the competition then post said tainted results or hire a lacky to do it.
> > >
> > > No, it's not lackeys, or evil conspiracies.
> > >
> > > The compiler does it because this is what expected
> > > from it while compiling normal programs.
> > >
> > > The opposite could be made out: Programming
> > > languages don't have anti-optimization features
> > > for writing benchmarks. But that hits all
> > > compilers.
> >
> > What a lot of blinkered BS..
> >
> > Care to explain then why a non standard android compiler was used with selected high
> > optimisation flags (ICC does none of this by default..) for the intel path, and the completely
> > default gcc was used for the arm path with zero attempt to even set a flag?
>
> Actually, gcc's flag are set to
>
> CFLAGS = -s -static -Wall -O3
>
> in nbench-byte-2.2.3/Makefile
>
> Until now I haven't seen anybody actually talk
> about this here.
>
> > The compilers abilities means nothing here, the methodology of building the
> > benchmark is where the 'cheating' happened. Do you not understand that?
>
> My problem is the methology how some people
> come to conclusions. Even you didn't look
> at the f*cking Makefile but just assumed there
> was no attempt to even set a flag.
>
> Wilco didn't know about that you can use ICC
> with NDK, but claims to have worked at ARM
> half a decade ago. (And it took me 10 seconds
> on google to find it as first link).
>
> Anybody can come up with the connection
> "pretty graph" -> "weird benchmark results"
> -> "Intel is evil", but how you got there
> matters.
Proving that -O3 wasn't used to build AnTuTu is trivial. If you're not even able to check that yourself, I don't understand why you keep posting and ridiculing yourself. You simply seem to have no clue what you are talking about, but you insist.
For people interested, getting to it is easy: compile nbench with the NDK flags which were already given in that thread, and compare the disassembly of ToggleBitRun. Changing a single option to increase optimization completely changes the code and removes the use for ABI mul/mod function when constants are used (e.g. in DoBitfieldIteration).
