Re: [gnugo-devel] Parallelizing GNU Go

[Evan Berggren Daniel]

I think the major use for a parallelized GNU Go is for tournament play.
Alternately, I think we could get several computers working together
across the net for play on nngs, if that can be made to work.

I think the way to look at parallelizing is like any other speed up, and
evaluate maintainability, etc in that context.

I think a clustered version is most interesting, since clusters are easier
to get ahold of than multi-cpu machines.

Evan Daniel

On Thu, 3 Apr 2003, Paul Pogonyshev wrote:

> just a question: do we really need it to be paralleled?
>
> personally i won't say so, because:
>
> - gnu go is a user-targeted program that is not supposed to be run
>   on supercomputers. it must be able to run on all but really outdated
>   machines in fact. so, paralleling it is a bit off goal.
>
> - gnu go is very time consuming, meaning that speed is our second
>   priority after engine strength. making it threaded would certainly
>   slow it down on all machines but that little fraction enjoying
>   multiple cpus.
>
> - making it heavily threaded would mean hell of changes in code, worse
>   maintainability (hi Gunnar ;), headache of crawling-out-of-nowhere-bugs
>   and very difficult debugging.
>
> - it will just make coding more difficult (e.g. i assume we'll have to
>   clone board[] and many other static arrays and variables for every
>   thread).
>
> so, if you ask me, i'm against this. forking gnugo is another deal since
> it doesn't touch the engine much (if at all). it's not very portable, but
> i don't think you'll find many users out there who are eager to have
> paralleled gnu go at all.
>
> just my 2 cents.
>
> Paul
>
>
>
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnugo-devel
>
>