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