low level optimization

[Dario Bressanini]

>>   Consider for a moment (yes, these are not equivalent):
>>
>>           x = ++c;       vs       x == c++;
>> These can be "compiled" as:
>>
>>                                   temp_001 <-- c;
>>           c <-- c + 1;            c <-- c + 1;
>>           x <-- c;                x <-- temp_001;
>>
>> (now throw away the "x=" part (last "instruction").
>>
>>So, "++c" is ``cleaner'' in some pedantic sense[1], and I suppose a
>>sufficiently lacking compiler might actually produce slower code
>>for "c++;" than for "++c;".                  ^^^^^^^^^^^^^^^^^^^^

I always read this group with interest, i have learned a lot following
many discussions, but sometimes the "war"  "This statement is faster
than the other" comes up, like in this case. I don't want to discuss
this particular case, but to make some general personal observations.
Based on my experience, I hardly believe that  in a "real world code"
one can improve the performances of a program using this kind
of "optimization".
When i REALLY HAVE to optimize a program, first of all i use 
a profiler to see where is the bottleneck, and THEN i try to optimize it;
probably I am biased since i mostly write programs (90% in FORTRAN)
for scientific computation (yes, I use floating points :-) ) where usually
you have a single routine, or even a single loop, that takes 95% of 
the CPU time.
In most cases the best way to gain speed was to change completely
the algorithm, and not to make some very low level optimization.
Following the latest "this is faster than that" wars I had 
the impression that they were pure void theoric discussions, without any
connection with the "real world", at least to my world.

Just in case.... I don't want to start the usual and useless war
C vs FORTRAN etc..,i would like to use C for my programs, but in most
cases i tried, the Code produced by the C compiler was 2 or 3 times
slower that the fortran code.

      dario bressanini