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.