Re: [avr-gcc-list] Gcc branches small comparison.

[David Brown]

> 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).

mvh.,

David


>
> Maybe things like "Moore's Law" are setting unrealistic expectations for
> those of us in this business.  Is the Second Law of Thermodynamics
> affecting "gcc" development?  Is ever increasing entropy is somehow
> negatively affecting "gcc" source code tree! :-)
>
> Best regards,
>
> Bruce
>