Archived

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

Cost of Function Pointers (using them)?

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

Does anyone know the cost in terms of ticks for using function pointers? I need to use the notion of virtual functions without actually using them (costs to much)... Base-Time template diriving - (as described in: http://www.gamedev.net/reference/programming/features/impperfcpp/) - cant be used because I still need the run-time side; so I was thinking about using function pointers and derived classes that would register their version and save it within a function pointer of the base class. logically it should work... but I'm just wondering what the cost would be to call a function pointer (with operands)... Thanks David [edited by - crakinshot on November 8, 2003 8:06:39 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You "know" that virtual functions "cost too much", but don''t "know" what function pointers "cost"?

No offense, but, ... nevermind. I''ll bite my tongue for you.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If you''re all that desperate for speed you could look up static polymorphism using templates, with policies and that stuff. But, I can almost guarantee that you''re not gonna notice the overhead of virtual function calls. Good luck!

Share this post


Link to post
Share on other sites
well I "know" that virtually (run-time look up) called functions cost 24 ticks without additional variables... what I "don''t know" is how many ticks a function pointer (direct) costs...

is it slower? faster?

I dont know why you have to bite your tongue.... please if I''ve got something wrong, please dont bite your tongue and and tell me so that I dont make the same mistake again... I dont pretend to know everything...

Share this post


Link to post
Share on other sites

void foo() { }
void (*foo_ptr)() = foo;


this doesn''t cost anything ( calling foo_ptr() is same fast as calling foo() directly ).

for accessing member functions i''ve been using boost::function, and there is nearly no expense in it.

how exactly do you want to store a classes version in a function pointer?

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
If you''re all that desperate for speed you could look up static polymorphism using templates, with policies and that stuff. But, I can almost guarantee that you''re not gonna notice the overhead of virtual function calls. Good luck!


hehe... its annyoning... everyone saying classes and their abilitys are evil and slow... (then they use their optimal code with template strings instead of unsigned char*... Heheh...

Share this post


Link to post
Share on other sites
quote:
Original post by 666_1337
how exactly do you want to store a classes version in a function pointer?



something like (probably wrong code - but general idea):


class A
{
public:
void (*foo_prt)(int a, int b); //pointer


protected:
void register_foo((*foo)){foo_prt=foo;}
};

class B : public A
{
public:
void foo_B(int a, int b);
B() {register_foo(foo_B);}
};



so now if at run time I called foo() on a list of A items each would call their dirived versions directly.

I've only been looking at this stuff for an a few hours so I dont know the exact code but its the general idea...


[edited by - crakinshot on November 8, 2003 8:55:39 AM]

Share this post


Link to post
Share on other sites
I have to agree with emilk really... a virtual function works through the rtti mechanism, and looks up the function pointer through the vtable. You can only speed this up using the templating mechanism described admirably in todays featured articles.

Share this post


Link to post
Share on other sites
yes but it is having to look up the vtable every time you call the base function.... you define the function to call within a member function then it will directly invoke that function instead of having to look up dymanically. i.e. your derived classes set the base function pointer and then all calls to it call that which is set.

I dont know... it seems a logical approch if you dont want the virtual lookup each time without using compile-time deriving (templates).

Share this post


Link to post
Share on other sites
quote:
Original post by 666_1337

void foo() { }
void (*foo_ptr)() = foo;


this doesn''t cost anything ( calling foo_ptr() is same fast as calling foo() directly ).

for accessing member functions i''ve been using boost::function, and there is nearly no expense in it.

how exactly do you want to store a classes version in a function pointer?




Actually, you are wrong. calling foo_ptr() is definitely slower than calling foo(). Remember foo() is a call that can be determined at compile time. In plain terms, the compiler could and should simply add codes to transfer control to the foo when you compile in such a call. However, given a foo_ptr(), the compiler would be inserting calls to load in the variable foo_ptr, perform a jump to the value indicate by foo_ptr. Of course, the call may be insignificant, but it''s still a cost (specially in tight condition of multiple calls perhaps).

Share this post


Link to post
Share on other sites
quote:
Original post by 666_1337

void foo() { }
void (*foo_ptr)() = foo;


this doesn''t cost anything ( calling foo_ptr() is same fast as calling foo() directly ).
That would be very, very surprising. There is an indirection involved in the function pointer.

Anyway, if you are so concerned about run-time performance, why don''t you profile both solutions yourself? Remember the three golden rules of optimization.

Cédric

Share this post


Link to post
Share on other sites
hehe... never profided before... I''m kindof running ahead and missing things... :/

I was going to use virtual and it would all be nice and simple... then everyone turned around and smashed that idea and said virtual is bad and slow... arge... I dont want to do it a bad way at first and then find out I have to convert 40 classes to use a different method...

I''ll check up on profiling and hopefully set this matter to rest.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
virtual is fine, simple, elegant, and fast. tell those people who told you its evil and slow to stop pretending to be programmers.

Share this post


Link to post
Share on other sites
Sure, virtual functions will be slower than a normal compile time bind function call. But unless you design your application in a way that you can get all those function calls at compile time, you will find that the way you implement could be similar, and maybe as fast as the how the C++ vtable works. Chances are you will get a slower implementation unless you are really good.
Most people bash virtual functions and then go around implementing a long, ugly switch which is just a plain maintaince nightmare, or simply a nightmare when you try to extend the application. For example, in the famous Shape example. Adding more shapes would involve adding a new case statement in all those relevant functions. If a shape has a lot of functions, then just have fun adding a case statement everywhere. Hope you don''t miss one less addition as well.
Other people might go around and implement function pointers. But just how different is that from a vtable? So they just added their own ''function redirection'' codes. Neat. Now, if you have more functions that need to use this ''simulated'' virtual, you get to add more pointers. Efficiency goes down the line as more and more need to be ''virtual'' *woo hoo! more function pointers you gotta add! I''m sure they are not as fun as adding more value/feature to your application* *sacasm*

Share this post


Link to post
Share on other sites
What is wrong with this thread?
quote:
hehe... never profided before... I''m kindof running ahead and missing things... :/

This post falls squarely and completely under "premature optimization." Please read that thread.

Share this post


Link to post
Share on other sites
quote:
Original post by dot
Other people might go around and implement function pointers. But just how different is that from a vtable? So they just added their own ''function redirection'' codes. Neat. I''m sure they are not as fun as adding more value/feature to your application* *sacasm*

No, but they can post about how it is faster on GameDev.net and THAT makes it all worthwhile.

Share this post


Link to post
Share on other sites
quote:
Original post by dmounty
I have to agree with emilk really... a virtual function works through the rtti mechanism, and looks up the function pointer through the vtable. You can only speed this up using the templating mechanism described admirably in todays featured articles.

RTTI has nothing whatsoever to do with virtual functions. Please look up what RTTI is, it is disabled by default on most compilers and your virtual functions still work.

Share this post


Link to post
Share on other sites
out of intrest, why do you want to know the number of ticks?
I''m not convinced this would be a static number anyways depending on how the rest of the pipeline is working and how instructions are being decoded (while not being a compiler theory expert myself its possible that the cpu could start looking up the function pointer to be called before it needs to be called and interlacing other operations around it...)

Share this post


Link to post
Share on other sites
quote:
Original post by crakinshot
hehe... all I asked for in the beginning was the number of ticks... A simple number would of sufficed...
Dude, you''re missing the point. You don''t need this information. That''s why no one here knows the answer. It does not matter.

And besides, it''s probably compiler and platform dependant anyway.

Share this post


Link to post
Share on other sites
42 ?

As other people pointed out, it depends on the CPU, the state of the pipeline and how the code has been laid out by the compiler.

There is no answer. He could, however, write his own test case and time it himself. This smacks of laziness.


[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]


[edited by - Fruny on November 8, 2003 2:33:37 PM]

Share this post


Link to post
Share on other sites
Just do some simple testing... it really shouldn''t be all that complex, and if it''s your only option, you don''t have much of a choice anyways . It''s the most efficient option you''ve got, so not much reason to look for specific speeds, unless you think there are faster/more efficient ways.

Share this post


Link to post
Share on other sites