|
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?
|