Re: Réf . : Re: [Bug-gnubg] Tutor/Analysis

[Joern Thyssen]

On Fri, Oct 03, 2003 at 12:30:28PM +0200, address@hidden wrote
> 
> 
> >> Why that ?! GNUbg has necessarily done all the analysis while
> >> playing ... isn't it stored somewhere ?!
> >
> >No :-)
> 
> 
> What a waste !! Can you foresee my next request ? :))
> 
> [Just in case :
>  to store it somewhere and use it when analyzing the match,
>  if the play level and the analysis level agree].
> 
> I don't mind waiting a bit during each move, but waiting 10mins
> at the end of a match really kills me.

It has been on the TODO list for quite a while. Bringing it forward
again doesn't help :-)

> 
> >This can been suggested multiple times, and the answer is still that
> >"background" analysis is very complicated to implement, so odds are that
> >you'll *never* see this in gnubg.
> 
> Don't be so negative, we just need the right person :

The reason why I sound negative is that you're person number 10 to
suggest this. The answer every time has been: "This is so complicated
that you won't see it in gnubg anytime soon/ever". The reply by the
requestor has often been: "No, that can't be. This is so trivial, you
just need to to use this-or-that library/algorithm". My answer is: No,
this *is* very complicated. Every shared structure in gnubg must be
protected by a lock/mutex: the evaluation cache, the move list, etc etc.
There are millions of other issues: what happens if the user changes the
match equity table while the background analysis is running? What
happens if the user requests a "hint" while the background analysis is
running? 

One of the problems is that gnubg was never designed for multi-threading,
so a lot of it has to be rewritten. Just ask Olivier Baur about his
problems....

> 
> (1) thread guru
> (2) mastering linux, unix (all flavours) and WinXX
> (3) knowing everything about GTK and GUI in general
> (4) high documentation skills
> (5) supremo level (2000+) in backgammon will be a plus
(6) the to read, understand, and find his way around the 100,000+ lines of 
    code in gnubg
(7) the ability to rewrite all the code to be thread safe
    (this has partly been done by Olivier Baur)
(8) the ability to make GTK+ run in a multi threaded environment
    (Olivier Baur has some experience on this)

I guess you see how non-trivial this is! 

I think there are people in the development team to cover all (1)-(8),
but I don't think that there is one person covering them all.  With
people sitting in 10 different countries it's very hard to coordinate
such an effort.

The work by Olivier evolves around using gnubg on multi-processor
machines or in clusters. Personally I think this is much more
interesting than saving 10 minutes after playing a match.  You can just
start a new instance of gnubg and analyse the match while playing a new
match in the first instance. People using operating systems that allow
the programs themselves to control CPU time should issue the command
"set priority idle" in the second instance of gnubg to avoid their
system being brought to it's knees.

Jørn

pgpQsq5FVkpK5.pgp
Description: PGP signature