Exophase (exophase.delete@this.gmail.com) on July 16, 2013 10:34 am wrote:
> bakaneko (nyan.delete@this.hyan.wan) on July 16, 2013 6:25 am wrote:
> > 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.
>
> It's you who doesn't know the first thing about Android native programming or even the software
> you're looking at. The native code that was compiled into libabenchmark.so couldn't have
> been built with nbench's makefile. For one thing, it's a library shared object and not an
> executable. For another thing it includes a whole bunch of crap that isn't part of nbench.
> Why not exercise some common sense before running your mouth about assumptions.

You are right, using the original makefile doesn't
work.

Doesn't mean you shouldn't read it first, so you
can actually write a Makefile that builds the
software.

And -O3 is on the second uncommented line.

> And no you can't "use ICC with NDK", NDK is literally the toolchain that Google provides and doesn't include
> ICC - if you use ICC you're no longer using the NDK. Google also doesn't provide any documentation for how
> to substitute GCC with ICC in the NDK. Google would prefer you didn't use NDK to begin with, but if you're
> going to of course they're going to want you to stick to their official package instead of modifying it.

If you compile to machine code, then you will
waste a lot of additional man hours. At least
get the best out of it and use the best
compiler for that situation.

Not that this matters much for a memory
benchmark.

I think I already posted the link to Intel's
HOWTO ICC with NDK, so I'm not going to post
it again.

> I wouldn't see much problem with using ICC if AnTuTu documented this (since it's pretty unintuitive that
> they'd do so). The problem is that they ARE using the standard NDK for the other builds. Compiler flags
> aside GCC 4.7.x and 4.8.x would generate better ARM code than what's currently used in the NDK (4.6.3).

My guess is they didn't use the ARM compiler
because they aren't allowed to post benchmark
results with binaries produced from it. Or
they couldn't make it work.

Otherwise, I'm with the "why did they not
use -O3 from the original makefile" question.

But this could also be because Android has
some problems with code generated like that.

Or the person who was responsible for this
benchmark knew more about ICC than gcc and
went at one point "fuck it".

whatever, old news by now.