Advertisement

Chess Transposition Tables

Started by April 21, 2009 07:01 AM
23 comments, last by DpakoH 15 years, 6 months ago
alvaro: I can't thank you enough. [smile]

I refarctored my move generation into using only one board copy at a time and generation of only legal moves without further validation (it took a lot of time and debugging for this) and my perft tests have improved drastically!!! I am now generating over 750,000 moves per second!! That's more than 10 times faster than before.

As far as searching goes, I am able to search around 180,000 nodes per second... It will probably reduce when I improve my evaluation function and I know that it's still not as fast as the best engines out there, but I am satisfied for the day [grin]

Thanks a lot once again.

PS: Those links you provided helped. Bruce Morland's articles were instrumental in my code refactoring. Thanks...

Edit: DpakoH - Let me just debug these modifications and then you can give it a test once again... I'll let you know when I upload to sourceforge... And my engine will still play badly at the end because the evaluation does not yet distinguish between middlegame and endgame... In fact I have not added any sense of endgame component in the AI. So that still needs to be done.
--------------------------------------Amaze your friends! Astound your family! Kennify your text!
any updates? please keep me notified :)
Advertisement
Getting back on topic of transposition tables... I have greatly improved the performance by optimizing storage of the hashtables. Instead of using Java objects (which take up a lot of space) I'm using a number of arrays of bytes, shorts, etc. in parallel. Surprisingly (or unsurprisingly), this takes 4 times less space. Using arrays combined with my move hashing technique* each entry in the transposition table is taking just 14 bytes! I am currently running Frittle with 4.2 million transpositions (56MB) and it works great!

* Instead of storing the heavy Move object in the hashtable, I generate a 16-bit (actually only 15-bit) unique hash for a move (6 bits for source square, 6 bits for destination square, 3 bits for promotion type).

@DpakoH: I just uploaded relese 0.2: http://frittle.sourceforge.net
This is a HUGE improvement from the earlier version. See the changelog if you are intrested in the stages of development as you said. Adding support for time controls and pondering was really tricky. When using multiple threads, bugs become a way of life.
--------------------------------------Amaze your friends! Astound your family! Kennify your text!
Quote: Original post by Verminox
* Instead of storing the heavy Move object in the hashtable, I generate a 16-bit (actually only 15-bit) unique hash for a move (6 bits for source square, 6 bits for destination square, 3 bits for promotion type).


Yes, that's much better than storing a complicated object. In Ruy-Lopez I actually store the move number as generated by the move-generating function (0 for the first move, 1 for the next one, etc.).

hi there,
i was on a vacation so i didnt have time to test your engine. but today, for tomorrow i will do it. expect feedback anytime soon :)

best,
y.

This topic is closed to new replies.

Advertisement