Re: [gnugo-devel] Parallelizing GNU Go

[Paul Pogonyshev]

Dave Denholm wrote:
> 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.

at least for the main project (gnu go that is, i'm not aware of any forks
yet) my opinion is that we should stick to portable, reasonably fast (must
run on medium-class machines) and of course as strong as possible user-
oriented program. this is of course only my point of view but it seems
to me that the whole gnu project is about common solutions, i.e. i doubt
it will ever include nuclear-explosion-evaluation-program-that-runs-on-
room-sized-clusters-only.

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

i believe it's mostly memory-bound, but who knows :) hyper-threading might
become a good reason for going threaded but it is not at the moment certainly.

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

encapsulating is a great concept, but i'd rather not use it with the engine.
i don't see any reasons to have several engine states at the same time.
besides, omitting that pointer saves us characters in source files,
considerable amount of time (assuming we would have to pass it everywhere
around via stack) and, finally, makes the code more readable (to me at
least ;).

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

i must note that it was gnu go that made me aware of free software at all
(yes, i had heard about linux and sourceforge, but never paid attention
and didn't even know about the gnu project and RMS). if only to participate
in development more productively (a strong word, not that i'm really that
productive ;) i switched from windows to gnu/linux. but since then i has
become a real worshiper of free software and i admire unix-like system
elegancy.

so i wholly agree that we are not in position (and we shouldn't be) to
prevent anyone from altering and modifying gnu go code or even start a
forked project. it could even make the things more interesting. i just
wanted to say that i'd rather not see threads in _this_ project, not
that i was against changing the sources that way or creating a separate
threaded project.

Paul