Page 2 of 2
Re: Unifying make/undo and copy-make
Posted: Tue Dec 22, 2015 7:34 pm
by Rein Halbersma
Bloodbane wrote:jdart wrote:I don't know of any strong program that uses copy-make.
--Jon
The only engine I know that uses copy-make and is even near the top engines is Hakkapeliitta. According to my notes copy-make was actually slightly faster than make-unmake.
As far as I have been able to find on this forum, all engines written by Don Dailey have been copy-make, all the way back from the days of CilkChess right up to Komodo.
Re: Unifying make/undo and copy-make
Posted: Tue Dec 22, 2015 8:43 pm
by Fabio Gobbato
My engine is not very strong but I use copy/make too. My board structure stay in 56 bytes, the copy is very fast.
Re: Unifying make/undo and copy-make
Posted: Tue Dec 22, 2015 9:26 pm
by Aleks Peshkov
My attack table size is 256 bytes, but it would be obviously very slow to unmake the incremental changes. So I copy the whole ~400 bytes position.
My program still at perft stage but it is not slow with my attack tables. It is comparable to the fastest known performers.
Re: Unifying make/undo and copy-make
Posted: Wed Dec 23, 2015 12:20 am
by lucasart
Rein Halbersma wrote:Bloodbane wrote:jdart wrote:I don't know of any strong program that uses copy-make.
--Jon
The only engine I know that uses copy-make and is even near the top engines is Hakkapeliitta. According to my notes copy-make was actually slightly faster than make-unmake.
As far as I have been able to find on this forum, all engines written by Don Dailey have been copy-make, all the way back from the days of CilkChess right up to Komodo.
I've done both, and I much prefer copy-make. Reason is that (if done correctly), the speed is about the same, and is a negligible part of your profiling result on a fully blown program anyway (where search and eval count much more). And copy-make is much more elegant. You can make your Position class "const" everywhere it should be "const". You needn't have an unmake function. And you avoid a whole bunch of possible bugs, simply, by not having an undo function. By definition, you cannot propagate bugs. You can really debug step by step, until you find the node where your movegen or make code went wrong. You cannot have path dependant bugs that a nightmarish to find.
Here's my latest copy-make. It was an attempt to rewrite DiscoCheck with SMP, but I got bored and gave up half way:
https://github.com/lucasart/Demolito
copy-make was really the correct design decision (among other things).