Author: Robert Hyatt
Date: 11:27:57 08/20/03
Go up one level in this thread
On August 20, 2003 at 03:59:38, Johan de Koning wrote: >On August 19, 2003 at 22:11:14, Robert Hyatt wrote: > >>On August 19, 2003 at 20:06:58, Mathieu Pagé wrote: >> >>>Hi, >>> >>>The fact: >>> >>>I have this question i read at some place that it is faster to unmake a move >>>than to save the state of the game before moving then restoring it when we want >>>to unmake the move. >>> >>>For the moment my engines did not implement unmake() (it is still buggy). >>> >>>My thougth: >>> >>>Since bitboard computation are slow (on 32 hardware) i think that it can be >>>slower to unmake the move than to save the state. I friend of me that is lot >>>better than me at optimizing code also think that. >>> >>>My questions: >>> >>>Are you all using unmake() function or there is some of you that found that >>>saving the state is better ? >> >> >> >>read the comments from Crafty in main.c. I started out using what is >>commonly called "copy/make" as that worked well in Cray Blitz. But it >>didn't work well in the PC. The PC has very limited memory bandwidth, >>when you compare the speed of memory to the speed/demands of current >>processors. If you keep the board in cache, and update it there, it is >>more efficient than to copy it from real memory to real memory... > >I hate to play Vincent here, but real memory is not an issue. > >If you manage to keep the deepest few plies worth of position structs in L1 >cache, then bandwith is pretty decent on the PC. And it has been ever since them >PCs were endowed with cache. Sure, but look at what happens. You copy a couple of hundred bytes. You update it _once_. Then you copy it again for the next ply. And so on. Not only are you not re-using what you moved around early, you are displacing good stuff from the cache as well. I'm not really guessing here. I did it both ways. My bitmap stuff was, at the time, something like 168 bytes. When I got rid of copy/make and went to make/unmake, I gained over 25% in raw speed, because _all_ of the bitmaps sit in cache and stay there. > >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. I discovered the problem simply by trying the make/unmake after someone else suggested that it might be faster. When I did it, it was a lot faster, although it took a lot of debugging. It's much easier to just decrement a pointer/ subscript than it is to unmake everything correctly... > >... Johan
This page took 0.01 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.