It occurs to me that you might wish to ask David Doshay about the
methods used by Sluggo; it is possible that they solved some of the
same problems for different reasons.
On Dec 4, 2008, at 1:37 PM, Sorin Gherman 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.
Sorin
On Thu, Dec 4, 2008 at 12:35 AM, Cai Qiang <[EMAIL PROTECTED]> wrote:
Hi,
Yes, "spawn one process for each game" method averagely will use
more memory than "spawn one process for each move". But if "The
complain from my ISV was about using to much CPU", your current
"spawn one process for each move" uses more CPU:
1. gnugo need to recalculate many info when you lose the
previous state(exit the gnugo) and let it genmove according a give
position
2. the spawn/exit overhead
----- Original Message -----
From: Sorin Gherman
So your approach tries to minimize the number of time we open the
gnugo processes, on the other hand we'll still have the same number
of processes running, at any given time, as simultaneous players are
there, and by keeping them in memory we'll eat up more memory then
in the current approach, with one process opened per move.
The complain from my ISV was about using to much CPU (running too
many gnugo processes at the same time), which I don't think will
change with one gnugo process per player.
Back to my original question: I'm not even sure that the "calling
gnugo as a library from python" works, because the board is a global
variable in gnugo, so if I load the same library just once from the
Python interpreter process, and modify the board from different
Python threads, they'll share and keep modifying the same board
structure, which is not good.
Can anyone comment on multithreaded issues that may occur in the
"using gnugo as a shared library" approach?
_______________________________________________
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
_______________________________________________
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel
