Performance Tips in C/C++
Author
Hi, does somebody has a link where i can find tips to improve the performance in my app?.
Or do you know some "tricks"??
Well, one thing I discovered the other day at work was that if you're going to square something, DON'T use the pow() function in the C standard math library. Multiplying the two numbers together nearly doubled the speed of my program (which did a lot of distance calculations). But unfortunately I don't know of any good online documentation for tips. I'd be interested to read some though. [smile]
The most important thing is to make your algorithms more efficient, not code tricks that might save a few cycles. "Can I rewrite to avoid that third inner loop?" is a better thing to think about than "should I compare the square of distances instead of the actual distance to avoid taking the square root?"
Profile.
Profile.
Also don't use the standard c sqrt function, it's as slow as pow. uses some slow ass lookup table.
it's best to multiply the 2 numbers together, and check against the non sqrted value for distance checks.
Example of worst distance check ever (IN a game, it will cause a rather decent performance drop, depending how many times in a frame you call it)
sqrt and pow = not good for games.
One last example, In your code you might say if
ship.distance(getdisSQRT(ship)) < 500
do blah;
you can do the same thing, but use
ship.distance(getdisNOSQRT(ship)) < 250000 (this is faster, less cpu calcs, does exact same thing)
if you think about it, sqrt is completly useless in a distance check, you don't need it at all.
it's best to multiply the 2 numbers together, and check against the non sqrted value for distance checks.
Example of worst distance check ever (IN a game, it will cause a rather decent performance drop, depending how many times in a frame you call it)
Distance=(float)sqrt(((float)pow((x1-x2),2))+((float)pow((y1-y2),2)));sqrt and pow = not good for games.
One last example, In your code you might say if
ship.distance(getdisSQRT(ship)) < 500
do blah;
you can do the same thing, but use
ship.distance(getdisNOSQRT(ship)) < 250000 (this is faster, less cpu calcs, does exact same thing)
if you think about it, sqrt is completly useless in a distance check, you don't need it at all.
There is a book I read called "Efficient C++" It is more for the advanced reader, but I high recommend it for this. It has almost all the tips and tricks to speed just about every part of your program up. Especially on the low level.
Quote:Original post by Foxostro
The most important thing is to make your algorithms more efficient, not code tricks that might save a few cycles. "Can I rewrite to avoid that third inner loop?" is a better thing to think about than "should I compare the square of distances instead of the actual distance to avoid taking the square root?"
Profile.
Agreed completely. The good programmers aren't the ones with lots of tricks up their sleeves for low-level optimization; they're the ones who understand how to structure their code and how to figure out the most efficient way to accomplish a task. (And how to use a profiler.)
Before you start doing low-level tricks like mentioned above, you need to make your program and then profile it. The profiler will tell you which parts of your program are using the most time so you know which parts to modify.
DevPartner Profiler Community Edition is a decent free profiler.
DevPartner Profiler Community Edition is a decent free profiler.
Unfortunately, you can't use the distance-squared trick for distance comparison in some graph algorithms. For example, if you compare the square of distances in Dijkstra's algorithm, then you may find a shortest path that well, isn't the shortest path. This is because you may find two legs of a right triangle to be equal to the hypotenuse, and so you would travel both legs rather than just the hypotenuse.
A profiler is your best friend (I use CodeAnalyst by AMD, available for free on Linux and Windows). I would back up the other things Foxostro said also. If your 'optimization' trick isn't based on real knowledge of computers, it's probably just slower (you should see some of the crap 'optimizations' that get slung around these forums sometimes!)
That said, in order to write fast code you need to design it fast. In order to do that, unfortunately, you need to understand how computer hardware works, and there's no short-cut for that. You'd be interested to know that the biggest slow-downs are cache misses, so you need to understand caches. This also means avoiding many levels of indirection, and instead storing together data that will be accessed together frequently.
In general, use a profiler as your bible, however realize that you should be able to accurately predict the results! Otherwise you haven't considered your choices carefully enough. Like Foxostro said, remove that third inner loop is good, but you should never have made it in the first place! Understand when you are moving into a performance-important part of code and when not....
For instance, your camera code might have some pretty crazy math to make it look nice, but there's no need to futz with trying to optimize that, total waste of time. Likely the most expensive camera routine will be doing line-of-sight tests, which are probably shared by Player, NPCs, missiles, etc, so Line-of-Sight you definitely should be planning on making really fast before you ever start writing!
I'm sorry that this is somewhat nebulous advice, not something like a 'trick', but more a philosophy. And to implement it you need a lot of trial and error and studying and working... no short-cuts sorry.
That said, in order to write fast code you need to design it fast. In order to do that, unfortunately, you need to understand how computer hardware works, and there's no short-cut for that. You'd be interested to know that the biggest slow-downs are cache misses, so you need to understand caches. This also means avoiding many levels of indirection, and instead storing together data that will be accessed together frequently.
In general, use a profiler as your bible, however realize that you should be able to accurately predict the results! Otherwise you haven't considered your choices carefully enough. Like Foxostro said, remove that third inner loop is good, but you should never have made it in the first place! Understand when you are moving into a performance-important part of code and when not....
For instance, your camera code might have some pretty crazy math to make it look nice, but there's no need to futz with trying to optimize that, total waste of time. Likely the most expensive camera routine will be doing line-of-sight tests, which are probably shared by Player, NPCs, missiles, etc, so Line-of-Sight you definitely should be planning on making really fast before you ever start writing!
I'm sorry that this is somewhat nebulous advice, not something like a 'trick', but more a philosophy. And to implement it you need a lot of trial and error and studying and working... no short-cuts sorry.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
