Author: Dan Newman
Date: 13:11:55 11/16/99
Go up one level in this thread
On November 16, 1999 at 06:11:48, Alexander Kure wrote: >A few months ago I implemented a movegenerator for 0x88 board and tried to do >some performance improvements so I am glad to see this thread starting ;-) >My pseudo move-generator app. generates 3 MNodes on a Pentium MMX 233 Mhz in >Vincent's position and is app. 2.5 times faster on a Pentium III 550 Mhz giving >7.5 MNodes (without sorting and assigning scores for a move). Far away from the >high score, I'm afraid ;-) >Unfortunately I can not show up with the code, cause I am at work right now. >Maybe later if requested. > >But I doubt if using a switch instead of indexing through a piece array gives >any performance improvement. But directly proccessing each direction (e.g. NE, >NW, SE, SW for Bishop) for a piece seperately instead of looping and indexing a >piece dependent direction array surly yields some performance improvement. While >this lacks elegance it improves speed. >I will check this out! The code certainly is ugly. My 0x88 move generator code is 767 lines long and that's with a lot of macros to shorten it. The bitboard code is at 1168 LOC--but that also includes a check evasions generator. I don't use the switch to avoid indexing through the piece array, I just use it to select piece specific code. When I look at the generated code I see a lot of overhead for the switch statement that isn't needed. The compiler doesn't know that the argument to the switch statement will never be anything other than PAWN, KNIGHT, BISHOP, etc. and so tests the arg to see if it is out of range. All it really needs to do is index into the jump table. (Wouldn't it be nice if there were a pragma to tell the compiler to eliminate this test...) One nice thing you can do with a switch statement is to effectively combine the test for color with that for piece type by switching on a combined color/piece type value. I did this in an earlier move generator, but I'm not doing it now--I don't remember why... The bitboard code doesn't use a switch since there is no real piece list. That's something I really like about bitboards, they eliminate all the complicated piece list machinery--no need to reorder the list when a pawn promotes, no need to contract the list on a capture, etc. > >What also gives some performance (app. 7% in my case) is to use the good old int >type instead of any combination of unsigned, short, and whatsoever. > I like the int type too. It has a number of advantages: 1) it's lightweight and so helps with cache, 2) you can set all the fields in one go, 3) you can actually mask off portions of the move for various purposes--specifically you can mask off the from-to portion and use it as an index into the history heuristic array (though this is more difficult with 0x88 because of the holes). > >>Another thing I do is have completely separate capture and non-capture >>move generators. This actually hurts on Vincent's test since I have the >>overhead of calling two generators and must do many things twice, but in >>actual use the capture generator is called far more often than the >>non-capture generator. This is because I use only the capture generator >>in the quiescence search, and in the full width search a capture quite >>often is the cause of a cutoff preventing the non-capture generator from >>getting called... So, it likely saves some cycles to separate the move >>generation like this. It also makes move ordering easier. >> >>-Dan. > >Sounds reasonable to me. >Thx for your insights. > You're welcome, -Dan. >Greetings >Alex
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.