On Thu, Dec 4, 2008 at 2:54 PM, Terry McIntyre <[EMAIL PROTECTED]>wrote:
> On Thu, Dec 4, 2008 at 1:37 PM, Sorin Gherman <[EMAIL PROTECTED]> wrote: > > I see, that makes a lot of sense, thanks again! As the game progresses, > the > > load time for each new move will increase, I assume. > > So I agree now, keeping one process per game would benefit the CPU usage. > > Problem is that currently I don't have the notion of a "game" on the > server > > side, but only on the client side. > > Also, there is no clear way to know that a game is over, and kill the > > associated gnugo process, without introducing some time limits for the > user: > > have to close their game after N minutes of inactivity. > > Currently, without time limits, a user can, say take a lunch break and > > resume their game afterwards. > > Perhaps you can implement some sort of caching strategy; if the game > is still active ( a move made within the last 2 minutes ), keep the > process alive; otherwise, save state to disk until the user returns. > > This gets fairly complex. How many users do you support at one time? > How many users in toto? > 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
