Lukasz, any chance you can access the assembly to see how the compiler
optimized it differently? That is a strange result. All that I could think
of is, if you have several places where the function is called, and the
compiler used to be inlining it, it may be faster (for cache reasons) to
make it a function call instead of inlining. Inlining is not always
fastest!
Regarding function pointers--from Agner Fog's guide:
"3.7 Indirect jumps (all processors except PM and Core2)
Indirect jumps, indirect calls, and returns may go to a different address
each time. The
prediction method for an indirect jump or indirect call is, in all
processors except PM and
Core2, simply to predict that it will go to the same target as last time it
was executed. The
first time an indirect jump or indirect call is seen, it is predicted to go
to the immediately
following instruction." (The Pentium M & Core2 have more sophisticated
indirect jump prediction)
So, if a function pointer always points to the same function, all processors
will predict the branch correctly! I am doubtful function objects would be
much faster, except that they may be more likely to be inline-able.
Also I disagree that well-designed code should cause function objects to be
predicted at compile time--it seems to me that their purpose is for run-time
polymorphism!
I will just tell You about my experiences:
- allmost all code of benchmark in Ego library is inlined (remove_stone is
not)
- function pointer are usually inefficient, because jump prediction works
poorly
- when I introduced a parameter to simple_playout::run: function
pointer that replaced play_one and always put address of play_one
there, then the code was slightly faster.
I have *no idea* why it was so.
- and most important: KISS
Lukasz
On 2/16/07, Darren Cook <[EMAIL PROTECTED]> wrote:
>> trouble. Also, the alternative is usually function pointers which
>> have
>> atleast 50 times the overhead of a function object. Correct me if I'm
>> wrong.
>>
> function objects really cannot be 50 times more efficient as function
> pointer are rather efficient with very little overhead.
With well-designed code, function objects ("functors") should be
compiled inline, and have zero overhead. Function pointers are never
inlined (unless modern compilers are getting *really* clever), so they
always have some overhead. Functors are therefore divide-by-zero-times
more efficient (I don't know where Nick got the 50 times figure from :-).
(If the functor is large enough to not be inlined then it is execution
time that dominates and function call overhead is not important.)
Using functors might cause more code, so less code fits in cache. I
don't know how that affects overall performance.
Darren
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
