Author: Gerd Isenberg
Date: 16:15:41 12/08/05
Go up one level in this thread
On December 06, 2005 at 09:08:12, Vasik Rajlich wrote:
>On December 05, 2005 at 11:31:03, Gerd Isenberg wrote:
>
>>On December 05, 2005 at 10:49:02, Vasik Rajlich wrote:
>>
>>>On December 05, 2005 at 10:18:43, Gerd Isenberg wrote:
>>>
>>>>On December 05, 2005 at 04:44:36, Vasik Rajlich wrote:
>>>>
>>>>>Hello,
>>>>>
>>>>>Well, I am shocked by the speed of the computer chess community. There are now
>>>>>200 requests for Beta versions of Rybka in my mailbox. Many of you made
>>>>>interesting comments and asked all sorts of questions, but at the moment I am
>>>>>really short of time and can't give personal responses to everyone. Some of
>>>>>these questions are answered here.
>>>>>
>>>>>The first piece of good news is that Rybka Beta 1.0 will be available for free
>>>>>download until midnight tonight (Dec 5) on Leo's website. Obviously this targets
>>>>>the more hardcore members of the computer chess community - there are so many
>>>>>here who give their time and share their ideas that I would be embarassed to do
>>>>>anything else.
>>>>>
>>>>>However, I am now working on this project full time, and much as I would like to
>>>>>just concentrate on the technical aspect, the truth is that there is now a
>>>>>business to run. The first commercial release will be as plain as can be - Rybka
>>>>>1.0 standalone UCI engine, no GUI, no book, no copy protection, no engine
>>>>>capability not currently specified in the UCI protocol. The price will be 34
>>>>>Euro. The original target date was Dec 16, but thanks to the incredible speed of
>>>>>the CEGT team this has been moved up to ASAP :) Additional announcements are
>>>>>forthcoming.
>>>>>
>>>>>While I hope that there are some sales of Rybka 1.0, the main goal here is to
>>>>>prepare for a summer 2006 release. If things go as I envision, we'll offer an
>>>>>engine-GUI combo which brings Rybka's chess knowledge to the user and makes
>>>>>chess players wonder how they ever survived without it. Of course, some software
>>>>>developers will tell you that when plans meet reality it is usually reality
>>>>>which wins .. but in my book reality is a seven point underdog :)
>>>>>
>>>>>If any of you are interested in helping the Rybka project succeed, the following
>>>>>are all useful areas of contribution:
>>>>>
>>>>>1) Comments, feedback, and CPU time for beta versions.
>>>>>2) Purchase the full version of Rybka 1.0.
>>>>>3) Get Rybka, and computer chess in general, "out there" into the world of chess
>>>>>- articles, clubs, into the general chess consciousness.
>>>>>
>>>>>This last point is for me the biggest. The computer chess community has
>>>>>tremendous expertise and knowledge, and computer chess is interesting and fun.
>>>>>As programmers, we struggle with the question of what chess knowledge really is
>>>>>in a much deeper and more interesting way than chess players do. A chess player
>>>>>will learn something obvious about positional play, and never really stop to
>>>>>inspect it - because as a human, he doesn't need to. On the other hand, when
>>>>>your program is constantly rebeling against everything you taught it, or plays
>>>>>worse with those last few bits of what you thought were knowledge, you end up
>>>>>asking much tougher questions. So - for those with the ability and interest,
>>>>>let's get out there and spread the word.
>>>>>
>>>>>I am also looking for a few people who will collaborate more closely on the
>>>>>project. There are the usual computer chess things (opening book, tournament
>>>>>operation, beta testing). In addition, the main event of the next four to six
>>>>>weeks will be the addition of I hope two more software developers to the Rybka
>>>>>team. I have of course a target list from my days as a student and developer,
>>>>>but if you are talented, and interested in the project, please don't hesitate to
>>>>>get in touch with me and we can discuss it further.
>>>>>
>>>>>Happy testing, and best regards,
>>>>>Vas
>>>>
>>>>
>>>>Hi Vas,
>>>>
>>>>wow, what great news - seems your bitboard baby has passed some imaginary
>>>>limits. While Fabien teached us smart search with steady evaluation, your
>>>>approach implies thinking bitboards in knowledge based implementaion of
>>>>evaluation as well as quiescence detection.
>>>>
>>>>Congratulations and a very big success with Rybka!
>>>>
>>>>Gerd
>>>
>>>Hi Gerd,
>>>
>>>to tell the truth, I don't think board representation is all that important. I
>>>flipped a coin my first few weeks of computer chess programming, and it said
>>>bitboards. :)
>>
>>hehe - i don't buy that, Vas ;-)
>>
>>I agree that board representation is not that important ...,
>>but didn't you agree that "thinking bitboards" - aka using setwise expressions -
>>isn't more suitable for a lot of pattern ;-)
>>
>>
>>>
>>>BTW: are there any tricks for speeding up bitboards on 32 bit systems. I go from
>>>166 knps to 104. I was thinking to somehow take advantage of the knowledge that
>>>sometimes, a bitboard truly is two half boards, but it never gave any speed up.
>>>
>>>I mean, instead of:
>>>
>>>for (bb knights = Board.pieces [WhiteKnight]; knights; knights &= 1)
>>>{
>>> unsigned long knight_sq;
>>> _BitScanForward64 (knights, &knight_sq);
>>> ...
>>>}
>>>
>>>something like:
>>>
>>>for (unsigned int i=0; i<2; i ++)
>>>{
>>> for (unsigned int half_knights = (unsigned int *)(Board.pieces [WhiteKnight])
>>>+ i; half_knights; half_knights &= 1)
>>> {
>>> unsigned long knight_sq;
>>> _BitScanForward (half_knights, &knight_sq);
>>> knight_sq += i * 32;
>>> ...
>>> }
>>>}
>>>
>>>This was always slower. (I also tried unrolling it, I guess the loop body is too
>>>big.)
>>>
>>>If you have any suggestions, I would love to hear them ..
>>
>>While it might be possible to gain something while processing two half boards
>>simultaniously, i favour one loop64 approach with some inlined bitscan64
>>function, which might be conditionally compiled for 64-bit and 32-bit or
>>"portable"-mode, e.g. with Matt Taylor's folded De Bruijn multiplication:
>>
>>// some haeder file
>>#ifdef USE_X64_INTRINSICS
>>// precondition: bb not null
>>__forceinline
>>unsigned int bitScan(bb b) {
>> unsigned long sq;
>> _BitScanForward64 (b, &sq);
>> return sq;
>>}
>>#else
>>extern const unsigned int lsz64_tbl[64];
>>
>>// precondition: bb not null
>>// Matt Taylor's folded De Bruijn multiplication
>>__forceinline
>>unsigned int bitScan(bb b) {
>> b ^= (b - 1);
>> unsigned int fold = ((int) b) ^ ((int)(b>>32));
>> return lsz64_tbl[(fold * 0x78291ACF) >> (32-6)];
>>}
>>#endif
>>
>>
>>for (bb knights = Board.pieces [WhiteKnight]; knights; knights &= knights-1)
>>{
>> unsigned int knight_sq = bitScan(knights);
>> ...
>>}
>>
>>// in some c file
>>#ifndef USE_X64_INTRINSICS
>>const unsigned int CACHE_ALIGN lsz64_tbl[64] = {
>> 63,30, 3,32,59,14,11,33,
>> 60,24,50, 9,55,19,21,34,
>> 61,29, 2,53,51,23,41,18,
>> 56,28, 1,43,46,27, 0,35,
>> 62,31,58, 4, 5,49,54, 6,
>> 15,52,12,40, 7,42,45,16,
>> 25,57,48,13,10,39, 8,44,
>> 20,47,38,22,17,37,36,26,
>>};
>>#endif
>>
>>Gerd
>>
>
>Gerd,
>
>thanks! If it's not too much trouble (and you visit this far down the page), can
>you also post this algorithm for __BitScanReverse64 ()?
Oups - i missed your answer somehow.
Lot of traffic these days here...
I currently use this one:
__forceinline
unsigned int bitScanReverse(BitBoard bb)
{
union {
double d;
struct {
unsigned int mantissal : 32;
unsigned int mantissah : 20;
unsigned int exponent : 11;
unsigned int sign : 1;
};
} ud;
ud.d = (double)(bb & ~(bb >> 32));
return ud.exponent - 1023;
}
>
>Also, I see in your pseudocode that the arguments to the native
>_BitScanForward64 () intrinsic are reversed, which makes me curious: did you
>type this code from memory? That's what I would call thinking in bitboards :)
Yes, the _BitScanForward64-one was from memory - Matt's one is tested.
Gerd
>
>Best regards,
>Vas
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.