Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Optimisation
henryj
Unregistered

 
Post: #1
Optimisation
Here is a good link about optimisation, a popular topic on idev...

[url=http://c2.com/cgi/wiki?FirstRuleOfOptimization
]http://c2.com/cgi/wiki?FirstRuleOfOptimization
[/url]

I was going to put it in the faq but couldn't find a good place.
2003.10.22 12:57 AM
Quote this message in a reply
inio
Unregistered

 
Post: #2
Optimisation
Something funky with that link. Should be:

http://c2.com/cgi/wiki?FirstRuleOfOptimization
2003.10.22 01:49 AM
Quote this message in a reply
Programmer
Unregistered

 
Post: #3
Optimisation
The first rule is complete crap. Of course you should optimize your code. If you don't pay attention to performance then how do you become an "expert"? And the notion that only experts can do this is nonsense.

The second rule should be the first. Optimization should only be done on code that works. Nobody cares how fast it is if its doing the wrong thing. Sometimes there are exceptions -- for example, if it takes 8 hours to get a test result to see if you fixed the bug(s) then it might be worth improving your turn around time because debugging is a lot more effective if you can iterate faster. Another case would be trying to debug a game which is running at a very low frame rate. Usually, however, you should make it right first and make it fast second.

Their third rule is really really important. I've been writing and optimizing code for a long time now, and on any program of significant size I can only rarely guess as the source of the slow down. On individual functions running on machines I am familiar with I can usually identify the likely problem area by inspection, but I just use that information to give me a place to start looking. I don't change anything until I know it is the problem. Certainly for anybody with less experience you should run a variety of profiles before you change a single line of code in the name of optimization.

My fourth rule is that you should always strive to improve the algorithm first. Do not even think about writing assembly code (note that I say writing -- reading the compiled code in the context of a profiling tool can be very illuminating). AltiVec specific code should come before going to assembly language, but it should come after algorithm improvements. Restructuring your algorithm to make it vectorizable or cache/VM-friendly counts as an algorithmic improvements (note that you can often save time by thinking about these considerations when you design the code in the first place!).

My fifth rule is to remember that there are different kinds of optimization. Be clear about what you are improving... execution speed? memory footprint? build times? load times? Sometimes you have to trade one of these for another, sometimes improving one improves the other. Be clear about what your goal is before you start optimizing.


I highly recommend Mac programmers look at Apple's CHUD tools, and read Apple's various Dev notes on the subject of optimization. There is a lot of good information in there. Ask more experienced people questions, this is often the best way to learn about making your code better.
2003.10.22 10:47 PM
Quote this message in a reply
Mars_999
Unregistered

 
Post: #4
Optimisation
I usually run infinte loops! LOL Big Grin
2003.10.23 12:27 AM
Quote this message in a reply
DoG Offline
Moderator
*****

Posts: 400
Joined: Mar 2005
Post: #5
Optimisation
Quote:Originally posted by Programmer
The first rule is complete crap. Of course you should optimize your code. If you don't pay attention to performance then how do you become an "expert"? And the notion that only experts can do this is nonsense.
[...]


No its not. If you think about it, it serves as a warning not to optimize away without really being sure it is necessary.

The "expert only" statement refers to knowing what you are supposed to be doing faster and better. If you only know you are slow, but you do not understand the used algorithms, you cant really improve performance in complex cases. With a 3D vector class, you can surely get huge boosts by inlining everything, but this doesn't work with more complex things. However, you can probably get an even bigger boost by cutting down the amount of matrix multiplications you are doing. If you fail to realize these kinds of things, you are not an expert in the above sense.

DON'T PANIC
2003.10.23 06:56 AM
Visit this user's website Find all posts by this user Quote this message in a reply
Programmer
Unregistered

 
Post: #6
Optimisation
Quote:Originally posted by DoG
No its not. If you think about it, it serves as a warning not to optimize away without really being sure it is necessary.

