Author: Robert Hyatt
Date: 08:31:08 08/21/03
Go up one level in this thread
On August 21, 2003 at 05:54:53, Bo Persson wrote: >On August 20, 2003 at 19:45:52, Sune Fischer wrote: > >>On August 20, 2003 at 06:15:14, Bo Persson wrote: >> >>>On August 20, 2003 at 05:28:59, Omid David Tabibi 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... >>>>> >>>>>> >>>>>>In the case that unmake is better. by wich factor ? >>>>> >>>>> >>>>> >>>>>For me, just faster. Not 300% or any such number, but at least 25% if >>>>>not more. >>>>> >>>>> >>>> >>>>Up until now almost all my data was global, updated in make_move and takeback. >>>>However, the more data structures I add, the more costly takeback becomes. Now >>>>I'm trying to dynamically update my attack tables in make_move, which is a very >>>>costly operation. Even though the attack tablea are about 256 bytes, I think >>>>copying them will be far cheaper than resotorig in take_back. >>>> >>>>So, it seems that one should experiment with each piece of data to find out >>>>whether resotring in takeback is cheaper than copying the structure. >>>> >>> >>>It all depends on the size of you data. Bob has a lot of bitmaps, most of which >>>do not change during a single move. Copying knight and bishop maps during a pawn >>>move seems like overdoing it. >>> >>>Late in the game they might even be empty and can be allowed to drop out of the >>>cache. >> >>Probably not, since they would still be a part of move generation and some eval >>terms. > >Could be. > >> >>I don't see an efficient way of rooting out empty boards entirely, and that is >>unfortunate since it is pretty common for a large part of the game to be played >>without all types of pieces. > >I was thinking more about how silly it is to copy the empty bitboards for each >ply. If you update the boards that are active, they will stay in the cache. >Those that are not used might drop out, unless they are copied once every micro >second. > That is a reasonable rate for a program that searches 1M nodes per second. I'm going at 2.4M so make that about once every 400 nanoseconds. :) Suddenly it begins to add up in a big way. :) > >Bo Persson
This page took 0.06 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.