Heiko Mikala wrote:
It may be a big disappointment to many, but really, there isn't much to learn from Strelkas sources at least regarding the search techniques and there surely is no secret revealed. All the techniques used in Strelka are well known and known for years. Things like Nullmove with R=3, Nullmove verification with R=4 (not 5, because in reality it's depth-1-R, giving depth-5), futility pruning, late move reduction, "delta" pruning and so on.
Strelka is clearly based on Fruit, which can be seen on the first glance by everyone who has looked into the Fruit 2.1 sources. The search is very similar, many functions and variables still using the same name, and it's following the same strict (and very good and successfull) principles that Fruit was following, but taken even further into the extreme.
Namely:
No selectivity in PV-nodes
No hashtable values being used in PV-nodes
Full extensions in PV-nodes
Full selectivity in other nodes
Full hashtable use in other nodes
No extensions in other nodes
With the only exception being the check extension, which is being used everywhere.
Fruits search has a very clear and unique fingerprint, which you can find exactly in Strelka.
Even more extreme than the original Fruit is the fact, that in Strelka the search functions have been split up even more into different functions - one function for every possible situation (like root-search, pv-search, full-search (all other than pv-nodes), check-search, quiescence-search, quiescence-check-search). Maybe a good idea, because it makes things a bit easier in some situations.
But every experienced chess programmer can read and understand Strelkas search functions within minutes - and will discover, that there is nothing new in it.
What makes Strelka strong is the same recipe, that made Fruit strong. What makes Strelka stronger than the first Fruits may be a better and clever combination of existing, well-known techniques and aggressive selectivity (but also using well known techniques with adjusted parameters). And maybe some things in the evaluation functions. But on the other hand, the eval of Fruit 2.1 was very strong already, and far from being simple (some things were split over some different source files, which some may not have realized).
My appeal to all of you:
Please do not in advance discredit all chess programmers, who will release new, stronger versions or new strong programs in the future by claiming they are all based on Strelka/Rybka. There really is no secret revealed in Strelka.
You may have noticed that there are close to zero discussions about the Strelka source in the programmers section. The reason, I'm very sure about that, is, that no one found something spectacular new in the sources.
Kind regards,
Heiko
Disclaimer:
With all this I do not judge, if Jury has disassembled Rybka beta or not. I truly admire Vas Rajlichs work with Rybka, which is great program, and which I have bought myself and enjoy to use.
Hi Heiko,
nice summary. Yes, you get some ideas after a few minutes studying Strelka source. It is compact and easy to inspect and to debug. Of course, if that should be Rybka 1 - I am very disappointed not to find some magic bitboard tricks with progressive kogge-stone mobility and whatever else. The pawn-shelter stuff - mapping 12 pawns per side and three neighboring files is quite clever and efficient - despite I would prefer mask/mul/shift nowadays instead of the shift/and/or orgy - but it don't cares due to pawn-hashing anyway. The idea with this nice 2*3*3... factors to index material imbalance tables was also new to me.
I mean a chess program is more than the sum of its components. While each component is not entirely new, the art is to make all parts fit together and to have a smooth and steady evaluation (1. fruit clause) and a stable and efficient search (2. fruit clause). How things are pruned aggressively - null-move and verification search. A combination of "small" implementation details, which determine the shape of the search tree.
Otherwise with a program like mine, containing about 10 times more source code - one chess programmers life is probably too short to perfectly weight and tune all the evaluation and search heuristic aspects and to get all the obscure bugs - not to mention all ideas one likes to try
Cheers,
Gerd