Author: Bas Hamstra
Date: 06:42:37 04/25/00
Go up one level in this thread
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. 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? Regards, Bas Hamstra. >>- You don't need the expensive 64 bit shifts doing movegeneration (and eval), >>which saves a lot of overhead. >> >>- Your make() is much faster without the 4 Occupied maps. >> >>Contra: >> >>- You have to scan for blocks, while rotated doesn't need to. However using a >>int__64 blockmask[From][To] can do this pretty quick (though some say scanning >>the board is even faster). >> >>The big question is: is the extra overhead of rotated bb's justifyable? Could it >>be non-rotated is faster overall? > > >I don't see how. But one point is that bitboards are a 64 bit technique, but >they are (at present) being used on a 32 bit architecture, which is not an >optimal solution. On 64 bit architectures, this is probably the right way to >do it. > > > >> >>(Currently I myself have started all over trying to make a really fast rotated >>BB program. Looks promising so far: make/unmake=2M/sec and movegeneration=12M >>moves/sec on a Celeron 466) > > >This is such a small part of a chess engine it doesn't really matter.
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.