Post
by BB+ » Mon Jun 21, 2010 7:14 am
Here is my (opinionated) take on Rybka and IPPOLIT over the past year(s).
First, Rybka is a full-time project, while with IPPOLIT one can only guess (I personally think it might be one main guy who writes in his free time, with maybe one or two other trusted confidants). On the other hand, VR spent a lot of time with the cluster instead of just with Rybka 4. [On the third hand, I'm not quite sure one can really be a "fulltime" chess programmer, spending 30+ hours per week actually doing strength improvements, as the time to test ideas usually outweighs the time spent to implement them]. Over May 2009-2010, it seems that IPPOLIT cleaned up their code a lot (though my guess is that some of this was already done by May 2009, and the IPP_ENG.C was the end-result of some pre-processing), added pondering, multipv, SMP, RobboBases, a randomiser, and fixed various bugs. It also spawned "me-too" versions that had various slight improvements (like time management), and/or allowed more user control via UCI options. The latest version claims to have gained 10 rating points at bullet (I see new "LMR" variables floating around the code, so maybe that is from where this purported gain comes).
The final chapter on Rybka 4 is not written yet, as there might be an update. Here is my idea of what has gone bad, which might be completely wrong. I describe my thought process. Many people report large (25+ ELO) gains from fiddling with the time management of Rybka 4, especially the "TC Max Move" variable. This seems odd to me, as usually if you set a MaxTime variable to anything within reasonable bounds, the change is not that much. However, if you are constantly hitting the "Max" time (more than just a few times per game), this could explain such large variances, especially when you "finish the ply" in time management like Rybka does... There is also the "large-branching" factor that many people have observed. So: my guess is that the "large-branching" is occurring in games, but that it is "hidden" because the "Max Move" variable tourniquets the branching before it explodes too much. If this is correct (and I certainly take it with a grain of salt), then fixing the large-branching problem (if indeed VR decides this a really a "bug") would also allow a more sensible "Max Move" setting. As I noted it a couple of other places, testing with "go movetime" could be better to determine the true "analysis strength" of programmes, as time management would then not be a factor.
Hmm, I guess this post doesn't exactly fit the thread of "Facts only", but so be it.
