Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Why have a UnMakeMove or UndoMove function (not as stupid as it soun

Author: Christophe Theron

Date: 21:48:09 02/24/03

Go up one level in this thread


On February 24, 2003 at 13:40:59, Andrew Dados wrote:

>On February 24, 2003 at 11:41:03, Albert Bertilsson wrote:
>
>>Hello!
>>
>>I've done some testing and thinking and I ask the following question:
>>Why have an UnMakeMove or UndoMove function?
>>
>>When testing with Sharper I found that actually copying the board and then
>>calling DoMove on the new board was faster than using DoMove() / UndoMove() on
>>the same board.
>>
>>My Board size is 376 bytes, and I figure that will cause a copy function to
>>require some 94 copy instruction (on a 32 bit machine), this will of course also
>>require some sort of condition of when to stop copying and so, but I figure this
>>must be a much easier task than doing branches and testing if it was a capture
>>etc. and updating piece lists.
>>
>>Is this a unique case for me? Have anybody else tried it? What is your board
>>size in bytes? Maybe this only works for me because my board is small (although
>>I certainly don't think it is small).
>>
>>Regards Albert Bertilsson
>
>Once your program reaches decent depth you'll find out that 376 extra bytes per
>depth will eventually blow up cache and slow things down. Probably somewhere
>around 10-12th ply.
>
>-Andrew-



Certainly not, even if you reach 100 plies.

Only the LAST plies are going to be accessed the most often, and only these will
reside in the cache.

When you are at ply depth 100, only the boards of ply depth 97-100 are going to
be copied "often" for example.

The cache is MRU, don't forget it.

So overflowing the cache is not a problem with his approach, unless your cache
is very small.



    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.