[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Bug-gnubg] Multithread (silly) question ?

From: Massimiliano Maini
Subject: RE: [Bug-gnubg] Multithread (silly) question ?
Date: Thu, 8 Mar 2007 14:49:30 +0100

"Jonathan Kinsey" <address@hidden> wrote on 08/03/2007 12:28:44:

> >From: Massimiliano Maini <address@hidden>
> >
> >with the recend multi-thread code and multi-core hardawre, what sould run
> >faster than before ? Just game/match analysis and rollouts or even
> >evaluation ?
> >
> >In other words, gnubg will run game/match analysis and rollouts faster,
> >but will
> >it play faster ? Will the tutor be faster ?
> >
> >My understanding (from previous posts) is that the answer is no, but since
> >I'd
> >like the answer to be yes, I want to be sure :))
> The answer is no.  I went for the quick approach of splitting up big tasks
> (moves in a game and trials in the rollout), the other idea of
> multi-threading the evaluations sounds great (as everything would be
> quicker), it's just a whole lot more complicated/likely not to work.
> I could take a look when I've a got a sec, I've got a feeling that they
> might use eval functions that are already used in the rollouts, so it might
> not be easy.

I'm just rambling here, but when gnubg evaluates moves, it computes
all the valid moves, then evaluates all of them at 0ply, then somehow
selects the ones to evaluate at higher ply.

Multi-threading the neural net may be not so interesting since it is
already very fast (overhead may be a killer), but running multiple
nets in parallel should gain a lot. A single function could receive
the list of moves to be evaluated and dispatch them to the N threads.

I don't know if that's what Chrsitian meant when he said  :

> Perhaps it would be possible to split the task on the movefilter
> level. It should be easier than on the eval level.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]