Author: Bas Hamstra
Date: 04:14:57 04/26/00
Go up one level in this thread
On April 25, 2000 at 13:56:35, Robert Hyatt wrote: >On April 25, 2000 at 09:42:37, Bas Hamstra wrote: > >>On April 25, 2000 at 08:57:10, Robert Hyatt wrote: >> >>>On April 25, 2000 at 01:20:11, Bas Hamstra wrote: >>> >>>>I have some evidence that an unrotated bb approach can be as fast or faster than >>>>a rotated one. >>>> >>>>- my fastest ever version did it unrotated. I thereafter thought rotated would >>>>be even faster, but never got that speed again. (until hopefully now) >>>> >>>>- Dan Newman reaches almost 600k nps with little eval on a PIII/500, unrotated. >>>>While I thought the limit (based on what I see around) for rotated on this >>>>hardware is about 500k doing only material! >>>> >>>>- On this board I saw someone gen moves pretty fast unrotated. >>>> >>>>Pro unrotated: >>>> >>>>- you can gen moves in LVA/MVV order right away. You can not do that while >>>>rotating, at least not the way Crafty does it. Saves a sort afterwards. Don't >>>>know how big a factor this is. >>> >>>This is wrong. Rotated or Unrotated doesn't affect generating moves in MVV/LVA >>>order. Dark Thought uses MVV/LVA + rotated bitboards. I tried MVV/LVA a few >>>years ago during a discussion with Hsu in r.g.c.c... I had _no_ problems making >>>it work. >> >>What I mean is this: suppose you want to generate captures 1 at a time. Suppose >>you want the best MVV/LVA capture rightaway, in one bang. With 0x88 (and I guess >>rotated bitboards too) that approach can be a gain. >> >>Now you try that in Crafty. It would hardly be faster than generating all >>captures. At least in my program. A couple of AttacksTo() kills performance. > >You are probably doing it wrong. In Swap() I basically do this over and over. >Do a single AttacksFrom() call to find all the pieces attacking that square, >then AND that with the various piece bitmaps to find the cheapest piece that >is on one of those squares... Already tried this, of course. My point is that this takes *much* longer than just generating all captures. In the already mentioned position, for example, you would have to do 9 AttacksTo's before you find the *first* capture. I measured the time: it took 3x as much time as generating all captures unsorted. Then I concluded the rotated bb datastructure is not fit for 1-at-a-time capgen. Maybe premature, because with 0x88 (where this is supposed to work) would probably suffer from the same in this position. Regards, Bas Hamstra. >As I said, Dark Thought does _exactly_ what you are suggesting can't be done... >It generates moves one at a time, using rotated bitmaps. No reason it can't >be done... > > > > >> >>Speaking of 1 of a time generators: having distinct gencaps() and gennoncaps(), >>would it be an idea to divide gencaps() further in firstcapture() and >>gencaptures? >> > >No idea there... I have two functions as well. However I generate all >captures at one swoop, rather than one at a time, because I don't like MVV/LVA >ordering, and prefer to use Swap() and sort.
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.