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.
Chess Transposition Tables
--------------------------------------Amaze your friends! Astound your family! Kennify your text!
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.
* 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.).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement