Author: Sune Fischer
Date: 10:36:59 08/20/03
Go up one level in this thread
On August 20, 2003 at 13:05:17, Christophe Theron wrote: >>Copying a struct does take time, and it can easily be pinpointed. Saving and >>restoring and unupdating also takes time, but is harder to identify. Especially >>since the stress on code cache and branch prediction don't show up in a run time >>profile. >> >>... Johan > > > >I'm not surprised by Bob results on this issue, as Crafty has a *lot* of things >to save/restore, and all of them are rather big structures. > >In a non-bitboard program like Chess Tiger, saving/restoring is probably faster. >At least it is in Chess Tiger. > >I do not know if you are using bitboards in The King. Do you? > >Actually I'm using a mix of undo and restore: I do not save the chessboard >itself because undoing a move involves very few read/write operations. So I undo >the move "manually" on the chessboard but restore with a memcpy a single >structure that holds the rest of the chessboard and a part of the search state. >I seem to remember that this structure is less than 40 bytes big, so restoring >it is really no problem, and as you pointed out most of the time the data to be >restored still lies in the L1 cache. > >In any case I cannot imagine that restoring the hash key for the current >position from memory could be slower than computing it again by undoing a >sequence of XORs (at least 2) on a 64 bits integer... Actually I think you are doing the same as Crafty, Crafty is using a mix of copying and undoing as well. The expensive stuff, hash key and rotated boards are copied back. The piece bitboards don't all need accessing, perhaps just 1 or 2 out of ~20, so for this undoing is faster. -S. > Christophe
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.