Dmitry K. wrote:
Hi all.
Functions are from avr-libc-1.2.0, without ones too small or asm.
(`*-new' are from patches).
Results are in form: prog_words + stack_bytes
-mmcu=atmega8 -Os -frename-registers
3.2.3 3.3.5 3.4.3 4.0 4.0-nrr
bsearch 69+12 68+12 67+12 66+12 66+12
bsearch-new 70+12 70+12 69+12 76+14 76+14
malloc 164+2 152+0 156+2 158+2 158+2
free 99+2 92+2 92+2 86+2 86+2
qsort 464+22 450+22 450+22 412+22 412+22
do_random 102+14 91+10 93+10 173+14 173+14
realloc 240+12 230+12 228+12 233+14 234+14
strtol 308+36 291+36 295+36 318+36 312+36
strtol-new 286+16 276+16 281+16 297+17 297+17
strtoul 277+29 260+29 261+29 278+27 278+27
strtoul-new 278+16 265+16 264+16 317+21 317+21
vfprintf 672+36 652+36 626+36 694+37 694+37
vfscanf 655+24 637+24 601+24 725+39 726+39
Notes:
* Stack usage -- without nested calls.
* 4.0 is 20050116
* `-frename-registers' is not recommended in 4.0, so `4.0-nrr' is
without this option.
Thank you for taking the time to run these benchmarks and share the
results with us!
The results for 4.0 clearly suck! These are big differences for
microcontrollers with very limited memory space. Can you explain
what is
going on?
Or, am I being stupid assuming that things will *always* get better as
time goes on?
As far as I understand it, gcc 4.x uses a very different internal
structure
for the program whose main benifit is the *potential* for better code,
optimisation, and checking. I'd be very impressed if a jump to a new
structure had lead to all-round better code at the first attempt. You
can
expect progress towards better (smaller and faster) code on average,
but you
can also expect the odd bump in the road. When gcc 3.x first arrived,
it
was not until 3.1 (or even 3.2) that it was considered "mainstream" and
consistently made better code (for x86) than the old 2.95. So I see
it as
showing solid progress in 4.0, but I'd wait a while before using it
for main
development work.
Also missing from these benchmarks is any information on run-time
speed.
Sometimes there's a tradeoff between code speed and code size, and
different
uses want different choices here. Without run-time speed information,
it is
difficult to compare compilers fairly (note to Dmitry - I fully
appreciate
that getting this information would be far more effort than generating
the
size comparisons).