[computer-go] Effective Go Library v0.101

[Łukasz Lew]

On 2/17/07, Luke Gustafson <lukeg3 at gmail.com> 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 <darren at dcook.org> 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 at computer-go.org
> >> http://www.computer-go.org/mailman/listinfo/computer-go/
> >>
> > _______________________________________________
> > computer-go mailing list
> > computer-go at computer-go.org
> > http://www.computer-go.org/mailman/listinfo/computer-go/
>
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>