Re: [avr-gcc-list] Speeding [u]ltoa by 35%

[Georg-Johann Lay]

Dmitry schrieb:
> Fine!
>
> I have check the speed with a set of bases and AVR types.
> The number of MCU clocks is:
>
>                     at90s8515          atmega8
>                   8   10   16      8   10   16
>               ---------------  ---------------
>  Old ultoa()   5798 5732 4510   5732 5666 4458
>  New ultoa()   3165 3143 2385   3161 3139 2381
>    sprintf()   1570 2581 1412   1490 2456 1342
>
> The value is 123456789L

There is an R plot showing ticks consumed by new ltoa
with respect to ticks consumed by sprintf.

The time for 123456789 is the last line of "raw data".

https://sourceforge.net/apps/mediawiki/mobilechessboar/index.php?title=File:Sprintf-ltoa.png

It's only base 10 for ATmega168 and does not factor out
overhead on either side, i.e. strrev for ltoa and general
printf overhead for sprintf.

The time for ltoa is basically the same, but the time for
sprintf is off by about 200 ticks.

Where do these 200 ticks come from? I use avr-libc 1.8.0
built with avr-gcc 4.7.1 + PR53595. Does 4.7.1 lead to
such speed decrease?

Concerning sprintf: what's the avr-libc policy here?
Prefer speed over size? The plot indicates that for
numbers up to 5 digits the new ltoa can compete with sprintf,
whereas __ultoa_invert eats up ~180 bytes.

new ltoa consumes ~100 bytes, new ultoa consumes ~60 bytes;
and the new versions no more drag __[u]divmodsi4.

Couldn't __ultoa_invert reuse ultoa? The latter does not use
T flag so that T could be used to parameterize out the sprintf
needs, i.e. premature return without writing final \0 and strrev.

I's say times for radix=8 are not so important, thus __ultoa_invert
could handle radix=16 and forward to ultoa for radix != 16.

Johann