[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Speeding [u]ltoa by 35%
From: |
Georg-Johann Lay |
Subject: |
Re: [avr-gcc-list] Speeding [u]ltoa by 35% |
Date: |
Sun, 01 Jul 2012 17:01:05 +0200 |
User-agent: |
Thunderbird 2.0.0.24 (Windows/20100228) |
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