By: Exophase (exophase.delete@this.gmail.com), July 16, 2013 10:34 am
Room: Moderated Discussions
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.
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.
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).
> 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.
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.
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).
