Archived

This topic is now archived and is closed to further replies.

DevLiquidKnight

Fine tuning C++ code?

Recommended Posts

I was wondering if anyone knows of a site that talks about some various techinques to fine tune your code, so that it is faster.. ect.. Anything about this area... would be great. If anyone has any links id like to read C++ code in particular [edited by - DevLiquidKnight on April 6, 2004 2:56:12 AM]

Share this post


Link to post
Share on other sites
step 1: run profiler
step 2: notice which functions take the most time
step 3: optimize
do this until your program is fast enough

Share this post


Link to post
Share on other sites
Here are some more tips:
If you expect functions to be inlined, you probably(depending on your compiler) need to have them defined in a header file.
Pass large classes by const&
Make sure you turned on optimizations in your compiler
Be aware of cache issues - for instance, don't iterate multi-dimensional arrays in the wrong order
Don't worry about psuedo-optimizations like >> instead of /
Use the appropriate algorithms for the job
Understand that while most algorithms consist of time/memory tradeoffs, on modern processors memory is often more precious than time(due to the huge penalties of cache misses)
Prefer stack allocation(or inline allocation in a heap-allocated class) to dynamic allocation, if possible.
Understand where your cpu time is going.
Check your allocations - make sure you know what's getting allocated when, and make sure that you're expecting it.
Understand that certain simple looking constructs(assigning a vector, or returning one from a function, for instance) can hide a deeper cost(eg, invoking the copy constructor for a very large object).

The first step of perf is measuring. If you don't measure, you're just wasting your time - it's as simple as that.

Second, budget your perf. Have a target in mind, and stop when you reach it. You're trying to make a game, and you need to make an engineering decision as to when perf is good enough.

[edited by - sjelkjd on April 6, 2004 5:37:50 AM]

Share this post


Link to post
Share on other sites
Learn inline assembly.

Its easy to interface assembly instructions into you C++
source code and for mathematically intensive functions, could
gain you increases in speeds from around 150% to 1000%+ or
more!!!

But then again, you REALLY have to know what you''re doing in
asm (assembly) in order to beat the C++ compiler.

BTW its not really neccessary to fine tune ALL your code. I''d
only fine tune code which is time critical. Sure, code wisely
and efficently, but if it ain''t time critical, don''t lose
sleep over it.

Programming these days is hard enough without having to worry
about EVERY single line of code you write!!!

A decent book to get you started on asm, is ''Assembley Language
Step - By - Step'' by Jeff Duntemann. It really digs deep into
how your PC works on a fundamental level, and explains the ins
and outs of the assembly language itself.

However, its not targeted towards inline asm, which is what you
want, but at least its a start.

I''ve yet to find a decent book on inline asm I''m afraid...

K...Hope this helps!!!

Share this post


Link to post
Share on other sites
I''d add something else, gleaned from years of experience: Optimize at as high a level as you can. A single high-level optimization can eliminate 50% or more of the operations your program has to do, at one fell swoop. Compare that to something that saves one or two cycles per 500-cycle loop, and you''ll see what I''m getting at.

Share this post


Link to post
Share on other sites
quote:

step 1: run profiler
step 2: notice which functions take the most time
step 3: optimize
do this until your program is fast enough



I''d make this a while instead of a do loop:

while (program is too slow) {
step 1;
step 2;
step 3;
}

Share this post


Link to post
Share on other sites
I''ll tell you what...

If you REALLY wanna go nuts on optimization techniques, get
Intel''s docs on low-level optimization.

The Intel manual is called:

IA-32 Intel Architecture Optimization

It''s about 600 A4 pages long.... but FREE!!!

Go to Intel''s Developer''s Website at:

http://developer.intel.com/design/pentium4/manuals/index2.htm

They also have various other manuals on offer... And you can
either download them or order them via post... Absolutely FREE!!

And considering that these guys ARE the chip makers, you won''t
get better advice anywhere else!!!

So... go knock yourself out with some untapped Intel power!!!

Peace!!!

Share this post


Link to post
Share on other sites
1. Declare variables in as low a scope as possible, no higher.
2. Declare variables only just before you need them.



blah blah blah.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
This is just typical thread started by DevLiquidKnight... He claims that he knows about 20 different programming languages, including x86 assembly. I think that person who knows 20 languages, knows how to write efficient C++ code.

Oh, and he rarely replies to threads, he has started (Makes me wonder, if he even reads the replies.)

Share this post


Link to post
Share on other sites
quote:
Original post by petewood
fractoid''s is some of the most important advice. Learn it well.

Rules of Optimization:
Rule 1: Don''t do it.
Rule 2 (for experts only): Don''t do it yet.
- M.A. Jackson




It''s because of idiots like that that Microsoft fails to include a profiler in there newest C++ compiler. They don''t want you to find out how poor there C++ compiler really is.

You want my advice? Think of C++ as a meta-C compiler. Use as little C++ as you can and use C as much as possible. C compilers rock. Keep things simple. Most C++ compilers are poor and the brainwashing to use ever more complex patterns is to sell ever faster hardware and new software. Don''t believe the hype. You really should not need more than an Athlon 1ghz machine, you can make them sing and dance if you use your head and understand when to avoid complexity for simpler solutions.

