Thanks & Regards,
Sadanand
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Stop worrying about it. The chance that you can write code in such a way
that a compiler will optimise it better is too small to concern
yourself. Just write good readable code. Now if the performance is
inadequate profile it to find the bottlenecks and then address those. In
fact most of the time it is a matter of finding a better algorithm.
Modern compilers can do quite extraordinary things when they optimise a
program (and that depends on whether you want a small program or a fast
one.)
{ edits: quoted sig and banner removed. please don't quote the banner. -mod }
You'd probably be better off searching for this sort of thing on
google. For example from 'C++ optimisation', the first result is
http://www.tantalon.com/pete/cppopt/main.htm seems to be roughly what
you're looking for. It also depends on which compiler you use as to
how your code is optimised exactly...
> You'd probably be better off searching for this sort of thing on
> google. For example from 'C++ optimisation', the first result is http://www.tantalon.com/pete/cppopt/main.htm seems to be roughly what
> you're looking for.
This particular website looks more a list of bad ideas (two-phase
initialization, limit exception handling, disable RTTI) than
optimization techniques though.
So I think people are not better off searching stuff on Google instead
of asking in a group where quite a few experts go.
It starts by saying that the results are valid for VC++ 6.0 running
Windows 95 on a Pentium II.
If you happen to have another configuration :-), you may have to run
the tests again to get the results for your platform. They would
probably be quite different.
Bo Persson
Hi, take a look at http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf
>From Abstract: (citation)
"People often write less readable code because they think it will
produce faster code. Unfortunately, in most cases, the code will not
be
faster."
However, there are still things you can do to
improve performance that don't amount to inventing
a new algorithm.
Mostly, they involve simplifying
the code or not using features if you don't really
need them. If there's a fancy, complicated way
and a simpler way to do the same thing, prefer the
simpler way unless you can justify using the fancier
way. Some things I look for:
1. Avoid new and delete. If you can make an object
a local (stack) variable or a member variable
without making the code more complicated, do it.
Believe it or not, I've seen stuff like
{
T *tp = new T;
// code that uses *tp
...
delete tp;
}
And stuff like
class T {
T2 *tp;
...
T() : tp( new T), ... {}
~T() { delete tp; ... }
...
};
is pretty common when
class T {
T2 t2;
...
};
would be perfectly good.
In my experience, new and delete (or malloc and free)
are expensive, often expensive enough that memory
pools are worth the trouble. A fortiori, if
new/delete can be replaced with nothing at all,
it's even better.
2. Avoid pointers. Use them if necessary, but
keep in mind that pointers (and references)
introduce aliasing issues. This makes
debugging and (compiler) optimization harder.
Keep in mind, for built-in types, copying is
faster than using a reference. Probably also
true for some classes.
Anybody have other suggestions?
Yes:
1. Rule of thumb: less code executed == faster code.
2. Use a profiler.
3. Have a look at the assembler output of your compiler for the hot spots.
My experience is if you're not willing to do (2) and (3), all the
internet optimization advice will not help your code get faster.
===========================================
Walter Bright
Digital Mars
http://www.digitalmars.com
Free C, C++, Javascript, D programming language compilers
I'd add, be aware of what operations cost, and especially the effect of
the cache architecture. It's worth viewing the talk by Herb Sutter at:
http://www.nwcpp.org/Meetings/2007/09.html
He claims, for example, memory access times:
L1 cache (32KB): 3 cycles
L2 cache (4MB): 14 cycles
DRAM (2GB): 200 cycles
So memory that's not in cache can take 66 times longer to access than
memory that is. How you organise your data may swamp any
micro-optimisations the compiler may make. Eg a vector may be much faster
than a linked list because it is more cache-friendly. These effects may
not be obvious from looking at assembler output, or the nominal amount of
code being executed.
-- Dave Harris, Nottingham, UK.
On that note, Ulrich Drepper has an excellent article, "What Every
Programmer Should Know About Memory". A quick google brings it up
here:
http://people.redhat.com/drepper/cpumemory.pdf
-tom