Author: Robert Hyatt
Date: 10:50:14 04/25/00
Go up one level in this thread
On April 25, 2000 at 10:17:15, 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. >> >> >> >>> >>>- 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. Perft was not done to measure speed. I never use it. It was done as others asked for those numbers to compare their speed to rotated bitmaps. I couldn't answer the questions until I wrote that code. (and I assume you mean perf and not perft). perft was written as a move generator sanity test only...
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.