Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Is rotating bb's only useful for movegeneration?

Author: Vincent Diepeveen

Date: 11:30:36 12/07/99

Go up one level in this thread


On December 07, 1999 at 10:32:38, Brian Richardson wrote:

>On December 07, 1999 at 08:28:53, Vincent Diepeveen wrote:
>
>>On December 06, 1999 at 15:20:39, Brian Richardson wrote:
>>
>>>On December 06, 1999 at 11:29:56, Bas Hamstra wrote:
>>>
>>>>Hi Bob and other bb experts,
>>>>
>>>>What do you use the rotated bb's for, exactly: only for movegeneration, or also
>>>>for attack detection?
>>>>
>>>>I ask this because I saw in Crafty some code to detect blocking of sliding
>>>>attacks, like I do it. Whith a BlockMask[File][Rank]. I thought the essence of
>>>>the rotated bb's is that you can avoid this block checking, so why this
>>>>block-code in Crafty?
>>>>
>>>>
>>>>
>>>>Regards,
>>>>Bas Hamstra.
>>>
>>>I had done some informal testing of rotated vs non for move generation with
>>>Crafty and found non to be slightly faster (<10%) for move generation (I suspect
>>>due to less overhead updating).  However, for attack detection and eval
>>>functions, I think rotated more than makes up for the additional complexity...
>>>
>>>Nonetheless, I do not use rotated in my program for simplicity (at this stage of
>>>development, I prefer KISS to maximum performance).
>>>
>>>An easy test would be rotated vs non in Crafty's Attacked() function.
>>>Differences probably vary significantly by game stage and mobility.
>>
>>Can you please post at what outdated hardware you tested that?
>
>Tested on PII 266, 512K cache, 64MB back in Sept 98 under Win95, MSVC 5.  Cut'n
>paste Crafty move generation, stripped hashing updates, but left incremental
>material updates.  Tried with and without rotated bitmaps.  This was before
>vcinline.h !  Certainly not a "fair" comparison, but I was only looking for
>"big" differences (turned out much faster than gnuchess pointer method, and my
>much older method, which I abandonded).  Tested with perft timing using starting
>position, which is another "problem".  I am not a bitmap guru.  Currently my
>program only does about 1M per second (with vcinline.h), so perft to depth 6
>takes about 130 secs, which is about the same as Crafty 16.18  Again, for my
>purposes this informal testing was adequate, since my program spends about 50%
>of the time in eval().  I am sure well-done rotated bitmaps are a significant
>improvement, but I am postponing rotated bitmaps until after the eval() gets
>smarter, and pondering, books, learning and EGTBs get implemented.

this is weird. please retest with a new crafty version.
it's faster here than with the SMALL thing.




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.