The "expert only" statement refers to knowing what you are supposed to be doing faster and better. If you only know you are slow, but you do not understand the used algorithms, you cant really improve performance in complex cases. With a 3D vector class, you can surely get huge boosts by inlining everything, but this doesn't work with more complex things. However, you can probably get an even bigger boost by cutting down the amount of matrix multiplications you are doing. If you fail to realize these kinds of things, you are not an expert in the above sense.


The first rule simply says "do no optimize". Your first point is their 2nd rule... "do not optimize -- yet". This means don't do it until you know where you need to, which may include nowhere if it meets the performance targets.

You don't have to be an expert to do this, you just have to learn. Where do experts come from except as novices who learned? I believe that all people writing code should have some basic understanding of efficiency and performance otherwise they are way too likely to be writing O(n^8) algorithms.
2003.10.23 10:11 AM
Quote this message in a reply
DoG Offline
Moderator
*****

Posts: 400
Joined: Mar 2005
Post: #7
Optimisation
Quote:Originally posted by Programmer
The first rule simply says "do no optimize". Your first point is their 2nd rule... "do not optimize -- yet". This means don't do it until you know where you need to, which may include nowhere if it meets the performance targets.
[...]


1st rule of fight club: Don't talk about fight club.
2nd rule of fight club: Don't talk about fight club.

#1 The boss is always right.
#2 If the boss is not right, refer to #1

The above statements are duplicates, the 2nd rule is completely unecessary, yet it gives additional power to the 1st rule. Call it poetry Wink

XP Optimization rules translation:

#1 Do not start writing a function by obfuscating your code with useless optimizations, potentially messing up your algorithm. (YouArentGonnaNeedIt)

#2 & #3 When you need to optimize, think about the best strategy first. Is your current algorithm the most efficient? If not, try another one. Make sure your instict is correct by collecting performance data, eg. profile. Only start writing assembly when you are out of options.

DON'T PANIC
2003.10.23 11:19 AM
Visit this user's website Find all posts by this user Quote this message in a reply
henryj
Unregistered

 
Post: #8
Optimisation
The rules are correct.

If you don't know what you are doing then don't optimise. The first thing that novice programmers, especially games programmers, think of is speed. This is before they even write any code. Speed is the last thing they should be concerned about. How many times have we seen people ask how to write an fps counter on this forum? If your game is slow an fps counter isn't going to tell you why it's slow.

The second rule says if you are an expert still don't optimise. This is the redundant rule because if you are an expert then you probably know this. It is only included because of the strange way that novice minds work. People who know nothing assume they know everything. It is only as you learn more that you realise you know nothing. This is the first step to becoming an expert.

The third rule is the most important. Use the profiler. CHUD and OpenGL profiler are the best profiling tools available on any platform.
2003.10.23 05:03 PM
Quote this message in a reply
Programmer
Unregistered

 
Post: #9
Optimisation
Quote:Originally posted by henryj
If you don't know what you are doing then don't optimise. The first thing that novice programmers, especially games programmers, think of is speed. This is before they even write any code. Speed is the last thing they should be concerned about.

Taking into account performance requirements is something you should take into account before you write any code. Failure to do so will frequently require hacking the hell out of your code later, or rewriting it from scratch. In any system of significant size or any project on a schedule you generally cannot afford to do this. By planning for performance you can obviate the need for many after-the-fact optimizations. By failing to do so you can end up with designs which can never reach acceptable performance levels.

This applies to other kinds of "performance requirements" as well. Memory footprint, speed of development, etc. Planning ahead can save you amazing amounts of grief, and its a lot cheaper to throw away plans than prototypes, and prototypes and real implementations.


Think before you do.
2003.10.23 11:30 PM
Quote this message in a reply
Programmer
Unregistered

 
Post: #10
Optimisation
Quote:Originally posted by DoG
The above statements are duplicates, the 2nd rule is completely unecessary, yet it gives additional power to the 1st rule. Call it poetry Wink


The difference between the rule pairs you quote and the one on the optimization page is that your rules are duplicates. The optimization rules are not, they are contradictory.
2003.10.23 11:36 PM
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 2 Guest(s)