Hi, I've found quite a nice site about optimization of code. I have not read it all yet, but so far it looks good.
http://www.azillionmonkeys.com/qed/optimize.html
Code Optimization
Code Optimization
irrRenderer 1.0
Height2Normal v. 2.1 - convert height maps to normal maps
Step back! I have a void pointer, and I'm not afraid to use it!
Height2Normal v. 2.1 - convert height maps to normal maps
Step back! I have a void pointer, and I'm not afraid to use it!
It's an interesting article, but I don't know how valid it is. Some of it seems like unnecessary obfuscation that might not even produce the intended results. Other things like switching x * 8 to x << 3, are done automatically by any compiler worth its salt (every modern compiler I can think of knows to automatically make multiplication with powers of two bit shift ops automatically). "Optimizing" code for certain hardware also seems silly to me too - hardware changes, and it changes fast. What's true today probably won't be true a year from now, and it seems to me like you'd be wasting a lot of time doing these "optimizations" instead of focusing on what your code is supposed to be doing. Well written and thought out code will always outperform poorly written code that's "optimized" the way this article describes. In short, let the optimizing compiler do the optimization and focus on making your code good.
-
- Posts: 1186
- Joined: Fri Dec 29, 2006 12:04 am
Thinking in C++, 2nd ed. Volume 1, Programming Guidelines
1. First make it work, then make it fast. This is true even if you are certain that a piece of code is really important and that it will be a principal bottleneck in your system. Don’t do it. Get the system going first with as simple a design as possible. Then if it isn’t going fast enough, profile it. You’ll almost always discover that “your” bottleneck isn’t the problem. Save your time for the really important stuff.
35. Don’t fall prey to premature optimization. That way lies madness. In particular, don’t worry about writing (or avoiding) inline functions, making some functions nonvirtual, or tweaking code to be efficient when you are first constructing the system. Your primary goal should be to prove the design, unless the design requires a certain efficiency.
1. First make it work, then make it fast. This is true even if you are certain that a piece of code is really important and that it will be a principal bottleneck in your system. Don’t do it. Get the system going first with as simple a design as possible. Then if it isn’t going fast enough, profile it. You’ll almost always discover that “your” bottleneck isn’t the problem. Save your time for the really important stuff.
35. Don’t fall prey to premature optimization. That way lies madness. In particular, don’t worry about writing (or avoiding) inline functions, making some functions nonvirtual, or tweaking code to be efficient when you are first constructing the system. Your primary goal should be to prove the design, unless the design requires a certain efficiency.
"Whoops..."
Agreed, but not.randomMesh wrote:1. First make it work, then make it fast.
Balance is important-- not just in programming but in life, too...
Making things "work" without making them reasonably fast will lead to a horrible mess; making things insanely fast before making them work will lead to nothing.
I know several computer engineers and a professional game developer, and every time I talk to them about optimization, they say that it's best to let the compiler do the simple optimizations (such as knowing whether to bit shift or multiply or divide) and focus on optimizing your program at a higher level. For example, no matter what compiler you use, heapsort will (almost always) outperform bubblesort. Work on the higher-level structure of your code and let the optimizing compiler deal with the details.