Author: Uri Blass
Date: 04:48:34 12/01/03
Go up one level in this thread
On December 01, 2003 at 07:36:11, martin fierz wrote: >On December 01, 2003 at 06:57:13, Tord Romstad wrote: > >>From the initial position, I compute the attack tables about a million >>times per second with this code. From WAC1, the rate drops to about >>700,000 times per second. The high nodes/second count of Rebel (which >>has similar tables) makes me believe that it is possible to do this >>many times faster. > >hi tord, > >what hardware would that be? your P4 2.4GHz as usual? > >i have a similar problem - like you i also do a full eval at each node, and my >eval also generates all attacks => (?) my engine is awfully slow in nps. >not sure whether the "=>" is really true in general, or whether i'm just a >crappy programmer :-) > >unlike you, i use bitboards, but non-rotated. when i do a perft in the initial >position, i'm a bit slower than crafty (20%), but then i don't know what crafty >does in perft, probably more than mine. >in addition to making/unmaking moves i also update material count and hash >signature. i also generate attacks at all interior nodes of the perft tree, >which i decided to use in the move generation to avoid moving the king into a >check - not really necessary in perft, but since i have this information >computed in the real search, i added this to the move generator and can't do a >perft without it. > >in perft like this i do something like 3MN/s on a centrino 1.3GHz. when i add a >position-to-attack at every leaf node my speed drops to about 800 kN/s. i tried >using kogge-stone floodfill routines instead of my stupid way of generating >sliding attacks, but they were slower in the initial position. possibly because >in the initial position you can't slide anywhere, i'll have to check some perft >numbers for other positions (my stupid way of generating sliding attacks is to >make a "while !(x&occupied), x = direction(x), attacked|=x;" or something like >that - basically i move over all squares and look whether there is something on >that square, not a very efficient way of doing things, i'm sure. but i can stop >once i find something, which is pretty often in the initial position). > >so i don't have an answer to your code, but i'm also wondering how the other >engines manage to be so fast. don't they generate attacks? or is there a smart >way to update attacks incrementally? or are their authors just so much better at >programming? I believe that you simply generate more information and a lot of other programmers do not generate attack information. I do not know if you are slower than the latest public movei but my attack information is probably less than your attack information The information that I generate at every node is not about pieces that attacks every square but only about directions that every square is attacked from and the attacking square in the relevant case. Latest version is about 1.5 times faster in nps(only an estimate based on memory) thanks to optimization except other improvements. Uri
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.