Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?

[David Brown]

Dmitry K. wrote:
> On Saturday 03 March 2007 07:57, Eric Weddington wrote:
> > > Today, there is a bit of functions (memset, memcpy and
> > > memcpy_P), which are in 2 variants: compact and speed.
> > > This acceleration is very effective: a few of progmem
> > > words give 10..30% speed increase. I plan to expand this
> > > function list slightly.
> > >
> > > Avr-libc compiles a speed variant for avr3 family only.
> > > What about to add avr5? Is there any objections?
> > Hi Dmitry,
> >
> > This brings up the overall issue of what should the goal be for avr-libc?
> > Speed, or size?

Speed is, IMHO, often an important aspect in embedded programming. 
Faster code means lower clock frequencies for the same job, leading to 
lower emissions and lower power.  It can also mean more options 
regarding the hardware (such as less stringent voltage restrictions). 
Alternatively, it means the processor spends more time asleep, and 
therefore use less power.  All in all, faster code is good.

> > I still lean towards *size* as the number 1 priority for all code, for all
> > architectures and devices. When AVR compilers are compared, they are always
> > compared on code size, not code speed.

Size is the main priority when you are low on flash space - otherwise, 
it is irrelevant.  If your chosen AVR has 16k flash, then it does not 
matter if the program code takes 2k or 15.9k of that flash.  In 
particular, for smaller devices, program space will be at a premium, 
while for the larger devices, much of the flash will often be things 
like tables or other data that is of fixed size.

There are only two things I have ever compared AVR compilers on - 
features (where gcc wins), and "quality" of the generated code, which is 
at least as much to do with speed as size.  I can't see any reason to 
generate poorer code just to look better on someone else's comparison 
benchmarks, just because it is easier for them to give a code size than 
do a proper comparison.

> OK, I shall not change any compilation options.
> Though a discrepancy remains between avr3 and avr5.
>
> Nevertheless, I shall a little expand the list of functions
> where this option is present. Certainly, it can affect a code
> only in case of compulsory inclusion of this option. I shall
> repeat, that it is a question only of small quantity of functions
> which it is often enough used and where such optimization is
> effective enough. For example (not commited now):
>    memset:          3.5 vs 6 clock/byte, cost= 4 words
>    memcpy,memmove:  5.5 vs 8 clock/byte, cost= 5 words
>    memcmp:          7.5 vs 10 clock/byte, cost= 6 words
>    strlen:          4 vs 5 clock/byte, cost= 2 words

Personally, I'd choose speed over size in all of these cases - the gains 
are high and the costs low.

> I would not be so categorical in an estimation of a priority
> of the size. Eventually, speed is important from the very
> beginning of the project, and the size starts to interest only
> after overflow of memory.

For what it's worth, I agree with you fully, Dmitry.

mvh.,

David


> Dmitry.
>
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev