[computer-go] Effective Go Library v0.101

[Łukasz Lew]

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/
>