Thanks Bero. Sending this extremely useful information out to a wider audience.
Alex,
I think you're probably be very interested in this for your Mozilla work.
-O3 * What is is, does, available on
-O3 enables several additional compiler optimizations such as tree vectorizing and loop unswitching, and optimizes for speed over code size somewhat more aggressively than -O2, e.g. by inlining all calls to small static functions. It is available on any platform supported by gcc.
OpenMP * What is is, does, available on
OpenMP is a simple API that makes it easier for a programmer to make use of multi-core or multi-processor systems, e.g. by automatically splitting marked loops into several threads. Example:
#pragma omp parallel for for(int i=0; i<100; i++) do_something(i);
Would use up to 100 threads to do its job.
It is available on plaforms supported by gcc that can use libgomp, gcc's OpenMP library. This includes most platforms that support POSIX threads - but -- initially -- not Android.
Loop parallelization * What is is, does, available on
Loop parallelization takes OpenMP a step further by automatically determining which loops are suitable for "#pragma omp parallel for" and similar constructs. This allows code that was written without multiprocessing in mind (such as most code written specifically for ARM platforms - multicore/SMP ARM systems are quite new) to take advantage of multicore/SMP systems (to some extent) without having to modify the code.
Compiler flag: -ftree-parallelize-loops=X (where X is the number of threads to be optimized for - typically the number of CPU cores in the target system)
Available on anything supported by gcc that has both libgomp and graphite (incl. CLooG, PPL or ISL) - the original Android toolchain has neither of those.
...and any other optimizations that you've done.
None of the following is enabled yet (but the support in the toolchain is there now), but I'm planning to enable them step by step once we have systems built w/ the new toolchain that actually boot:
binutils: --hash-style=gnu By default, ld creates SysV style hash tables for function tables in shared libraries. With --hash-style=gnu, we switch to GNU style hashes, making symbol lookup a lot faster. (details: http://sourceware.org/ml/binutils/2006-10/msg00377.html)
binutils: -Bsymbolic-functions Speed up the dynamic linker by binding references to global functions in shared libraries where it is known that this doesn't break things (it's safe for libraries that don't have any users trying to override their symbols - it's probably safe to assume e.g. skia and opengl could benefit). (details: http://www.fkf.mpg.de/edv/docs/intel_composer/Documentation/en_US/compiler_f...)
binutils/gcc: -flto, -fwhole-program Link-Time Optimization - causes code to be optimized again at link time, when the compiler knows what functions are called form what parts of the code, what functions are only called with constant parameters, etc.
gcc: -mtune=cortex-a9 (or whatever the actual target CPU is) The Android build system uses -march=arm-v7a, which is good -- but it doesn't do any tuning for the specifc CPU type (e.g. cortex-a8 vs. cortex-a9).
gcc: -fvisibility-inlines-hidden Don't export C++ inline methods in shared libraries. Makes the symbol table smaller, improving startup time and diskspace efficiency
gcc: -fstrict-aliasing -Werror=strict-aliasing Currently, Android uses -fno-strict-aliasing unconditionally for thumb code, to work around some pieces of code that violate strict aliasing rules. Using -Werror=strict-aliasing, we can determine what pieces of code are affected, and fix them, or limit the use of -fno-strict-aliasing to the specific files that need it - enabling the rather useful strict-aliasing optimization for the rest of the build
gcc: Investigate Graphite optimizations that aren't even enabled at -O3: -fgraphite-identity -floop-block -floop-interchage -floop-strip-mine -ftree-loop-distribution -ftree-loop-linear
On Sat, Aug 20, 2011 at 7:13 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Thanks Bero. Sending this extremely useful information out to a wider audience.
Alex,
I think you're probably be very interested in this for your Mozilla work.
-O3 * What is is, does, available on
-O3 enables several additional compiler optimizations such as tree vectorizing and loop unswitching, and optimizes for speed over code size somewhat more aggressively than -O2, e.g. by inlining all calls to small static functions. It is available on any platform supported by gcc.
OpenMP * What is is, does, available on
OpenMP is a simple API that makes it easier for a programmer to make use of multi-core or multi-processor systems, e.g. by automatically splitting marked loops into several threads. Example:
#pragma omp parallel for for(int i=0; i<100; i++) do_something(i);
Would use up to 100 threads to do its job.
It is available on plaforms supported by gcc that can use libgomp, gcc's OpenMP library. This includes most platforms that support POSIX threads - but -- initially -- not Android.
Loop parallelization * What is is, does, available on
Loop parallelization takes OpenMP a step further by automatically determining which loops are suitable for "#pragma omp parallel for" and similar constructs. This allows code that was written without multiprocessing in mind (such as most code written specifically for ARM platforms - multicore/SMP ARM systems are quite new) to take advantage of multicore/SMP systems (to some extent) without having to modify the code.
Compiler flag: -ftree-parallelize-loops=X (where X is the number of threads to be optimized for - typically the number of CPU cores in the target system)
Available on anything supported by gcc that has both libgomp and graphite (incl. CLooG, PPL or ISL) - the original Android toolchain has neither of those.
...and any other optimizations that you've done.
None of the following is enabled yet (but the support in the toolchain is there now), but I'm planning to enable them step by step once we have systems built w/ the new toolchain that actually boot:
binutils: --hash-style=gnu By default, ld creates SysV style hash tables for function tables in shared libraries. With --hash-style=gnu, we switch to GNU style hashes, making symbol lookup a lot faster. (details: http://sourceware.org/ml/binutils/2006-10/msg00377.html)
Sorry, silly question, but does Android use the glibc dynamic linker? If not, does its linker support other hash styles?
binutils: -Bsymbolic-functions Speed up the dynamic linker by binding references to global functions in shared libraries where it is known that this doesn't break things (it's safe for libraries that don't have any users trying to override their symbols - it's probably safe to assume e.g. skia and opengl could benefit). (details: http://www.fkf.mpg.de/edv/docs/intel_composer/Documentation/en_US/compiler_f...)
binutils/gcc: -flto, -fwhole-program Link-Time Optimization - causes code to be optimized again at link time, when the compiler knows what functions are called form what parts of the code, what functions are only called with constant parameters, etc.
gcc: -mtune=cortex-a9 (or whatever the actual target CPU is) The Android build system uses -march=arm-v7a, which is good -- but it doesn't do any tuning for the specifc CPU type (e.g. cortex-a8 vs. cortex-a9).
Good. Using -march=armv7-a -mtune=cortex-a9 enables the Cortex-A8 fixups. Using a -mcpu=cortex-a9 disables them which means your build may not run on an A8.
gcc: -fvisibility-inlines-hidden Don't export C++ inline methods in shared libraries. Makes the symbol table smaller, improving startup time and diskspace efficiency
gcc: -fstrict-aliasing -Werror=strict-aliasing Currently, Android uses -fno-strict-aliasing unconditionally for thumb code, to work around some pieces of code that violate strict aliasing rules. Using -Werror=strict-aliasing, we can determine what pieces of code are affected, and fix them, or limit the use of -fno-strict-aliasing to the specific files that need it - enabling the rather useful strict-aliasing optimization for the rest of the build
gcc: Investigate Graphite optimizations that aren't even enabled at -O3: -fgraphite-identity -floop-block -floop-interchage -floop-strip-mine -ftree-loop-distribution -ftree-loop-linear
Looks good. I'd add SMS to the list as well: first -fmodulo-sched, then -fmodulo-sched -fmodulo-sched-allow-regmoves.
On 21 August 2011 15:00, Michael Hope michael.hope@linaro.org wrote:
Sorry, silly question, but does Android use the glibc dynamic linker?
No, they really like reinventing the wheel. Bionic comes with its own dynamic linker.
If not, does its linker support other hash styles?
It looks like it supports both the sysv and gnu styles. It uses libelf to do most of its ELF parsing, and libelf seems to do the right thing.
Good. Using -march=armv7-a -mtune=cortex-a9 enables the Cortex-A8 fixups. Using a -mcpu=cortex-a9 disables them which means your build may not run on an A8.
Right... On really A9 specific builds (like Pandaboard), we may want to add -Wl,--no-fix-cortex-a8 as well so we don't get any penalties for old CPUs
gcc: Investigate Graphite optimizations that aren't even enabled at -O3: -fgraphite-identity -floop-block -floop-interchage -floop-strip-mine -ftree-loop-distribution -ftree-loop-linear
Looks good. I'd add SMS to the list as well: first -fmodulo-sched, then -fmodulo-sched -fmodulo-sched-allow-regmoves.
Good point
ttyl bero
2011/8/22 Bernhard Rosenkranzer bernhard.rosenkranzer@linaro.org:
On 21 August 2011 15:00, Michael Hope michael.hope@linaro.org wrote:
Sorry, silly question, but does Android use the glibc dynamic linker?
No, they really like reinventing the wheel. Bionic comes with its own dynamic linker.
hi Bernhard and Michael,
The dynamic linker is file "/system/bin/linker".
If not, does its linker support other hash styles?
It looks like it supports both the sysv and gnu styles. It uses libelf to do most of its ELF parsing, and libelf seems to do the right thing.
I don't think so. Since Android uses the libelfcopy[2], derived from some really old parts in binutils, providing the facilities about DWARF/ELF, we would need extra modifications like the attached patch.[*]
Also, bionic linker changes are required. Another attachment contains the 0xlab internal modifications.
Sincerely, -jserv
[*] The related patches are expected to be submitted to AOSP Gerrit recently.
-
Bernhard Rosenkranzer -
Jim Huang -
Michael Hope -
Zach Pfeffer