Thanks a lot to all who replied!! I'll have to limit the number of simultaneous users anyways, and while doing so dedicating one gnugo process to each game seems to be the best idea.
>From twogtp.py it's not clear to me how is the long-run gnugo process stopped - does it rely on some specific game-ending command, or is it just killed when the python process running the twogtp script dies? I guess for a game-server I'll need to manage timeout explicitly, and send some GTP command myself in case the human player is idle for some period of time. Sorin On Fri, Dec 5, 2008 at 11:49 PM, Arend Bayer <[EMAIL PROTECTED]> wrote: > > 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 >
_______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
