If you’ve compiled an Android kernel or two, you have undoubtedly noticed that there are more than a few cross-compiler toolchains at your disposal. Although Google offers its own toolchain as part of the Android Native Development Kit (NDK), several aftermarket options exist—many of which promise higher target device performance.
So what’s a new developer to do? Since kernel devs ultimately wish to eke out as much device performance as humanly possible, choosing the wrong toolchain could potentially have disastrous results. And without any firm guidance as to which toolchains work best, it’s easy to get lost in the available choices.
To alleviate this problem, XDA Recognized Developer Ezekeel decided to run extensive benchmarks with four popular toolchains. And much to the content of the obsessed, he has even tested the toolchains with and without the popular flags -fgcse-after-reload and -ftree-vectorize. In the words of the developer:
I have read of lot of praise for these optimized TC from different kernel developers that all claim that these do much better than the offcial Google TC, however to my knowledge up until now nobody actually took the effort of investigating the effect of the TC and most devs simply assume that a TC marketed as optimized by their creators is actually performing better.
So to investigate the performance of the different TC, I compiled a kernel (GLaDOS kernel for ICS) with the following four different TC:
1. Offical Google arm-linux-androideabi-4.4.3 (part of android-ndk-r7)
2. CodeSourcerey arm-2011.03-41-arm-none-linux-gnueabi
3. Linaro android-toolchain-eabi-linaro-4.6-2011.11-4-2011-11-15_12-22-49-linux-x86
4. Mjolnir arm-eabi-4.6-mjolnir-20111006
Also while I was at it, I investigated the effect of the compiler flags ‘-fgcse-after-reload’ and ‘-ftree-vectorize’ (see https://github.com/Ezekeel/GLaDOS-ne…f32ee#comments) by compiling a version with the CS TC which did not include these flags.
I performed the following two tests for the kernels:
Test I: Measured the bootup time including a rebuild of the Dalvik-cache after a wipe (2 times).
Test II: Performed a benchmark with AnTuTu Benchmark v2.4.3 including CPU/memory, 2D and 3D graphics (3 times).
Long story short, the allegedly optimized toolchains yielded no real world performance gains. At this point, you’re probably salivating at the mere thought of viewing the benchmarks. To get started, continue on to the original thread and join in on the discussion._________