On 2/17/07, Luke Gustafson <[EMAIL PROTECTED]> wrote:
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!
There was only one place and no inlineing :)
So it was pure difference static/dynamic call.
And I did immediately look at the asm, the difference was very small.
exactly static / dynamic call :) So I don't get it.
But I don't won't to get it. Is to much for me. I.e. too absorbing :)
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)
I tested on PM, so this may be an explanation.
But anyway this is so small *detail* that I prefer to concentrate in
different places.
For instance I just implemented UCT and I want to publish it asap.:)
Lukasz
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/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
