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. _______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
