Author: Bas Hamstra
Date: 07:17:15 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. > > > >> >>- 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. Sorry, but I think it does. If you don't pay attention to speed issues from the beginning you will end up with half the nps you could have had. I have done it slow. If you stick an eval in a slow program you can *still* divide nps by 2. So it is better to start at least reasonably. You know that. Wasn't it important enought to make "perft"? Regards, Bas Hamstra.
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.