Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Code Optimization

2 views
Skip to first unread message

Sadanand

unread,
Dec 18, 2009, 7:34:58 PM12/18/09
to
hi all,
Can anybody please let me know how compiler optimize a C++ code? can
you give me a simple example? which will help me to write more
optimized code in all my working projects.

Thanks & Regards,
Sadanand

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

unread,
Dec 19, 2009, 9:44:18 AM12/19/09
to
Sadanand wrote:
> hi all,
> Can anybody please let me know how compiler optimize a C++ code? can
> you give me a simple example? which will help me to write more
> optimized code in all my working projects.


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.)

ramblex

unread,
Dec 19, 2009, 9:45:13 AM12/19/09
to
On Dec 19, 12:34 am, Sadanand <steggi...@gmail.com> wrote:
> hi all,
> Can anybody please let me know how compiler optimize a C++ code? can
> you give me a simple example? which will help me to write more
> optimized code in all my working projects.

{ 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...

Mathias Gaunard

unread,
Dec 20, 2009, 3:05:58 AM12/20/09
to
On 19 d�c, 14:45, ramblex <alexdul...@googlemail.com> wrote:

> 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.

Bo Persson

unread,
Dec 20, 2009, 9:47:19 AM12/20/09
to
Mathias Gaunard wrote:
> On 19 d�c, 14:45, ramblex <alexdul...@googlemail.com> wrote:
>
>> 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.
>

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

Bartosz Wiklak

unread,
Dec 21, 2009, 9:59:55 AM12/21/09
to
On 20 Gru, 15:47, "Bo Persson" <b...@gmb.dk> wrote:
> Mathias Gaunard wrote:
> > On 19 d�c, 14:45, ramblex <alexdul...@googlemail.com> wrote:
>
> >> 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.htmseems 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.
>
> 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."

A. McKenney

unread,
Dec 24, 2009, 3:58:08 AM12/24/09
to
On Dec 19, 9:44 am, Francis Glassborow

<francis.glassbo...@btinternet.com> wrote:
> Sadanand wrote:
> > hi all,
> > Can anybody please let me know how compiler optimize a C++ code? can
> > you give me a simple example? which will help me to write more
> > optimized code in all my working projects.
>
> 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.)

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?

Walter Bright

unread,
Dec 31, 2009, 2:06:33 PM12/31/09
to
A. McKenney wrote:
> 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

Dave Harris

unread,
Jan 1, 2010, 10:58:58 AM1/1/10
to
newsh...@digitalmars.com (Walter Bright) wrote (abridged):

> 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.

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.

t...@shigeru.sci.utah.edu

unread,
Jan 4, 2010, 9:31:52 PM1/4/10
to
Dave Harris <bran...@cix.co.uk> wrote:
> 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

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

0 new messages