4 ms·
The last time anyone did a project like this (ChessBrain), they were very careful not to give any meaningful performance results. I can tell you why: latency is
by gcp 15y ago
The last time anyone did a project like this (ChessBrain), they were very careful not to give any meaningful performance results. I can tell you why: latency is critical in these applications, and APHID scalability is terrible once you go over a few nodes. Scaling YBWC is even harder, more latency-sensitive, and responds terribly if you can't effectively share memory over multiple nodes.
Using a lot of CPUs to generate heat is easy. Using them to generate good chess moves is another matter.
How about having your "2000-node chess program" play against the strongest GPL-ed chess program (Stockfish 2.1), running on a fast 4-core box?
If you can win a match of meaningful length against that, I might be interested.
Until you get there, this is a nice exercise in combining technology to achieve meaningless results.
- sylvinus 15y agoIndeed. APHID doesn't scale well and it will be hard to distribute YBWC efficiently but we think we have a shot at it with very short compute windows for each worker. We may also look at other algorithms but currently a variation of YBWC seems the most promising. In terms of strength, we'll add the UCI protocol to be able to run games against other engines. We'll see how it performs but we don't expect to beat Stockfish easily, even with a very large number of nodes. That will be part of the experiment and we'll be happy to publish the results. Now, another path to get real performance would be to find a way of using webGL on the workers. Folding@home has proven it's sometimes 10x more efficient than using CPUs. If we can manage to do that then we might have a shot at being both the largest and strongest AI...
- jvandenbroeck 15y agoYou might have a look at Monte Carlo Tree Search & improvements they made on it for game playing. It's easy to parallelize and has had amazing results with Go. You might also combine it with a moves/games database and play variations on these games according to a softmax distribution. (instead of playing random games with classic MCTS) I think this will work much better than tree search but still, I think it will be really hard to beat eg. Stockfish. You got nothing with lots of processor power if you're doing the wrong calculations:)
- sylvinus 15y agoThanks for the pointer! We'll definitely look into it.
- gcp 15y agoFolding@home has proven that embarrassingly parallel problems run well on embarrassingly parallel architectures. Computer chess is not one of those. Forget about using the GPU for chess. Just getting that to work somewhat decently is a huge achievement - which no-one has succeeded in so far. Some people, when they see a problem, think: "We'll use the GPU". Now they have 2 problems.
- sylvinus 15y agoFair point. Though I'll have to get burned trying before being convinced it's that complicated :) However webGL is not in the critical path of the Guinness Record thing, so I'll happily trust you for now!
- 0x12 15y agothis guy might have a hint or two, or maybe you could collaborate if you go that way: http://blog.cudachess.org/ http://blog.cudachess.org/
- evandijk70 15y agoTo show how unlikely it is that it will beat the strongest GPL chess program on modest hardware, a back of the envelope calculation. The program they want to use ranks around 500 elo points lower than the strongest open source program on the same hardware. (source: http://computerchess.org.uk/ccrl/4040/rating_list_all.html http://computerchess.org.uk/ccrl/4040/rating_list_all.html) It is estimated that doubling the speed of the computer adds 50-70 elo points (http://en.wikipedia.org/wiki/Computer_chess http://en.wikipedia.org/wiki/Computer_chess cites David Levy's book how computers play chess.) This means that they will have to achieve anywhere between a 2^7 to a 2^10 speedup over a normal single PC. Once you consider the latency problem described above, it is very unlikely that they can achieve this speed up. To put this problem into context, even on a quad-core a three times speedup is considered pretty good in computer chess.
- sylvinus 15y agoIt is indeed unlikely. But if we can actually get to the point that 2^10 web clients (1024) are as strong as Houdini or Rybka on one high-end hardware, it won't be that hard to double the size of the web grid a couple more times. As you pointed out, the main challenge is scaling efficiently, and not getting a poor speedup even with that many workers (I think we can aim for 60% speedup with YBWC). We hope to have an edge here with Node.js' I/O performance, but it's still a big challenge (and that's what keeps it interesting ;-)
- gcp 15y ago>I think we can aim for 60% speedup with YBWC Note that most top engines barely get this speedup with 4 cores on an SMP system. I doubt you can get the same efficiency in a distributed system with 2000 cores.
- glinscott 15y agoAs noted on the Garbochess JS page, I didn't estimate the strength of the JS version. It would be much weaker than Garbochess 2.20 on the same hardware. Having a node.js uci adapter would be fun to test this. It will be very difficult to make Javascript competitive with Stockfish, even across 1000 computers. Still, a very cool project!
- beefman 15y agoCritter is stronger than Stockfish http://www.vlasak.biz/critter/ http://www.vlasak.biz/critter/ I think you're being too pessimistic. Even if high playing strength isn't achieved, using JS to do @home projects is huge, and putting it together in 48 hours is pretty sweet.
- libraryatnight 15y agoYea, no need to be a negative Nancy. This is a super cool achievement and I'm really happy for these dudes. It's a neat idea and a lot of fun.