Re: [gnugo-devel] How to compile gnugo as a shared library?

[Sorin Gherman]

On Thu, Dec 4, 2008 at 2:54 PM, Terry McIntyre <address@hidden> wrote:

On Thu, Dec 4, 2008 at 1:37 PM, Sorin Gherman <address@hidden> 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.