Hello,
I've uploaded my latest test results with gcc 4.4.3 and the just
released binutils 2.20.1 to
http://www.rockbox.org/wiki/CodecPerformanceComparison. The new combo
does a bit better than the current 4.4.2/2.20 combo (reading the
binutils mailing list, 2.20 had quite a few bugs, especially related to
ARM).
The new toolchain is pretty close now in terms of codecs. The major
codecs are the same, or even faster. The only exception is FLAC, which
is a good deal slower. BUT I think flac is fast enough anyway, so we
shouldn't worry about it too much.
In regards to binsize/ram usage, the new version gives us a mostly huge
win. Around least ~64k on every PP, almost 60k on ipodnano2g, 50k on
mr5000. On targets that already have no long calls (sansa ams,
gigabeatfx), binsize is slightly increased (400-500 bytes) but ram usage
is decreased more (600-800 bytes). The beast wins 1k bin and 10k ram.
I'm proposing the switch since this is the first compiler in a long time
which works almost out of the box (it hasn't been tested on all arm
targets, but on many and it worked like a charm on all). I may emphasise
this reason because it could mean that we might be able to not brew our
own toolchain anymore, but instead let people be able to use the one
their distro provides soon. It also means a huge or at least decent
binsize and ram usage win for all arm targets. The speed is comparable
to the current toolchain (with the mentioned exception flac). Another
weak reason: We would be more standard conform, since eabi is the
standard ARM abi (but that doesn't really matter for our project). The
next may be imagination (or ccache influenced) but I feel the compile
time has reduced as well.
Are there any opinions?
- Proposal to update GCC for ARM Thomas Martitz
-
