[Computer-go] effectiveness of transposition tables for go

Petr Baudis pasky at ucw.cz
Mon May 10 18:30:03 PDT 2010


On Mon, May 10, 2010 at 02:26:18PM -1000, Mark Boon wrote:
> >Don't you remember that Mogo had an issue with memory?
> 
> Yes, I remember. Like I said, I've seen people write about memory
> issues. But I just never understood where they came from. I'd like to
> understand, as I don't see how they could follow from keeping the
> nodes.

It seems memory issues start to pop up when you try to support very long
thinking times (minutes per move) or massive influx of simulations
(cluster computation). Pachi was originally extremely wasteful about
memory (malloc()ating each single node separately!) and it never really
mattered (unless you wanted to play very slow on 19x19) until Jean-loup
had to fix that in order to handle many-core machines sensibly - tens
of cores simulating in parallel will grow the tree very quickly. ;-)

> On Mon, May 10, 2010 at 1:37 PM, Don Dailey <dailey.don at gmail.com> wrote:
> If it was 2 or 3 min. for 19x19 it's a little easier to understand.
> It's still a lot longer than you can think on average.

Pachi is used to playing with 25/5:00 timesetting on KGS and commonly
runs out of its reserved 3GiB of memory on the final moves in the period
when it can easily spend 30s on a single move _and_ gets simulations
from 8 i7 cores. Usually when it is going through a narrow sequence
where major portion of the tree get reused in the following moves

> Plus, for 19x19
> you cannot do playouts nearly as fast as on 9x9. The 5 times longer
> game-length gets compounded by the need for heavier playouts.

>From my experience, the tree still grows noticeably quicker on 19x19,
the much larger node expansion rate seems to quite outweight our heavy
playouts cost just yet.

-- 
				Petr "Pasky" Baudis
When I feel like exercising, I just lie down until the feeling
goes away.  -- xed_over



More information about the Computer-go mailing list