problems with optimisation

[David Brown]

On 29/12/12 23:26, Ángel González wrote:
> On 29/12/12 17:26, David Brown wrote:
>> With -Os, the compiler will obey normal "inline" directives (at least,
>> that is my experience when compiling C on the avr - I have not tried
>> C++ much on it).  It won't do any automatic extra inlining, except for
>> static functions that are only used once - which are always inlined as
>> this saves space.  Again, I don't know how that plays with template
>> functions or other C++ features.
>>
>> As far as I know, gcc uses weighting heuristics to decide whether to
>> do something the rcall you mentioned above, compared to using the
>> inlined code directly.  It is certainly not impossible that the
>> weightings are not optimal here.
>>
>> There is currently very little use of C++ with avr-gcc.  The avr port
>> maintainers and the avrlibc developers have little experience with
>> C++, and feel they have enough to do with just the C support.  But
>> there are a few people on the avr-gcc mailing list that work with C++,
>> and it is certainly worth posting there too - they may be able to give
>> suggestions.
>>
>> <https://lists.nongnu.org/mailman/listinfo/avr-gcc-list>
>>
>> mvh.,
>>
>> David
>
> I got good results (code apparently better) using -O3 in avr instead of
> -Os. Just the skipped instructions in the prologue and epiloques may be
> worth it. It may that since on avr you have one cycle per instruction
> (except branches), when optimizing for speed, you indirectly also
> optimize the number of instructions. However, I was using C, not C++, so
> the different way of coding could lead to worse optimizations.

It is not always easy to guess the best choice of optimisation flags. 
You are right that on the avr, small often means fast - and 
optimisations that first appear to make code larger (such as inlining 
functions that are used more than once, or loop unrolling) can lead to 
smaller code by avoiding prologues/epilogues, function call overheads, 
and other "bookkeeping" code.  Theoretically, the compiler knows this 
and will pick the smaller code with -Os.  In practice, it is a very hard 
problem, and there is a limit to the complexity (and accuracy) that can 
be achieved here.

On the bright side, gcc seems to be getting steadily smarter about these 
things - gcc 4.7 does partial function inlining and function 
specialisation in some cases.

Personally, I would like to see the distinction between "optimise for 
speed" and "optimise for size" disappear - or at least be reduced to a 
specialised flag (meaning "I /really/ don't care about speed - just make 
the code as small as possible", and vice-versa).  There are several 
reasons for this:

On modern "big" cpus, small means fast because small fits the fastest 
cache levels (including branch target buffers, prefetch buffers, etc.) 
best.  On an old 386 cpu it might make sense to unroll a loop - on an i7 
the fastest code will have the loop intact (unless unrolling gives 
additional optimisations).  And now the 386 will be deprecated...

On small cpus (like the avr), fast means small because fast means 
running fewer instructions.

In cases where it makes sense to bias on the side of size or speed, 
programmers are notoriously bad at making such decisions themselves. 
Hands up all developers who always profile their code before deciding 
which bits need optimisations :-)  The compiler, on the other hand, can 
do a reasonable job in many cases (see the -fipa-profile flag for an 
example).


On big cpus, the normal optimisation choice should be "make this code as 
fast as possible on this processor, maintaining all standards".  Other 
sensible options are "as fast as possible disregarding the fine print of 
IEEE standards" (the "-Ofast" flag), and "as fast as possible but still 
easy to debug" (the "-Og" flag).

On small cpus, the ideal flag would be something like "as fast as 
possible, but fitting within 32K code memory" - but I don't see that 
coming in the next version or two of gcc...



> I recommend giving gcc as much information as possible, and watch the
> generated code. I got gcc to perform a few tricky optimizations, and in
> one case, I manually unrolled a loop for him (otherwise, it didn't
> notice it could be optimized). If you see a very bad instance of code
> generation, open a bug. :)
> What difference do you have from -Os to -O3 ?
>

The more information the compiler gets, the better.  In particular, you 
always get better results if you can make your functions (and data) 
static - if the compiler can see that the functions don't escape (by 
taking their addresses), it can do far more optimisations.

mvh.,

David