C speed question

[LongJumper]

In a function that I will be calling a whole lot of times every frame, I need to know which of these options will be faster to do the following:

I have function pointers that return some information in a structure based on what function is in the function pointer(obviously). Sometimes it doesn't need to get any information at all, in which case the function pointers are NULL.

Now, option one(what I have temporarily have in place) is to check if the various function pointers are pointing a valid function address. This means I'm basically doing 2 if statements per frame per particle, so something along the lines of 18000 if statements, if you were really to push the limits.

Option two would mean creating a dummy function that returns 0 everytime, so I'm basically calling two functions that are just {return 0;}.

I guess to sum it up, does an if statement take more time than the function overhead to just return 0?

[OneSadCookie]

the if statement would be quicker. Function call overhead is large.

[Andrew]

the reason for this is that a function call requires the contents of several registers to be pushed onto the stack (http://www.madchat.org/coding/osdevl/stack.html) (the contents of any registers you were using need to be saved), then later popped off the stack

[LongJumper]

Thanks. I was aware of the many register moves for the parameter and return address, but I didn't remember how costly they were. But I guess b address is a lot faster than n * mov register + b address, silly me.

[phydeaux]

If there's an if statement that needs to be really fast, and you're using GCC to compile (if you use XCode, it's probably compiling with GCC) you can use:
long __builtin_expect (long exp, long c)
to control the branch prediction, which can speed things up somewhat. For example:

#define unlikely(x) (__builtin_expect((x), 0))
...
(inside some loop)
if( unlikely( x==5 ) ){
numfives++;
}

means that you want the branch prediction to predict that the code will not go into the if block, so you only pay the penalty of missing a branch prediction on the case when x actually is 5.

This trick won't usually buy you that much speed, but it's good to know if your code needs to be as fast as possible. Here's a reference I found for some gcc builtins. (http://www.imodulo.com/GNU/gcc/Other-Builtins.html)

[Andrew]

phydeaux: thanks for WICKED tip!! :D I had no idea it was possible to give branch prediction hints

[LongJumper]

I thought it always predicts that it won't go into the block, since if a branch evaluates to false, it goes to the next line in assembly, which is faster than jumping somewhere else, so it assumes the first one.

[Andrew]

I thought it always predicts that it won't go into the block, since if a branch evaluates to false, it goes to the next line in assembly, which is faster than jumping somewhere else, so it assumes the first one.

It's a tad bit more complex:

http://www.extremetech.com/article2/0,1558,1155321,00.asp

The development of branch prediction algorithms is a huge priority for chip companies like Intel and IBM. Generally, the better your branch prediction algorithms, the longer you can make your pipeline without worrying about it having a detrimental effect on your CPU's computational power.