Ok, I've heard in a lot of places to avoid using too many if's, because they're slow. But I heard somewhere (on this board, once or twice upon a time), that whether or not it's slow depends on what conditions you're testing. So I was wondering, what conditions are slow and what aren't?
i.e.
is this slow:
bool x = false;
if(x)
...
And,
is #1 slower than #2:
#1 -> if(a <= b)
...
#2 -> if(a < b)
...
I'm just sort of confused about what it is that's slow, and I want to clear that up...
Just Google It. √
(\ /)
( . .)
c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.
the actual condition testing is not what's slow, its the controll path of the program not being predictable. when you compile and run a program, some of what is executed gets "pre-processed". with many 'if' statements, the machine is not able to predict program flow.
my description is pretty bad. look up branch prediction, pre-processing, and instruction pipe-lines to find more info.
And actually, they're not that slow anymore. Modern branch prediction on a Pentium 4 has about 94% success.
As mentioned, the reason that they are slow is that the CPU is actually "working ahead". Rather than do instructions sequentially, waiting for one to finish before doing the next (very slow), multiple instructions are at different stages of decoding at the same time. A P4 can have as many as 126 instructions in-flight simultaneously. So at the time it's calculating the branch, other parts of the CPU are working on instructions that happen after the branch. On the 4% of times the branch is mispredicted, all that work has to be thrown away, and you essentially waste 19 clock cycles (the pipeline is 20 levels deep).
Ohh, I see. I thought it just took a long time to compare things or something, and I couldn't figure out whyThanks for clearing that up!
Just Google It. √
(\ /)
( . .)
c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.