I use C++ and enjoy it, but I am not decieved by these charlatans who push all these complex design patterns down the throats of naive college students. But it has one good thing, it keeps the economy going, except that if there are no jobs nobody has money to buy anything...

You can believe whatever you want to believe I don''t care.

Share this post


Link to post
Share on other sites
quote:
Original post by PeterTarkus
You can believe whatever you want to believe I don''t care.


why are you ranting then?

Share this post


Link to post
Share on other sites
quote:
Original post by JD
inline code and reduce memory accesses


Bad advice. Too much inline can cause bloat and slow down your process. A better advice would be to know when to inline, ie. inline constructors and destructors are usually a bad idea.

[Edit] PeterTarkus, you're a tool. You make totally unsubstantiated claims with arguments pulled out of your ass. Shut up man.



[edited by - fallenang3l on April 7, 2004 10:52:59 AM]

Share this post


Link to post
Share on other sites
Inlining can cause bloated code but more importantly, the inline keyword is more like a hint to the optimizer than a command. If the function is to complicated, i.e. it refers to itself ( recurrsion ), or it calls other functions, then the compiler ( not all compilers ) will just ignore the suggestion. And you can't inline a virtual function cause the decision to call a virtual function is made at run time and inlining occurs at compile time.

Computers can execute billions of lines of code per second. Some things that slow them down are loops and function calls. All that shifting around of the instruction pointers. You can unroll a loop, i.e. do more than one thing during each iteration of a loop. Like, instead of drawing a single vertex each iteration, draw two.

One last tip, 99% of the time, its only 1% of your code that is not optimized.

Edited: One more thing. Use the pre-increment operator instead of the post-increment operator because in the pre-increment operator it increments the value and then returns the incremented value. In the post-increment operator it copies the current value ( making a call to the copy constructor ) then increments the current value and returns the copy. Using the pre-increment saves you a function call to the copy constructor. Summary: Use ++i, not i++

[edited by - tolleyc on April 7, 2004 12:38:24 PM]

[edited by - tolleyc on April 7, 2004 1:26:36 PM]

Share this post


Link to post
Share on other sites
One practical tip, things like:
for (int i = 0; i < strlen(mystring); i++) { /* loop body */ }   
can possibly lead to recomputation of the length of your string every time through the loop. Of course you want this if your string changes size, and do not want it if your string does not change size. Sometimes compilers are able to pick up on things like this, but usually it is a very hard determination to make.

Consider the contrived example:
char mystring[] = "abcdefg";
char *p = mystring[4];
for (int i = 0; i < strlen(mystring); i++)
{
someglobal++;
if (somecondition)
*p = 0; /* This is actually undefined behavior in C, for pedants. */
}


The length of the string changes but the compiler would not be able to tell this without doing a significant amount of checking. Most compilers prefer the correct method, which is to evaluate the strlen every time through the loop.

If your string doesn't change, something like this can save repeated computation:
for (int i = 0, end = strlen(mystring); i < end; i++) { /* loop body */ }   


This is just a practical tip that you can use in everyday code. It's not a silver bullet and it won't get you 7000 extra frames per second, it's just smart coding.

[edited by - bobstevens on April 7, 2004 12:56:32 PM]

[edited by - bobstevens on April 7, 2004 1:14:56 PM]

Share this post


Link to post
Share on other sites
So Peter, what are your sources of information? I''m sure you have a vast array of publications that detail your findings. Or at least you speak like you do.

Share this post


Link to post
Share on other sites
While at GDC last month, I went to a talk on optimizing C++ given by a person from Microsoft that evaluates the XBox games. The #1 thing was to run a profiler. That was it. He was amazed how many games he reviewed that didn''t use one. He got a MINIMUM 25% increase in frame rate on all games evaulated. Mainly from running the game through a profiler.

As for why Microsoft doesn''t supply one, that''s anyones guess.


- onebeer

Share this post


Link to post
Share on other sites
Hi!

quote:
Original post by tolleyc
Summary: Use ++i, not i++



No offense, but I really wonder if you'd notice any difference in speed in any test you can think of (talking about this ++i instead of i++). Optimizations like this one is not something any serious programmer would do. Note that you usually do something hundreds (if not more) times more expensive inside the "for" branches.
I can't think of any serious code sample where such optimization would be noticeable. Tell me if I'm missing something important.

I would divide optimizations that make sense into 2 kinds:

1. Algorithm related.

Much more important in most of the applications nowadays.
Exceptions here are "only": real-time applications and drivers, otherwise optimizing down to stuff like "make 2 tricky assignments instead of 4" doesn't usually make any sense but makes your application much more difficult to understand for the others and makes it more buggy.
A well designed and clever algorithm will speed up you application much more than poor but dangerous tricks you can do with C/C++.

A well known rule for software developers is KISS which stands for "Keep It Stupid Simple", which - a bit exagerating - expresses best what I'm talking about.

2. Coding tricks.

These are the things that are exceptions from above - mostly computer games, real-time simulators etc.
You should keep in mind however not to optimize everything, but just the critical pieces of your code like (just few examples):
- copying some large arrays of vertices
- interpolating thousands of vertices of your models in real-time
- precomputing some computationally expensive values

[edited by - MickeyMouse on April 7, 2004 4:43:44 PM]

Share this post


Link to post
Share on other sites