Jump to content
  • Advertisement
Sign in to follow this  
THACO

Optimization

This topic is 4862 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, just double checking this, but is it a good idea to try to use multiplication over division. Say I have to divide 2 or more things by the same float, should I find the 1/float then multiply by that instead of dividing? -THACO

Share this post


Link to post
Share on other sites
Advertisement
If you have to divide 2 float outside the loop then it's not the bottleneck or you are writing hello world...

Share this post


Link to post
Share on other sites
Such micro optimization tends to be performed by any good compiler these days. You're probably gonna get substantially better performance by thinking/changing at the algorithmic level as that is something the compiler can't touch [smile]

hth
Jack

Share this post


Link to post
Share on other sites
I have never actual use a code profiler, when should I use, incrementally, only at the end? I use VC++ 2003, does that have one, any place I can go to read up on that. Right now I am only at the early stages of my game/engine but I assume at some point I should use a profiler if it be for this project or later on in life.

-THACO

Share this post


Link to post
Share on other sites
Quote:
Original post by THACO
I have never actual use a code profiler, when should I use, incrementally, only at the end?

Profiling code is a pretty big topic with lots of different methods... Have a look at this Wiki Entry for a brief overview.

You will tend to run your profiling whilst the application is running - and then output to a file "on the fly" or spit it out at the end of execution.

If you suspect a piece of code might be causing a problem you surround it in timing code, measure the difference in the system clock between when it started and when it finished.

If you're running under Win32, have a look at the QueryPerformanceCounter() and QueryPerformanceFrequency() functions.

Quote:
Original post by THACO
I am only at the early stages of my game/engine but I assume at some point I should use a profiler if it be for this project or later on in life.

Yes, you will want a profiler at some point - either your own or a 3rd party library/program.

I've said it a lot of times before, but trying to optimize without instrumentation is a bit pointless - you're reduced to, at best, informed guessing. Not only do you not know where to focus your efforts, but you won't be able to measure any gain (or reduction!) in performance from your changes [smile]

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Such micro optimization tends to be performed by any good compiler these days. You're probably gonna get substantially better performance by thinking/changing at the algorithmic level as that is something the compiler can't touch [smile]


True enough, I too was like you once, tried to optimize every single equation (most of the time just doing what the compiler optimized internally) ... and commonly? Well, I went a few steps further and noticed that I could one pass instead of two, and wham, all multiplication optimizations and all ugly little hacks I had come up with was now just a complete waste of time seeing that my "real" optimization just overdid the performance gain from all the ugly little hacks by a 100 times... that was the last time I ever "useless" optimizations for all my code.

However, regarding the initial question, first dividing and then multiplying should provide a loss of accuracy in exchange for minor speed, is it actually worth it considering the poor accuracy of floats (perhaps not on Intel as they are using 40bit floats internally if I'm not mistaken).

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Such micro optimization tends to be performed by any good compiler these days.
That's actually not true in this case. No compiler is (by default) going to replace e.g.

float r = a / c;
float s = b / c;

with

float t = 1.0f / c;
float r = a * t;
float s = b * t;

because these expressions are not equivalent, due to how floating-point arithmetic works. That is, if the compiler made changes like this, it could ruin a carefully crafted floating-point expression that you meant to look a particular way in order to e.g. maintain as much as precision as possible.

Having said that, some compilers have compiler flags that informs it that you're allowing it to perform rewrites of the above kind, and that you're willing to live with the inaccuracies such rewrites can introduce.


Quote:
You're probably gonna get substantially better performance by thinking/changing at the algorithmic level as that is something the compiler can't touch
This on the other hand is very much accurate and great advice. Always begin any optimization by considering a change of algorithm before doing anything else.



Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Thaco,
Ok, 1) Memory is the bottleneck. Always.
I would say, in general a profiler (such as AMD's super-free CodeAnalyst) is good to use at regular intervals to 1) validate what you expect your slow-downs to be and 2) speed-up code that you think can be faster.

So I've come to view writing optimized programs as like a game of chess... the first few times, you barely know the rules, move some random pieces and eventually lose (At this point, some people actually quit!). After a dozen games, you've learned the rules and you've seen patterns emerge and maybe come away with a satisfying result. But if you look at grandmasters, they treat chess the way performance programmers treat code.

The opening moves: I think of this as choosing your algorithms and memory-access patterns. These are highly studied, well-understood choices you can pursue according to your specific goals and architecture. Very simply, book-knowledge wins this every time; it simply comes down to studying. In general, at this point my goals are to choose data structures that are as compact as possible and allow my algorithm to access data sequentially.

Then comes the middle game. At this point you are beyond the domain of 'known' trajectories for your problem. In chess, your goal is to simplify to a point where you have obvious strengths with weaknesses that are containable. Now, accordingly, in your code you don't have an obviously expoitable weakness like some virtual call that is accessing memory who-knows-where. Your game should be well-conceived to run tight, with boundary conditions checked at a high level, and low-level routines that require coherent, correct input. (Fault-tolerance is a high level issue)

Then there is the end-game or mating combination. This is generally the assembly routine if such precision is necessary. According to the connotation assumed from chess, this should be quite easy to write and very satisfying. Indeed it is true, it is quite common to blast through 100 lines of assembly without a single error, while in C it is very rare. Most probably, this results from the fact that you've taken such a thought-intensive route to get to the end, the bugs have been predicted and accounted for on the way.

Now, you can think of the profiler as that score that computers give you when you play a move. "Oh, now I'm -1.20, that means I did a dumb thing..." Except that you can always undo your move! So at the beginning, the results don't matter that much, assuming you have a well-informed plan. But you'll find people that never check, then late in the game they say "Oh crap, I'm -5.0!" and it all has to do with a decision made a long time ago. And now it's too late.

So anyway, if someone says "Micro-optimization!" they're probably right... but why not profile for yourself and see the difference? Making a decision and receiving feedback is the only way for a sentient being to learn.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!