Re: [gnugo-devel] Parallelizing GNU Go

[Dave Denholm]

Paul Pogonyshev <address@hidden> writes:

> 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.
> 

This has come up before. I asked (when I still had time to help out in
development) where we were headed...

 - do we want a program for users to play interactively on their own pc

 - do we want, say, a robot on nngs, such that it can use a small number
of computers in parallel to be a bit stronger.

 - do we want to make the worlds strongest go playing program, using
as many cpus, with as much memory as possible.

As you say, the design tradeoffs are possibly not compatible.


> - 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.
> 

Depending on what happens with hyper-threading...
Also depends on whether gnugo is cpmpute bound or memory bound.


> - 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.
> 

I agree. In my (professional, FWIW) experience, it is very very hard
to write correct multi-threaded code. Notwithstanding the problem of
doing it portably.

> - 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).
> 

Would possibly be a good thing anyway to get rid of all globals, and
have state attached to an environment pointer.


> 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.
> 

Well... for what it's worth, one of my own motivations when I started
helping on this project was to get a free engine out there. I didn't care
if gnugo ended up particularly strong, but it was a free base onto which
other people could build new engines. That's presumably what happened with
gnu chess. I hope that eventually, there will be a strong, free, go playing
program.

So from that view, it is a good thing to take the gnugo sources and
parallelise it for a 64-cpu machine. No reason to fold the changes
back into the main code base. The whole point of the GPL is that
anyone can take the sources of gnugo and build a rival. With, I hope,
everyone's blessing.

Some things might be learned that can be fed back in. It might be a disaster.
It's something interesting to try...


Eg xemacs was spun off from emacs when RMS refused to go in a direction
others wanted to go.

Eg egcs spun off from gcc when the gcc maintainers seemed to slow down.
Then egcs "won" and became the supported gnu c compiler. (If I remember
my history corretly)


dd
-- 
address@hidden          http://www.insignia.com