Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Evil_Greven

Challenge 11/13: Do you know your code?

This topic is 5353 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

The objective: A simple bounding box collision detection code segment. The question: Which of the two is faster? You have a point(ix,iy) that you must use to detect a collision with box, with a point(x,y) and width and length of 20. Thusly, you must decide which is faster: SEGMENT 1: if((ix > (x-10)) && (ix < (x+10)) && (iy > (y-10)) && (iy < (y+10))) { //collision code here! } SEGMENT 2: if(ix > (x-10)) { if(ix < (x+10)) { if(iy > (y-10)) { if(iy < (y+10)) { //collision code here! } } } } Do you know the answer? -Greven

Share this post


Link to post
Share on other sites
Advertisement
I say segment 1... because at least in C++ as soon as one of the conditions is false, it will move on to whatever's next

in segment 2 the machine is forced to evaluate each condition

EDIT:

oh wait... no it isn't because you nested the second one... I still go with segment 1

[edited by - tempuself on November 13, 2003 6:30:48 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by TempusElf
I say segment 1... because at least in C++ as soon as one of the conditions is false, it will move on to whatever''s next

in segment 2 the machine is forced to evaluate each condition


T
empusElf




No the if statements are inside each other, so if the first fails, the others are not evaluated.

Share this post


Link to post
Share on other sites
a) depends on how often that code is executed and where. It''s pointless even being concerned about the differences if its in an insignificant place.

b) they should be exactly the same. If the && were & things might be different, but && on a decent compiler should give you the same as the nested if statements by early-outing as soon as a condition fails.


c) depends on the particular compiler.

d) depends on the types of the input variables.

e) depends on what code surrounds that code.

f) depends on whether the compiler has enough spare registers/FP stack space to avoid temporaries in memory (that''s a case by case thing too - using that in one place may well be different than another aplace).

g) if you''ve profiled the posted code and found one of those to be significantly different than the other then I''d be VERY suspicious of the way you''re profiling. If it tests one then the other in a big loop or two big loops, it''s already potentally flawed due to the first one incurring the higher of the caching penalties.

h) if the compiler were able to re-order an expression for better branch prediction then the first might be slightly faster

Share this post


Link to post
Share on other sites
My intution tells me segment 1, just because there''s only one point the code has to jump to, whereas it appears that (unless the compiler optimizes it away) there are more possible address to jump to, thus bloating the code a little more.

Actually, I''m no c++ guy, so that''s more like my 1 1/2 cent''s worth,
-Michael

Share this post


Link to post
Share on other sites
quote:
Original post by Chris Hare
The first is better, it is more readable, and will short-circuit when optimized.

Wizza Wuzza?


Actually it will short-circuit even when unoptimized, the c++ standard requires it, so that you can do things like this, without getting access violations

if(player && player->IsAlive())
{
//Do stuff
}

Share this post


Link to post
Share on other sites
they are 100% identical logical constructs, so any compiler which doesn''t generate the exact same code should note be allowed to use the term "optimizing compiler" ... quite simply, back in the days before compilers did analysis and optimizations things like these:

// assuming i is an int
++i;
i++;
i = i + 1;
i += 1;

could each generate different compiled code ... but in the days of compiler code analysis, these should always be 100% equivelent (in this simple case) ... obviously for real classes with overloaded operators

// assuming custom class
++obj;
obj++;
obj = obj + 1;
obj += 1;

will still all generate different code ... so please people, quit using obj++; when you do not NEED postfix increment ... it''s just wrong.

Share this post


Link to post
Share on other sites
quote:

I say segment 1... because at least in C++ as soon as one of the conditions is false, it will move on to whatever''s next



So will section 2.

Share this post


Link to post
Share on other sites

  • 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!