Performance and function pointers

Quote:

Original post by hahaha Lets say i have 1000 different pointers to 1000 different functions. Will it decrease performance if im constantly using function pointers?

As supposed to what? Doing something will always be slower than doing nothing.

say i have

woul it make in any difference in performance if i access it directly

FunctionToAccess();

or if i use a pointer to it like this SomeFunctionPointer Func = FunctionToAccess(); and call it

Func();

It'll be slower, yes. But only by a few cycles (A tiny fraction of a millisecond). However, this is micro optimisation. You probably don't want to worry about this at all, unless you're calling a function pointer like this thousands of times per frame, and you've profiled and found that this is a bottleneck.

Quote:

Original post by hahaha say i have *** Source Snippet Removed *** woul it make in any difference in performance if i access it directly FunctionToAccess(); or if i use a pointer to it like this SomeFunctionPointer Func = FunctionToAccess(); and call it Func();

No - SUV is faster than Formula 1. As long as you're not in some dedicated race track. Also, if you're in a golf course, golf cart is faster than both of those - it's the only vehicle you're allowed to drive there.

If you're always calling the same function from the same place, then you use direct call.
If you have an object that needs to access different functions, all defined during run-time, then you cannot use direct call, and need function pointers, or some different mechanism.
If context is known at compile time, function pointers may get inlined, removing the cost altogether.

A better question here would be: Can you avoid the function call?

That's a quite meaningless question to ask, really. Using the function pointer is likely to be a tiny bit slower, in reality, but it's used to solve a different problem. You use it where you cannot use the direct function call, and so comparing it to a direct function call is meaningless.

Use function pointers where you need dynamic function calls, and static function calls where you need static function calls.

If your problem can be solved with static function calls, function pointer doesn't add anything. If you need dynamic function calls, a static function call can't help you, so you need a function pointer (or some other mechanism that, effectively, ends up like a function pointer). So, a comparison between the two doesn't make any sense, because they are different tools for different problems.

Thanks evil steve for telling me what i wanted to know seeing that im using hundreds of functions pointers. Screw the rest of you

Quote:

Original post by hahaha Screw the rest of you

Are you certain you want to appear obnoxious and impolite to people who, after all, used their free time to help you?

In some cases it'll probably be a lot slower since the address of the function that is to be called cannot be known in advance. That means that the processor won't know where to cache the coming instructions from, leading to a stall at the actual call.

On a side note, you probably should do something about your repulsive attitude. Don't get me wrong, I don't really care. It's your opportunities to miss.

Quote:

Original post by hahaha Thanks evil steve for telling me what i wanted to know seeing that im using hundreds of functions pointers. Screw the rest of you

Ooo, your rating should be interesting to watch.

So, why the bad attitude towards those who actually gave you a very important tip?

That is, in the typical case, function pointers can't be replaced by functions, so the performance doesn't really matter, since there's no alternative.
When you know in advance which function to call, direct function calls are (slightly) faster and (a lot) nicer to look at.
When you don't know in advance which function to call... there isn't much of a choice.

Seems like a fairly harmless and helpful piece of advice to me. Not sure why it offended you so much.

I was just wondering if function pointers have an effect on pointers. I use them a lot so now that i know that they will slow things things down im gonna have to take a different approach(not using function pointers)

Anyway i guess i have said that other stuff. Sorry guys

Quote:

Original post by hahaha I was just wondering if function pointers have an effect on pointers. I use them a lot so now that i know that they will slow things things down im gonna have to take a different approach(not using function pointers)

There are two articles that explore all function delegation in depth.

The observations are quite interesting.

For example, some compilers will recognize static binding, and completely inline the call. In another case, it's possible to avoid virtual nature of a method call, result in theoretically faster code.

In some cases, function pointers are incredibly slow. In others, there is no overhead at all.

All of this depends completely on the compiler, the code, and everything else.

But no matter what method you use - it's passing the parameters that is incredibly expensive. Function call is just a statement - but passing parameters into the function can result in incredible overhead.

All things equal - direct function call will win due to inlining. But in complex systems statically referencing everything can have a much more adverse effect.

This is the type of question that cannot be answered with a yes or no. Even when presented with complete analysis of the situation, the answer will still be: depends.

