Wow. I really dig this idea of sharded / modular network problem solvers. It would be interesting to take it a step further and let the solvers themselves negotiate their own distribution over time, CPU use, etc. - e.g. replicate all the active solvers on all the clients but allocate chunks of variable size to each depending on which evolves to be the "dominant" solver on any given CPU. You'd need an algorithm to stop Montecarlos from becoming the dominant process everywhere, probably. Montecarlo is notorious for chewing up a processor, but in various applications it often does not need to be run constantly, so the free cycles could be used for something else.
I especially like the idea that this could be applied to anything, not just Go. I did something in this direction a few years ago with an a-life data processing platform that used SOAP to shard problems to groups of machines.
At that point there are two issues, firstly the protocol becomes a bottleneck if you're dealing in large datasets, and secondly if you're dividing something up spatially you still have to aggregate your results. It would be the same if you divided it problematically for Go moves, unless each algorithm could give a "confidence" indicator that could be used reliably so that the master engine would not have to montecarlo each result set. That could be done if the montecarlo was moved to the sub-servers to test their own moves before sending the moves back complete with percentage wins for direct comparison in the master engine. It would chew up a lot more cycles and mean more machines, but it would remove the post-processing bottleneck.
A list of 10 moves from 30 different machines, even using a heavy-weight protocol like SOAP, would be nearly instantaneous. I would favour a light-weight format such as JSON, though. For other applications, I agree, network bandwidth would be a possible bottleneck.
My initial idea was to have each engine return ten moves, in sequence, with the first move being most important. The moves need not be delivered simultaneously. The Master selects the lowest scoring move that was picked by multiple engines. Other ideas include weighting (the fuseki engine's input is not very important in chuban or yose), and imperative moves (death engine forces a play to save a 30 point group).
The Master would send requests for moves by submitting a board position and whose turn to play.
What I really like about the idea, though, is that anyone could develop an engine (in any language) that adheres to the protocol, and add it to the AI network. At any time.
Cool stuff. Do you already have an API for people to write their own solvers -- something that passes a board state and an interface to return ranked choices?
How do you stop people on the network from overranking their own AI's choices (assuming this were an open project)?
I especially like the idea that this could be applied to anything, not just Go. I did something in this direction a few years ago with an a-life data processing platform that used SOAP to shard problems to groups of machines.
At that point there are two issues, firstly the protocol becomes a bottleneck if you're dealing in large datasets, and secondly if you're dividing something up spatially you still have to aggregate your results. It would be the same if you divided it problematically for Go moves, unless each algorithm could give a "confidence" indicator that could be used reliably so that the master engine would not have to montecarlo each result set. That could be done if the montecarlo was moved to the sub-servers to test their own moves before sending the moves back complete with percentage wins for direct comparison in the master engine. It would chew up a lot more cycles and mean more machines, but it would remove the post-processing bottleneck.