Functionoids vs Member Function Pointer?

[Immortal_Nephi]

I had a lot of research to see how function pointer works. Sometimes,
programmers choose switch keyword and function in each case block can
be called. Sometimes, they choose ordinary function pointer array
instead of switch.

They believe that ordinary function pointer is much faster than
switch. Think of one variable called selectFunction. selectFunction
variable can be the range of 0 through 1,000 or more.

Load selectFunction variable into a register. Load memory address of
ordinary function pointer array into a register. Both registers can
be added together to create indirection before one of these 1,000
functions can be called.

Member function pointer array is slower than ordinary function pointer
because first step is to load "this" pointer to locate memory address
of member function pointer array. It is likely that member function
pointer array needs to execute indirction twice before one of these
mmber function is called. Only ordinary function pionter needs one
indirection.

How can you find a way how member function pointer array can execute
one indirection instead of two indirection? A vtable has a memory
address where constructor function and deconstructor function are the
top. You can use selectFunction variable to be added to "this" pinter
in vtable memory address. Then, one of these 1,000 member functions
in the vtable can be called.

I did read C++ Lite FAQ and it does mention functionoids. They claim
that functionoids are much faster than member function poitner array.
How can it be possible to be true?

I would prefer to use static memory where member function pointer
array is stored at compile-time. I may do not need virtual functions
becaus I choose not to use dynamic binding.

Please advise which I should choose to use ordinary function pointer,
member function pointerarray, or functionoids.

Short example of code looks like this below.

int selectFunction = 0;

.....
do something ....
.....
selectFnction may be modified to have a value of 100.

.....
.....
FuncPtr [ selectFuntion ] ();
.....
100th member function is called...

Nephi

[Jon Harrop]

Im************@hotmail.com wrote:

They believe that ordinary function pointer is much faster than
switch.

Looking up a branch location can be faster but it is often much slower.
Specifically, when there are a small number of choices it is faster to use
nested branches to fixed locations.

I did read C++ Lite FAQ and it does mention functionoids. They claim
that functionoids are much faster than member function poitner array.
How can it be possible to be true?

The C++ Lite FAQ is wrong. They are describing rudimentary precursors to the
first-class functions now found in all modern languages because they are
the only workarounds available in C++.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

[Immortal_Nephi]

On Sep 13, 5:24*am, Jon Harrop <[e-mail]:

[e-mail] wrote:

They believe that ordinary function pointer is much faster than
switch.

Looking up a branch location can be faster but it is often much slower.
Specifically, when there are a small number of choices it is faster to use
nested branches to fixed locations.

I did read C++ Lite FAQ and it does mention functionoids. *They claim
that functionoids are much faster than member function poitner array.
How can it be possible to be true?

The C++ Lite FAQ is wrong. They are describing rudimentary precursors to the
first-class functions now found in all modern languages because they are
the only workarounds available in C++.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u

Dr Jon D Harrop,

I agree that nested branch like switch keyword, but sometimes, un-
nested branch with 1,000 branches in "JMP Table" is faster. It
depends on the processor specification. If you force all functions to
be inlined in un-nested branch and nested branch, then C++ Compiler
will fail to compile because it exceeds branch limit. Not all C++
compilers have exceeded limit support.

Branch misprediction is a major problems. I don't know if modern
machines like x86 32 or x86 64 at 3 GHz may solve it.

I believe that function pointer with "CALL Table" may be preferred.
You have to make sure that stack frame is not needed. Then all sub-
functions can be inlined in each function inside function pointer
table.

My question is -- do you recommend me to use ordinary function pointer
or member function pointer? Ordinary function pointer is faster
because it uses one indirection. I can use class as long as I want,
but I will define member function pointers to be static.

What do you think?

Nephi

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-09-13 04:50, Im************@hotmail.com wrote:

I had a lot of research to see how function pointer works. Sometimes,
programmers choose switch keyword and function in each case block can
be called. Sometimes, they choose ordinary function pointer array
instead of switch.

They believe that ordinary function pointer is much faster than
switch. Think of one variable called selectFunction. selectFunction
variable can be the range of 0 through 1,000 or more.

Load selectFunction variable into a register. Load memory address of
ordinary function pointer array into a register. Both registers can
be added together to create indirection before one of these 1,000
functions can be called.

Member function pointer array is slower than ordinary function pointer
because first step is to load "this" pointer to locate memory address
of member function pointer array. It is likely that member function
pointer array needs to execute indirction twice before one of these
mmber function is called. Only ordinary function pionter needs one
indirection.

How can you find a way how member function pointer array can execute
one indirection instead of two indirection? A vtable has a memory
address where constructor function and deconstructor function are the
top. You can use selectFunction variable to be added to "this" pinter
in vtable memory address. Then, one of these 1,000 member functions
in the vtable can be called.

I did read C++ Lite FAQ and it does mention functionoids. They claim
that functionoids are much faster than member function poitner array.
How can it be possible to be true?

I would prefer to use static memory where member function pointer
array is stored at compile-time. I may do not need virtual functions
becaus I choose not to use dynamic binding.

Please advise which I should choose to use ordinary function pointer,
member function pointerarray, or functionoids.

Have you carefully profiled your code and analysed the results and from
that decided that the calling mechanism is the best place to optimise
your application? Unless you have you should do so before doing
something that will further obscure your code.

Short example of code looks like this below.

int selectFunction = 0;

....
do something ....
....
selectFnction may be modified to have a value of 100.

....
....
FuncPtr [ selectFuntion ] ();
....

Can you reorganise the code to call the correct function instead of
setting selectFunction to a value? If possible that should be the most
performant way to do things since the compiler knows which function to
call and can do stuff like inlining etc.

Another possibility is to replace selectFunction with a function-pointer
and assign the correct function to it where where you today assigns a
value to selectFunction.

--
Erik Wikström

[James Kanze]

On Sep 13, 4:50 am, [e-mail] wrote:

I had a lot of research to see how function pointer works.
Sometimes, programmers choose switch keyword and function in
each case block can be called. Sometimes, they choose
ordinary function pointer array instead of switch.

They believe that ordinary function pointer is much faster
than switch.

Who'd be stupid enough to believe something like that. If an
indirect jump is the fastest method on a given machine, that's
what the compiler will generate for a switch. In the distant
past (before extensive pipelining), it was usual for compilers
to break switches down into different categories: a dense switch
would be implemented by means of bounds checking and a jump
table, a scattered switch would use a lookup table to determine
the index, and then the jump table. And small switches would be
implemented as a hardwired binary search, using code more or
less equivalent to nested if's. The cut-off point where the use
of the jump table became a win depends on the processor; on
older machines, without extensive pipelining, it's often as
little as four cases. On a modern machine, with extensive
pipelining, branch prediction (which is often invalidated by an
indirect call), etc., the cut-off is often a couple of hundred,
or even a couple of thousand; some compilers probably don't even
bother with even considering the jump table, since the cut-off
is high enough that it will never be reached in reasonable code.
(Which is debattable: in hand written code, of course, you
probably will never have more than a couple of dozen cases, but
in machine generated code, switches with several hundred cases
or more are not unreasonable.)

At any rate, it's the compiler's problem to get this right, not
yours.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]