Re: [gnugo-devel] Parallelizing GNU Go

[Evan Berggren Daniel]

On Fri, 4 Apr 2003, Paul Pogonyshev wrote:

> Evan wrote:
> > If we want GNU Go to perform well on these sorts of platforms, it will
> > have to be multi-threaded.  We don't have to deal with that now, clearly,
> > but why not?  A 64-way system makes a good preview of such computers.
>
> it's very easy: i don't have such a machine and most of us don't. if we
> start solving future problems now, we'll make development tremendously
> slow. besides, we don't want to release gnu go which an average user
> (and average developer) will be able to run after a couple of years only.
>
> Paul

There's no reason we can't make a GNU Go that performs well on both
platforms.  Currently, GNU Go runs on a broad range of machines, and the
performance / strength tradeoff is tunable via the --level option.  I
agree that our first priority should be a strong Go program on desktop
machines, either individually or in small clusters, but making it so that
you can simply run it as gnugo --level 15 --threads 32 would make a lot of
sense.

For a specific answer to your concerns that such code would be
problematic performance-wise:

My current thinking is that the best thing to do would be to parallelize
the owl reading.  do_owl_attack could become a call to
collect_owl_attack_moves followed by try_owl_attack_moves, plus any
support code.  The try_owl_attack_moves would need to be parallelized in
order to make use of multiple threads.  There could be two versions of
this function, one for the single threaded program and one for the
multi-threaded program.  This would be compile time selectable.  The only
other change to the owl code would be a way to abort early if one of the
other threads found an answer.  There would need to be locking around the
persistent caches.  Everything else could be copy-per-thread, and a copy
of the board array could be made as part of passing off the work to a new
thread.  I don't think there would be *any* other changes needed.
Clearly, this is not fully parallel, but it would probably be enough to be
useful, and it can all be easily #define'd out for single threaded mode.

Evan Daniel