Re: Habitual optimization
dhruv wrote:
Steven T. Hatton wrote:
I have long wondered about certain programming styles/strategies and how
they can impact performance.
[snip]....
const int dTick((rect.width() - 1)/settings.numXTicks);
and then writing:
int x = rect.left() + i * dTick;?
Or even `int x(rect.left());' outside the loop, and `x+=dTick'; inside the
loop?
Yes, definitely there is a gain to use the additive operation inside of
the loop.
That's what a na?ve person might think.
Two in fact:
[1] You are executing an add operation instead of a multiply every
time, which is less time consuming.
On some machines. On most modern machines, I don't think that
there's any difference. On some machines, certain combinations
of operations are faster---I've seen machines which could
optimize a*x+b much better than a simple multiplication or
addition.
[2] You are touching lesser number of variables.
Except that a good optimizer will have put them in registers, so
that it doesn't matter.
Typically, on an x86 machine, the former would be:
(a) Load dTick into a temporary.
(b) Multiply i and dTick.
(c) Store the result of rect.left() in a temporary.
(d) Add the result of the above 2 temporaries.
However, the latter would be:
(a) Store the result of rect.left() in a temporary.
(b) Add the above temporary and the value of dTick.
Both sequences are signs of a pretty bad compiler. If values
are being cumulated during a loop, the compiler should be
storing them in a register. And compilers are very good at
strenght reduction (replacing multiplication with addition when
it does make a difference) and loop invariant motion---these
have been standard optimizations for over twenty years.
[snip]....
One additional question I have deals with for-loops.
std::vector<Object> v;
// fill the vector
for(unsigned i(0); i<v.size(); ++i){
//do something.
}
Is it likely that an optimizer could improve performance if it could
determine that v.size() is unchanged during the loop, and thus eliminate
calls to v.size()?
Yes, definitely it would result in a performance gain.
The C++ standard specifies that the size() member function should be
constant time. It may be implemented as a difference of 2 pointers,
which boils down to difference followed by a divide with the type's
size. If these 2 operations can be eliminated(which btw involve an AGI)
then there's nothing better for speed!!!!
And a good optimizer can do it. Why should the programmer worry
about such things?
And of course, most of the time, even if the optimizer doesn't
do it, the program will still be fast enough. Wasting time
optimizing what doesn't have to be optimized is pretty
unprofessional, when it comes down to it.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]