You shouldn't worry about start-up time etc., it is very small compared
to the CPU time used by gnugo for a single move. However, it will save
you quite a bit if you let the same gnugo process play a full game
(without doing any other moves for any other game in between), due to
gnugo's caching.
There are two examples of how to start a gnugo process and set up a
pipe between a python script and gnugo in the gnugo sources:
./interface/gtp_examples/twogtp.py
./regression/breakage2tst.py
You will definitely have to limit the number of simultaneous users,
enabling caching will only save you s.th. like 30%.
Arend
On Thu, Dec 04, 2008 at 03:24:59PM -0800, Sorin Gherman wrote:
> I don't limit the number of simultaneous users - that was next on my "todo"
> list, even in the current implementation, since no matter what solution I
> choose, there should be an upper limit. Currently I would say there are about
> 10 simultaneous users.
>
> Caching strategy: assuming there is a way to keep the gnugo process alive from
> Python (as opposed to just do some "exec" which I do now, asking gnugo for one
> move), that's a very interesting idea, thanks a lot! Sure, can get complex
> quickly, like any caching strategy, but may be well worth the effort.
>
> I wonder though how much overhead is there in rebuilding the whole board from
> scratch relatively speaking, I mean as a % of the whole CPU utilization for
> generating a new move with genmove.