Re: Assuming optimization? What is best of these code alternatives?

[Per Sandberg <per.s.sandberg@bahnhof.se>]

Well
It all depends on Compiler and target architecture so i would recommend 
the following actions i order.
1 Read the compilers manual on optimization flags.
2 Get yourself a decent analyzer.
3 If you are running gnat compile your program with "-O2"
4 Measure.
5 Analyze the results they are usually surprising.
5 Do code changes.
6 Back to 3

So the usual approach is
1) Write the program as readeble and understandable as possible.
2) Analyze the execution behavior on the real target with real data,
3) Optimize after deep analysis and reflection.

The measurement tools usually points to parts of the code and constructs 
that are complete opposite of what you expected.

/Good quotes J-P
/Per


On 11.09.2014 15:34, J-P. Rosen wrote:
> Le 11/09/2014 15:14, reinkor a écrit :
>> I am not sure to what extent one may assume the Ada compiler
>> makes optimization.
> It does. An Ada compiler without optimization would not be usable.
> (and I worked on Ada/ED !)
>
>> For example, assume the following two program
>> code alternatives:
>>
>>
>> -----------------------Alternative 1:
>>     i1,i2,k : Integer;
>> begin
>>      (Read i1,i2 and n - do not change after)
>>
>>      k := i1 + i2; -- store "i1 + i2" in k to avoid recalculation (?)
>>      loop
>>        for i in k .. n loop
>>            Do something...
>>        end loop;
>>      end loop;
>>
>> ------------------------Alternative 2:
>>     i1,i2 : Integer;
>> begin
>>      (Read i1, i2 and n - do not change after)
>>
>>      loop
>>        for i in i1 + i2 .. n loop -- will recalculate "i1 + i2" ?
>>            Do something...
>>        end loop;
>>      end loop;
>>
>> What is the "best" alternative?  Alternative 2
>> is shortest (and probably easier to read), but
>> could it give slower code that for Alternative 1 ?
>>
> Response 1: don't bother with such micro-optimization
> Response 2: the language requires that the bounds be evaluated only
> once, not on each loop. Therefore, it won't make any difference.
>
> FWIW, here is my favorite collection of quotes about optimization:
>
> Kernighan & Plauger, 1974.  Elements of Programming Style:
> - Make it right before you make it faster.
> - Keep it right when you make it faster.
> - Make it clear before you make it faster.
> - Don't sacrifice clarity for small gains in "efficiency."
> - Let your compiler do the simple optimizations.
> - Keep it simple to make it faster.
> - Don't diddle code to make it faster - find a better algorithm.
> - Instrument your programs.  Measure before making "efficiency" changes.
>
> Ledgard, Nagin, Hueras, 1979. Pascal with Style: Programming Proverbs:
> Shortening the code, running the program faster, or using fewer
> variables are all popular pastimes. Not mentioning ... the extra testing
> time needed to check the new and often subtle boundary conditions, are
> you sure that fewer machine instructions or faster machine execution is
> likely?
>
> M.A. Jackson
> Rules of Optimization:
> - Rule 1: Don't do it.
> - Rule 2 (for experts only): Don't do it yet.
>
> W.A. Wulf
> "More computing sins are committed in the name of efficiency (without
> necessarily achieving it) than for any other single reason - including
> blind stupidity."
>
> Donald Knuth
> "We should forget about small efficiencies, say about 97% of the time:
> premature optimization is the root of all evil."
>