tag:support.primatelabs.com,2011-01-31:/discussions/geekbench/1317-geekbench-3-compile-options-for-ios-and-for-android-armPrimate Labs: Discussion 2013-12-16T04:55:28Ztag:support.primatelabs.com,2011-01-31:Comment/283649142013-08-29T07:22:15Z2013-08-29T07:22:15ZGeekbench 3 compile options for iOS and for Android (ARM)<div><p>I'm sorry for the delay in getting back to you.</p>
<p>Geekbench 2 for iOS is built with GCC 4.2, while Geekbench 2 for
Android is built with GCC 4.6. We use conservative compiler
optimizations (<code>-Os</code>) on both platforms.</p>
<p>Geekbench 3 for iOS is built with Clang 3.3, while Geekbench 3
for Android is built with GCC 4.8. We use aggressive compiler
optimizations (<code>-O3 -ffast-math -fvectorize</code>) on both
platforms.</p>
<p>One of the reasons for the big jump in iOS scores is that GCC
4.2 had poor ARM code generation, especially when compared with
more modern compilers like Clang 3.3 and GCC 4.6. We think
switching to the latest compilers has "leveled the playing field"
(so to speak) between Android and iOS.</p>
<p>Let me know if you have any other questions and I'd be happy to
help out.</p></div>Johntag:support.primatelabs.com,2011-01-31:Comment/283649142013-08-30T10:39:39Z2013-08-30T10:39:40ZGeekbench 3 compile options for iOS and for Android (ARM)<div><p>Thanks John, makes sense.</p>
<p>For the complete set, what compiler/options are used for x86 on
Android for both GB2 and GB3?</p>
<p>Regards.</p></div>redbluetag:support.primatelabs.com,2011-01-31:Comment/283649142013-09-04T06:06:58Z2013-09-04T06:07:15ZGeekbench 3 compile options for iOS and for Android (ARM)<div><p>Geekbench 2 for Android uses GCC 4.6 for x86 with similar
optimization flags (<code>-Os</code>).</p>
<p>Geekbench 3 for Android uses GCC 4.8 for x86 with similar
optimization flags (<code>-O3 -ffast-math -ftree-vectorize</code>).
We do specify additional flags to tune for the Atom architecture
(<code>-mtune=atom -maes -msse2</code>). Note that we do the same
for ARMv7 as well (<code>-march=armv7-a -mfloat-abi=softfp
-mfpu=neon</code>).</p>
<p>Again, let me know if you have any other questions and I'd be
happy to help out.</p></div>Johntag:support.primatelabs.com,2011-01-31:Comment/283649142013-09-04T09:33:39Z2013-09-04T09:33:41ZGeekbench 3 compile options for iOS and for Android (ARM)<div><p>Thanks John,</p>
<p>It's been awhile since I've looked at the various compile
options, but if building for v7, shouldn't the abi option be
hardfp? Using hardfp can have a significant effect on
performance:</p>
<p><a href=
"https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks">https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks</a></p>
<p>I guess there could be other dependencies that are forcing the
softfp option.</p>
<p>Regards,</p></div>redbluetag:support.primatelabs.com,2011-01-31:Comment/283649142013-09-06T02:10:44Z2013-09-06T02:10:44ZGeekbench 3 compile options for iOS and for Android (ARM)<div><p>My understanding is that softfp is a required compiler flag for
Android (it's what the NDK uses for both ARMv5 and ARMv7 code).
Also, we've shared our compiler settings with a number of Android
device manufacturers, and none suggested switching from softfp to
hardfp.</p>
<p>That said, we'll certainly look into switching from softfp to
hardfp. I don't expect it would make much of a difference, though,
since the number of function calls in our floating point workloads
is pretty minimal (BlackScholes and FFT being the two notable
exceptions).</p></div>Johntag:support.primatelabs.com,2011-01-31:Comment/283649142013-12-01T10:28:51Z2013-12-02T19:36:54ZGeekbench 3 compile options for iOS and for Android (ARM)<div><p>Given that using the "recommended" softfp flag in Android gives
worse results that hardfp in devices with FPU, I suggest you could
switch to hardfp when hadware FPU is detected. As you know, this
can be done at run time.</p>
<p>Usually FPU intensive or FPU mainly dependant android ndk apps
use hardware floating point unit where available. Because of this I
think is more equitable you use this FPU when available in
GeekBench to give more realistic and comparable results for Android
devices.</p>
<p>Regards</p>
<p>Oscar</p></div>Oscartag:support.primatelabs.com,2011-01-31:Comment/283649142013-12-07T05:07:34Z2013-12-07T05:07:34ZGeekbench 3 compile options for iOS and for Android (ARM)<div><p>Hi Oscar,</p>
<p>Thank you for your message.</p>
<p>We have tried to use <code>--mfloat-abi=hard</code> calling
convention with Geekbench 3 for Android but it doesn't work as
Android libraries expect the <code>--mfloat-abi=soft</code> calling
convention.</p>
<p>Don't forget that with both calling conventions floating point
operations are still performed using hardware. We might see a small
speedup when switching from <code>soft</code> to <code>hard</code>
on workloads such as BlackScholes, but generally function call
overhead is small compared to the computation time.</p>
<p>Let me know if you have any other questions and I'd be happy to
help out.</p>
<p>Best,<br>
John</p></div>John