Back to General and Gameplay Programming

massive if's vs continue

General and Gameplay Programming Programming

Started by bencelot May 13, 2008 02:19 AM

22 comments, last by Steadtler 15 years, 11 months ago

634

May 13, 2008 09:07 PM

looks an awful lot like premature optimisation to me. I second the person that said make the code correct, readable and maintainable.

IMO I doubt any syntatic change you make will matter so long as the predicates are the same and the overall result of the expressions are the same, the compiler will almost certainly reorganise your statements to maximize things you arn't even worrying about yet (cache, BPU hit rate, instr. pipeline/mem stalls etc)

On a side note, and just out of interest.
This is an excellent candidate for paralleling.

PS> this is off the top of my head, probably won't compile

typedef std::vector< Player >::iterator player_iter;void heal_thread_func(player_iter begin, player_iter end) {   for( player_iter i = begin; i != end; ++i ) {        if( i->GetTeam() == 2 && i->GetHP() < 75 && i->IsAlive() ) {           i->Heal();        }   }}void heal() {   boost::thread_group* tg = new boost::thread_group();   const int c = player.size() / 3;   tg->create_thread( boost::bind(&heal_thread_func, player.begin(), player.begin() + 1*c );   tg->create_thread( boost::bind(&heal_thread_func, player.begin() + 1*c, player.begin() + 2*c );   tg->create_thread( boost::bind(&heal_thread_func, player.begin() + 2*c, player.end() );   tg->join_all();}

"I am a donut! Ask not how many tris/batch, but rather how many batches/frame!" -- Matthias Wloka & Richard Huddy, (GDC, DirectX 9 Performance)

http://www.silvermace.com/ -- My personal website

iMalc

2,466

May 14, 2008 02:21 AM

I would be VERY surprised if your compiler didn't produce identical assembly code for both ways of doing it.
It is really only a matter of taste. Use whichever is clearer.

"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

172

May 16, 2008 09:51 PM

Quote:Original post by sphen_lee
Quote:Original post by nb
Quote:Original post by samoth
Quote:Original post by nb
some compilers / compiler settings actually do the if statements either way you suggested. They can be set so that they stop checking once a section of the if statement fails, or they can check the entire expression regardless of if any have already failed or not.
Careful, though. This may be a "speciality" of Delphi (don't know anything about Delphi really).
In C/C++, it is clearly against the standard (you are guaranteed that the right side of && will not execute if the left side is false), and any compiler implementing it differently is broken. I wouldn't want to use a compiler that lets you customize such a behaviour, since many programmers indeed rely on that assertion, so it may break code that's perfectly valid.

i did say 'some'. as a default delphi does not check all statements if one is already found to be crap. i'm sure there's a reason why it can be toggled to do checks on all statements... maybe something to do with being able to debug values that it would otherwise trash and render un-readable when it got to the if statement. don't know. all's good.

As samoth says, any C/C++ compiler that doesn't short-circuit logic is very broken. It breaks a very common if statement involving NULL pointers:
if(ptr && *ptr == some_value)...
If the compiler doesn't short-circuit the &&, it will dereference a null pointer.

exactly the same thing for delphi... my last point was more that i do not know the reasoning behind NOT short-circuiting, and can only assume it is for what i already mentioned.

Personally i find that it's sometimes cleaner to put the if over multiple lines if as previously discussed the statement pushes too far to the right

if (a = b) and   (c = d) and   (so_on = and_so_on) then begin  do_something_cool;end;

i would also add that it would be wise to put a comment near the first part of the if that says something like "make it easier to read" so that you don't suddenly come across a piece of your code formatted different and have to wonder why you did that and why is it appears to be special etc.

Steadtler

220

May 16, 2008 10:39 PM

To add my grain of salt, always profile before optimizing. Else you're just wasting your time.

But always use the pre-operator (++i) unless you have a good reason not too...

Also, if that code is real, you have bigger performance problem than && vs continue. For example, you are calling your [] operator 4 times when one would suffice, and thats inside the loop, and the call to .size() should be taken outside the loop...

IMO I would have written it like this:

const unsigned int maxPlayer = playerarray.size();for(int playerIndex = 0; playerIndex  < maxPlayer ; ++playerIndex ) {PlayerType& player = playerarray[playerIndex ];if(player.GetTeam() == 2 && player.GetHP() < 75 && player.IsAlive()){playerHeal();}}

Now thats a start. If you want to make it clean, it would look something like this:

for_each(playerarray.begin(), playerarray.end(), ConsiderHealing());

or something.

massive if's vs continue

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

massive if's vs continue

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines