#### Archived

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

# Challenge 11/13: Do you know your code?

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

## 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 on other sites
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 on other sites
The compiler should generate the same code for both, so my answer is that they are equally fast.

##### 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 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 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 on other sites
The first is better, it is more readable, and will short-circuit when optimized.

Wizza Wuzza?

##### 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 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 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.

1. 1
2. 2
3. 3
Rutin
17
4. 4
5. 5

• 14
• 9
• 9
• 9
• 10
• ### Forum Statistics

• Total Topics
632917
• Total Posts
3009200
• ### Who's Online (See full list)

There are no registered users currently online

×