Author: Robert Hyatt
Date: 07:05:10 10/30/98
Go up one level in this thread
On October 29, 1998 at 13:36:30, Roberto Waldteufel wrote: > >On October 29, 1998 at 06:34:05, Peter Fendrich wrote: > >>On October 28, 1998 at 20:02:36, Roberto Waldteufel wrote: >> >> >>>>I suppose that you have four routines to update your bitboards. Something like >>>>CutAtttacksTo, ExpandAttacksTo, DeleteAttacksFrom and InsertAttacksFrom. If you >>>>used rotated bitboards to get all the bits from a certain square you could OR >>>>that into your atkfr table but you still had to loop through all these bits in >>>>order to update the atkto table. So I agree, it would probably be an overkill... >>> >>>Well, I do something similar, but not quite like you say here. Remember that >>>when a square is vacated, some of the attack maps for other pieces may change >>>due to "discovered" attacks, so all the rays through that square need to be >>>extended, whereas when a square that was empty becomes occupied, it is necessary >>>to do the reverse and chop off any rays passing through the square. >> >>That's the meaning of CutAtttacksTo(sq), ExpandAttacksTo(sq) >> >>>However, I use a nice little trick, only updating these changes when >necessary. Thus when a >>>capture takes place, only the from square needs to have its rays adjusted. >Also, >>>because I generate captures in MVV/LVA order, I often have a situation where I >>>try several captures with the same to-square. In this case I don't have to do >>>the ray adjustments. >>> >>>I use these functions: >>> >>> Putman places a given man of a given side to a previously empty square. >>> >>> Cutman removes a piece from a square, making that square empty. >>> >>> Repman replaces a man on a given square with some givenm other man of the same >>>side (no ray adjustments) >>> >>> Chngman replaces a man on a given square with some given other man of the >>>other side (no ray adjustments) >> >>The result will be same I think: When I made a move i called those funktions I >>mentioned above. >>When it was a capture move I didn't have to call CutAtttacksTo(To-sq). >> >>>All the bitboard updating is done in assembler, and runs quite quickly, but >when >>>I first coded this it was very tricky to get it just right. The pentium's bsf >>>and bsr instructions are very handy for this. >>> >>>I also have found that the evaluations are a problem, since my currant >>>evaluation function (also in assembler) makes very heavy use of the attack >>>tables. The fact that the tables' utility is so diverse makes it very difficult >>>to quantify and weigh up against the overhead of continually updating them. >>> >>>Best wishes' >>>Roberto >>> >>>> >>>>//Peter >> >>One idea is to keep the atkto table and use rotated bitboards instead of the >>atkfr table. One table less to update. I never found out a clever way of doing >>this however. The best part with the rotated bitboards is that the "UnMake Move" >>doesn't have to update bitboards at all! In your current approach these atk >>tables has to be updated 'backwards'. >>By keeping the atkto table the unmake function seems to be almost as costly as >>before even if the atkfr is replaced by rotated bitboards. >> >>//Peter > >I don't understand why unmake move does not need to update the rotated >bitboards, unless do you pass them as parameters when recursing to the next ply? >(is this more efficient than global bitboards?) Otherwise, you have to do four >masking steps whenever the occupancy of a square changes, which will happen when >unmaking moves, sometimes for the destination square, and always for the source >square. > >I like the idea of only maintaining one set of atkto tables, but in practice >these are what take most of the time at present. The atkfr tables are much >faster to update, at least the way I do it they are anyway. So, as you say, this >may not really be worth much of a saving. > >Best wishes, >Roberto Actually the savings is significant. Early crafty versions used a non-rotated bitmap scheme and incrementally updated the attacks_to[] and attacks_from[] bitmap arrays for all occupied squares. Over several months this was optimized quite a bit. But you *still* end up updating attack bitmaps that you never use since the q-search doesn't need *all* of them. Using rotated bitmaps does mean computing the attacks_from[] is slightly more expensive, but when you factor out the updating for non-rotated bitmaps, this is still a good bit faster. attacks_to[] is much slower to compute with rotated bitmaps since we don't keep it incrementally updated. But you learn how to get along without that except for a few key places, so that it is *still* faster overall when using rotated compute-on-the-fly attack bitmaps... Bob
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.