The only way to determine if function pointers (virtual functions, new allocations, calling convention, cache performance, ....) have an effect of your code is through profiling. But until that point, talking about performance is redundant.

The greatest hit still comes from function call itself. Branching, cache incoherency, parameter copying - so the only reliable answer to your question is: don't call.

In C++, templates and lambda-like approach using functors can eliminate just about all overhead. Reason for this is that you provide a lot more information to the compiler, which then uses it to optimize things.

As example:

It doesn't matter how you call it, it'll be slow...

alternative:

Templated solution severly outperforms the original one, although it appears that a new object must be constructed, parameters need to be copied, and a function call must be made.

But compiler has so much more knowledge about the process that it will perform a bunch of optimizations:
- It will completely inline both, Params and func()
- It will inline Params constructor
- Variables passed into constructor will not be copied
- Func() will be inlined and will directly reference existing variables

This (not always) results in code that is several times faster than any other form of function call, where parameters need to copied and passed in their entirety.

Im going to explain exactly what i want to do.
Ive got two seperate DLLs. One for OpenGL Rendering and the other for Direct3D.
i have two classes, CD3DRenderer and COpenGL Renderer.At first i was going to setup function pointers for every function in the dlls depending on which one the user wants to use. Then i thought maybe i should create a template class with all the functions of the renderer and call them through the template class.

Any suggestions of how i should do this?

Do it statically, at compile time. It is rarely worth the trouble -- especially for a hobbyist developer -- to bother with runtime toggling of the underlying rendering API.

Appropriate application of preprocessor switches makes the whole system much, much easier. On the other hand, there's always the aspect of "why even bother" to consider. What benefit do you feel you're getting out of this system?

Its all for learning. Im only 15 and by the time i go to university i want to have as much programming experience as possible

That's a common -- but misguided -- reason. What you gain from your approach in terms of technique can be gained from a much smaller project -- having a single function defer, at runtime, to one of two runtime-selected implementations. That's it. One function.

The rest is just a problem of scaling that approach by a few orders of magnitude.

There's also some aspects of learning OpenGL and D3D in there, but if you try it your way you're comingling them both along with the ickiness of this runtime dispatch problem and coming away from it all with a half-baked system you spent a lot of time on but doesn't have a lot of practical application.

If you want to get programming experience, you want it to be interesting and relevant experience, I would assume. Simply pick a single API and use that, for now. Learn it well, make some cool stuff with it.

A runtime-API-swapping system is not actually that cool; doing it is actually pretty easy. Doing it really, really well first involves knowing how to design an appropriately abstracted rendering layer anyway (most people's approaches to the problem you're trying to solve end up being very low-level least-common-denominator homogenization of both APIs -- basically, renaming all the functions to a common set).

So you'd be much better off in the long run picking one API and writing some really cool games with it, in the process learning how to build a renderer on top of that API, and maybe in the future returning to this problem with that newfound perspective.

I actually used to write my rendering code in a DLL, the only difference being that I used an interface (class full of virtual functions) instead of function pointers. Same thing really.

However, as jpetrie pointed out, this isn't all that productive. Feel free to do it if you want, but try to think how much time you'll spend writing two renderers versus how much time you'll gain from being able to use D3D or OGL.

Also, function pointers (or virtual functions) shouldn't really be a performance issue (As I said in my previous post, make sure you profile). Your rendering classes should abstract stuff away so much that you shouldn't be calling these functions thousands or even hundreds of times per frame.

In short - don't worry about it just now. Just write your code however you feel comfortable and then profile it to see what parts need optimised.

Quote:

Original post by Spoonbender Quote: Original post by hahaha Thanks evil steve for telling me what i wanted to know seeing that im using hundreds of functions pointers. Screw the rest of you Ooo, your rating should be interesting to watch.

I'm seeing it at 666, oddly enough. :)

Is the main reason for being slower that function pointers completely break the processor pipeline?

In a way. Depending on the conditions, you're probably breaking the pipeline anyway just by having the function call, unless it's inlined or the processor is really good at pipelining jump instructions. With function pointers, the usual big loss is that it requires an additional memory lookup which can miss in the cache.