Author: Uri Blass
Date: 12:43:44 01/03/03
Go up one level in this thread
On January 03, 2003 at 14:42:19, Dieter Buerssner wrote: >On January 03, 2003 at 13:21:40, Robert Hyatt wrote: > > >>Why not something like this: >> >>rank=to>>3; (now we know the rank and only care if it is zero or seven, and >>it can't be zero for white or seven for black so side to move is not important). >> >>So, you end up with one line: >> >> >>if (to>>3==0 || to>>3==7) gen_promote(); > >Why should this be faster than > >if (to <=7 || to >= 56) > >? > >With some bit fiddling tricks (which I would not suggest), one test will be >enough and also include the side. For example > >if ((((to ^ ~((unsigned)side-1))) & 0x38) == 0x38) > >Note, that this is untested, and probably more clever ideas are possible. It >assumes, that side is 0 for white and 1 for black. Then side-1 will be -1 or 0. >-1 is all bits set in unsigned. Now reverse the bits by not. So for white, the >~((unsigned)side-1)) will be 0. 0x38 is binary 111000 (decimal 56). So, only >when to goes to the 8th rank (56-63), the 111000 bits will be set. And the >binary and gives 0x38. For side = 1, ~((unsigned)side-1)) will be all bits set. >The xor will only set the 111000 bits, when they were cleared before (so to <= >7). If I haven't totally failed until here, the binary and could even be >avoided, by > >if ((to ^ ~((unsigned)side-1)) >= ~7U) > > >Uri, why do you need side? Will you movegenerator generate to to squares >= 56 >for black pawns? > >Regards, >Dieter You are right and I did not need side but in any case special function for white and for black seem to be faster. I already implement some functions instead of my previous functions and it does things faster by almost 5% and the improvement was not finished(after doing something I test to see that I did not generate a new bug). I already defined 3 new special functions to generate quite moves 1)generating white pawn moves 2)generating black pawn moves 3)generating nonpawn moves(no castle). The structure of my gen_push was copied from tscp(the only difference between my gen_push and the gen_push of tscp is different way to give scores for move ordering) and my gen_push got 3 parameters. Now it is faster also because I can allow generating nonpawns moves to get only 2 parameters (bits is always 0 when there is no capture no pawn move and no castle). I see that I do not need Ed's book for optimizing my program and I do it faster even without it. I think to define more function(for example generating pawn move 1 square forward). All of this thanks to Ed idea to prune moves in the qsearch when there is no capture that is good enough to get the score above beta. I found that finding the maximal capture cost significant time for me because I had no different gen_push for captures and for non captures so I did it and continue to other things. I doubt if I will use Ed's idea because there are risks in it for people who do checks in the qsearch(it may be good for crafty) but this idea gave me the push for speed improvement that will probably be more than being 5% faster(I alreasy have more than 4% in the opening position). Uri
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.