Perft

Rein Halbersma · Post by **Rein Halbersma** » Sat Aug 23, 2008 11:05

Here are 2 more positions that I used in testing. One is the initial position with all men replaced by kings, the other has 5 men for each side one row away from promotion.

FEN "W:WK31,K32,K33,K34,K35,K36,K37,K38,K39,K40,K41,K42,K43,K44,K45,K46,K47,K48,K49,K50:BK1,K2,K3,K4,K5,K6,K7,K8,K9,K10,K11,K12,K13,K14,K15,K16,K17,K18,K19,K20."

Code: Select all

     
     B   B   B   B   B
   B   B   B   B   B
     B   B   B   B   B
   B   B   B   B   B
     .   .   .   .   .
   .   .   .   .   .
     W   W   W   W   W
   W   W   W   W   W
     W   W   W   W   W
   W   W   W   W   W


perft(1) 17 nodes, 0.001 sec, 0.017 Mnodes/sec
perft(2) 79 nodes, 0.001 sec, 0.079 Mnodes/sec
perft(3) 352 nodes, 0.001 sec, 0.352 Mnodes/sec
perft(4) 1399 nodes, 0.001 sec, 1.399 Mnodes/sec
perft(5) 7062 nodes, 0.017 sec, 0.415412 Mnodes/sec
perft(6) 37589 nodes, 0.016 sec, 2.34931 Mnodes/sec
perft(7) 217575 nodes, 0.111 sec, 1.96014 Mnodes/sec
perft(8) 1333217 nodes, 0.594 sec, 2.24447 Mnodes/sec
perft(9) 8558321 nodes, 3.642 sec, 2.3499 Mnodes/sec
perft(10) 58381162 nodes, 23.033 sec, 2.53467 Mnodes/sec
perft(11) 417920283 nodes, 198.126 sec, 2.10937 Mnodes/sec

FEN "W:W6,7,8,9,10:B41,42,43,44,45."

Code: Select all

     
     .   .   .   .   .
   w   w   w   w   w
     .   .   .   .   .
   .   .   .   .   .
     .   .   .   .   .
   .   .   .   .   .
     .   .   .   .   .
   .   .   .   .   .
     b   b   b   b   b
   .   .   .   .   .

perft(1) 9 nodes, 0.001 sec, 0.009 Mnodes/sec
perft(2) 81 nodes, 0.001 sec, 0.081 Mnodes/sec
perft(3) 795 nodes, 0.001 sec, 0.795 Mnodes/sec
perft(4) 7578 nodes, 0.001 sec, 7.578 Mnodes/sec
perft(5) 86351 nodes, 0.001 sec, 86.351 Mnodes/sec
perft(6) 936311 nodes, 0.079 sec, 11.852 Mnodes/sec
perft(7) 11448262 nodes, 0.891 sec, 12.8488 Mnodes/sec
perft(8) 138362698 nodes, 10.767 sec, 12.8506 Mnodes/sec
perft(9) 1799526674 nodes, 144.47 sec, 12.4561 Mnodes/sec

FeikeBoomstra · Post by **FeikeBoomstra** » Sat Aug 23, 2008 11:34

This is my detailed brake down of perft(13)
I think Rein's perft(14) is incorrect as e.g. cap7 becomes lower compared to perft(13)

Code: Select all

perft(13) 9872744 nodes in 84 sec(x100) 
node count = 9872744
		cap=0, cap_count=8645100
		cap=1, cap_count=578496
		cap=2, cap_count=467405
		cap=3, cap_count=134752
		cap=4, cap_count=37222
		cap=5, cap_count=7344
		cap=6, cap_count=2166
		cap=7, cap_count=259
		cap=8, cap_count=0
		cap=9, cap_count=0
tot cap count = 9872744

Anyway, it is quite strange:
cap 5,6 and 7 are equal, as well as cap 2.

Rein, can you send me a file with your cap 4 positions.
The damexchange format is the easiest, but any format will do.

Rein Halbersma · Post by **Rein Halbersma** » Sat Aug 23, 2008 15:24

FeikeBoomstra wrote:This is my detailed brake down of perft(13)
I think Rein's perft(14) is incorrect as e.g. cap7 becomes lower compared to perft(13)

Anyway, it is quite strange:
cap 5,6 and 7 are equal, as well as cap 2.

Rein, can you send me a file with your cap 4 positions.
The damexchange format is the easiest, but any format will do.

Hi Feike,

The fact that cap=7 is lower for d=14 than for d=13 doesn't mean anything since it's black to move in one case, and white to move in the other. Also, Ed's program got the same overall numbers and it also breaks down exactly like mine per cap-count. So either Ed and I have the same error, or your program has one. And also Gerard and Bert didn't report different numbers from Ed's initital post.

I haven't got DamExchange working, so all I can print right now are 64-bit numbers (in hex). I represent a position with 3 such bitboards: black pieces, white pieces and kings. Bits 0 to 53 hold the square information, with bits 10, 21, 32 and 43 representing the ghost squares. Is this a format you can read? (I will try to send it after the weekend, since I have some family obligations now).

Rein

Ed Gilbert · Post by **Ed Gilbert** » Sat Aug 23, 2008 19:32

Rein Halbersma wrote:, here is the breakdown in the number of captures (yes, the speed is slow, but that's a 3-year old single-processor P4 3.2GHz with 32-bits WinXP):

Rein's perft time's may not look very impressive running on his older computer, but his move generator uses some very unconventional techniques, including the use of 'magic' multiplications to compute in parallel some of the intermediate results. When he is able to run it on 64-bit hardware and OS I think it should really show its potential. In any case it is the most unusual and creative draughts move generators that I have heard about.

-- Ed

Rein Halbersma · Post by **Rein Halbersma** » Sat Aug 23, 2008 21:21

Ed Gilbert wrote:
Rein Halbersma wrote:, here is the breakdown in the number of captures (yes, the speed is slow, but that's a 3-year old single-processor P4 3.2GHz with 32-bits WinXP):
Rein's perft time's may not look very impressive running on his older computer, but his move generator uses some very unconventional techniques, including the use of 'magic' multiplications to compute in parallel some of the intermediate results. -- Ed

I am happy to share the trick Ed mentions. Given a bitboard from_sq that has a single bit set to 1, and a "magic" multiplier neighbor_magic=0x1803 I use the expression

Code: Select all

neighbors = (from_sq * neighbor_magic) >> 6);

to generate a bitboard neighbors that has all 4 neighboring squares of from_sq set to 1. The "mini-magic" 0x1803 is equal to 2^12 + 2^11 + 2^1 + 2^0. In my board representation (with ghosts), the bits 0,1,11 and 12 are the 4 neighbours of bit 6. Multiplying any single-bit bitboard by 0x1803 and shifting it by 6 is therefore equal to a bitboard holding only its 4 neighbours

I use this trick in my recursive capture routine in order to detect in which directions I can capture next. I do this by looping over all set bits of the neighbors (instead of looping over all 4 directions). I am sure that others who use the ghostsquare bit-layout must have come up with this same trick somewhere, but it is not possible without ghost squares.

Those of you who read the talkchess.com forums, know that the chess folks have developed a whole industry of such "magic" tricks that lets them generate moves for sliding pieces by "magic" multiplicative hashtable lookups. One of my future goals is to be able do the same for my man capture generator (i.e. no recursion any more!).

Rein

FeikeBoomstra · Post by **FeikeBoomstra** » Sun Aug 24, 2008 16:24

Thanks to Rein I found the problem:

The capturing king didn't go over it's initial start position. This was due to an optimization I made. First I only used a bitmap empty, and I added temporary the start-field to empty, but for performance reasons I introduced occupied. This was only generated once, and not updated if empty was changed.

Ok solved.

Rein Halbersma · Post by **Rein Halbersma** » Sun Aug 24, 2008 21:04

FeikeBoomstra wrote:Thanks to Rein I found the problem:

The capturing king didn't go over it's initial start position. This was due to an optimization I made. First I only used a bitmap empty, and I added temporary the start-field to empty, but for performance reasons I introduced occupied. This was only generated once, and not updated if empty was changed.

Ok solved.

During my conversations with Feike, I realized that the perft() output is a bit parsimonious. Here is a modified perft() output that shows per depth the number of moves, time, nps and the average branching factor. Also per capture depth this same information is given, including the number of positions (instead of only the number of moves). So in the output below for perft(9), the line cap

( 0): 37348848 ( 91.04%) 3482187 ( 53.70%) (b=10.73)

means that at depth=9, 91% of the moves are non-capture moves, and that 54% of the positions at depth=8 are non-capture positions. Hence, the average branching factor is 10.7 for non-capture positions. Similarly for the other lines. I also found it worthwhile to spend some time to properly align and format the output so that it is easier on the eyes.

Rein

Code: Select all

     b   b   b   b   b 
   b   b   b   b   b 
     b   b   b   b   b 
   b   b   b   b   b 
     .   .   .   .   . 
   .   .   .   .   . 
     w   w   w   w   w 
   w   w   w   w   w 
     w   w   w   w   w 
   w   w   w   w   w 

Starting position 

perft( 1)            9 nodes,  0.001 sec,   0.01 Mnps   (b= 9.00) 
cap ( 0):            9 (100.00%)            1 (100.00%) (b= 9.00) 

perft( 2)           81 nodes,   0.00 sec,   0.08 Mnps   (b= 9.00) 
cap ( 0):           81 (100.00%)            9 (100.00%) (b= 9.00) 

perft( 3)          658 nodes,   0.00 sec,   0.66 Mnps   (b= 8.12) 
cap ( 0):          643 ( 97.72%)           66 ( 81.48%) (b= 9.74) 
cap ( 1):           15 (  2.28%)           15 ( 18.52%) (b= 1.00) 

perft( 4)         4265 nodes,   0.00 sec,   4.26 Mnps   (b= 6.48) 
cap ( 0):         3932 ( 92.19%)          410 ( 62.31%) (b= 9.59) 
cap ( 1):          299 (  7.01%)          214 ( 32.52%) (b= 1.40) 
cap ( 2):           34 (  0.80%)           34 (  5.17%) (b= 1.00) 

perft( 5)        27117 nodes,   0.02 sec,   1.60 Mnps   (b= 6.36) 
cap ( 0):        24707 ( 91.11%)         2400 ( 56.27%) (b=10.29) 
cap ( 1):         2154 (  7.94%)         1609 ( 37.73%) (b= 1.34) 
cap ( 2):          256 (  0.94%)          256 (  6.00%) (b= 1.00) 

perft( 6)       167140 nodes,   0.02 sec,   9.83 Mnps   (b= 6.16) 
cap ( 0):       152018 ( 90.95%)        15133 ( 55.81%) (b=10.05) 
cap ( 1):        11838 (  7.08%)         8767 ( 32.33%) (b= 1.35) 
cap ( 2):         2366 (  1.42%)         2299 (  8.48%) (b= 1.03) 
cap ( 3):          918 (  0.55%)          918 (  3.39%) (b= 1.00) 

perft( 7)      1049442 nodes,   0.20 sec,   5.14 Mnps   (b= 6.28) 
cap ( 0):       954787 ( 90.98%)        90595 ( 54.20%) (b=10.54) 
cap ( 1):        75377 (  7.18%)        57587 ( 34.45%) (b= 1.31) 
cap ( 2):        13965 (  1.33%)        13645 (  8.16%) (b= 1.02) 
cap ( 3):         5313 (  0.51%)         5313 (  3.18%) (b= 1.00) 

perft( 8)      6483961 nodes,   0.67 sec,   9.63 Mnps   (b= 6.18) 
cap ( 0):      5894975 ( 90.92%)       569813 ( 54.30%) (b=10.35) 
cap ( 1):       420742 (  6.49%)       321160 ( 30.60%) (b= 1.31) 
cap ( 2):       131952 (  2.04%)       122367 ( 11.66%) (b= 1.08) 
cap ( 3):        35308 (  0.54%)        35118 (  3.35%) (b= 1.01) 
cap ( 4):          984 (  0.02%)          984 (  0.09%) (b= 1.00) 

perft( 9)     41022423 nodes,   4.08 sec,  10.06 Mnps   (b= 6.33) 
cap ( 0):     37348848 ( 91.04%)      3482187 ( 53.70%) (b=10.73) 
cap ( 1):      2677179 (  6.53%)      2068456 ( 31.90%) (b= 1.29) 
cap ( 2):       787229 (  1.92%)       725667 ( 11.19%) (b= 1.08) 
cap ( 3):       203297 (  0.50%)       201781 (  3.11%) (b= 1.01) 
cap ( 4):         5854 (  0.01%)         5854 (  0.09%) (b= 1.00) 
cap ( 5):           16 (  0.00%)           16 (  0.00%) (b= 1.00) 


End of program

Rein Halbersma · Post by **Rein Halbersma** » Thu Aug 28, 2008 21:53

The chess folks have a refinement of the perft() tool. It's called divide() and simple does a perft(depth-1) for all successors of the initial position. This is a useful thing to have since it allows two disagreeing programs to locate an example position where they generate a different move list. Below is my own output for a divide(11) on the initial position.

Rein

Code: Select all

     b   b   b   b   b
   b   b   b   b   b
     b   b   b   b   b
   b   b   b   b   b
     .   .   .   .   .
   .   .   .   .   .
     w   w   w   w   w
   w   w   w   w   w
     w   w   w   w   w
   w   w   w   w   w

Starting position: found 9 moves

  1.31-26 perft(10)    221541214 nodes,  23.17 sec,   9.56 Mnps   (b= 6.30)
  2.31-27 perft(10)    150536090 nodes,  15.00 sec,  10.04 Mnps   (b= 6.52)
  3.32-27 perft(10)    146283394 nodes,  14.63 sec,  10.00 Mnps   (b= 6.48)
  4.32-28 perft(10)    173413440 nodes,  17.13 sec,  10.13 Mnps   (b= 6.53)
  5.33-28 perft(10)    182091961 nodes,  17.86 sec,  10.20 Mnps   (b= 6.54)
  6.33-29 perft(10)    169824878 nodes,  17.08 sec,   9.94 Mnps   (b= 6.45)
  7.34-29 perft(10)    146116662 nodes,  14.86 sec,   9.83 Mnps   (b= 6.35)
  8.34-30 perft(10)    261785029 nodes,  26.22 sec,   9.98 Mnps   (b= 6.42)
  9.35-30 perft(10)    214268730 nodes,  21.84 sec,   9.81 Mnps   (b= 6.39)

Total nodes: 1665861398

End of program

Rein Halbersma · Post by **Rein Halbersma** » Sat Nov 01, 2008 15:53

Ed Gilbert wrote:Bert,

I think if you want to use Perft for move generator benchmarks, then we have to make the modification which they call bulk counting at the Perft web page. The description of bulk counting also points this out, that it gives a better indication of move generator speed. I made the bulk counting modification, and now I get these results for your comparison.

{game start position}
perft -d11
perft(1) 9 nodes, 0.00 sec, 9 knodes/sec
perft(2) 81 nodes, 0.00 sec, 81 knodes/sec
perft(3) 658 nodes, 0.00 sec, 658 knodes/sec
perft(4) 4265 nodes, 0.00 sec, 4265 knodes/sec
perft(5) 27117 nodes, 0.00 sec, 27117 knodes/sec
perft(6) 167140 nodes, 0.00 sec, 167140 knodes/sec
perft(7) 1049442 nodes, 0.02 sec, 61732 knodes/sec
perft(8) 6483961 nodes, 0.14 sec, 45986 knodes/sec
perft(9) 41022423 nodes, 0.86 sec, 47645 knodes/sec
perft(10) 258895763 nodes, 5.30 sec, 48867 knodes/sec
perft(11) 1665861398 nodes, 32.80 sec, 50792 knodes/sec

{test position with 530 redundant moves at the start}
perft -d9 -f B:W6,9,10,11,20,21,22,23,30,K31,33,37,41,42,43,44,46:BK17,K24.
perft(1) 14 nodes, 0.00 sec, 14 knodes/sec
perft(2) 55 nodes, 0.00 sec, 55 knodes/sec
perft(3) 1168 nodes, 0.00 sec, 1168 knodes/sec
perft(4) 5432 nodes, 0.00 sec, 5432 knodes/sec
perft(5) 87195 nodes, 0.00 sec, 87195 knodes/sec
perft(6) 629010 nodes, 0.00 sec, 629010 knodes/sec
perft(7) 9041010 nodes, 0.14 sec, 64121 knodes/sec
perft(8) 86724219 nodes, 1.27 sec, 68448 knodes/sec
perft(9) 1216917193 nodes, 18.22 sec, 66790 knodes/sec

{Position from a Woldouby game}
perft -d15 -f W:W25,27,28,30,32,33,34,35,37,38:B12,13,14,16,18,19,21,23,24,26.
perft(1) 6 nodes, 0.00 sec, 6 knodes/sec
perft(2) 12 nodes, 0.00 sec, 12 knodes/sec
perft(3) 30 nodes, 0.00 sec, 30 knodes/sec
perft(4) 73 nodes, 0.00 sec, 73 knodes/sec
perft(5) 215 nodes, 0.00 sec, 215 knodes/sec
perft(6) 590 nodes, 0.00 sec, 590 knodes/sec
perft(7) 1944 nodes, 0.00 sec, 1944 knodes/sec
perft(8) 6269 nodes, 0.00 sec, 6269 knodes/sec
perft(9) 22369 nodes, 0.00 sec, 22369 knodes/sec
perft(10) 88050 nodes, 0.00 sec, 88050 knodes/sec
perft(11) 377436 nodes, 0.02 sec, 23590 knodes/sec
perft(12) 1910989 nodes, 0.06 sec, 29859 knodes/sec
perft(13) 9872645 nodes, 0.28 sec, 35009 knodes/sec
perft(14) 58360286 nodes, 1.60 sec, 36590 knodes/sec
perft(15) 346184885 nodes, 9.38 sec, 36922 knodes/sec

-- Ed

Thanks to Ed for running my code on his fast quad core: here are my fully optimized perft() timings. I think I can claim the speed record now [img]images/smilies/icon_cool.gif[/img]

Code: Select all


     b   b   b   b   b
   b   b   b   b   b
     b   b   b   b   b
   b   b   b   b   b
     .   .   .   .   .
   .   .   .   .   .
     w   w   w   w   w
   w   w   w   w   w
     w   w   w   w   w
   w   w   w   w   w

"W:B1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20:W31,32,33,34,35,36,37,38,
39,40,41,42,43,44,45,46,47,48,49,50"

Starting position: searching to nominal depth=11

perft( 1)            9 moves,   0.00 sec,   0.01 Mnps   (b=-1.#J)
perft( 2)           81 moves,   0.00 sec,   0.08 Mnps   (b=-1.#J)
perft( 3)          658 moves,   0.00 sec,   0.66 Mnps   (b=-1.#J)
perft( 4)         4265 moves,   0.00 sec,   4.26 Mnps   (b=-1.#J)
perft( 5)        27117 moves,   0.00 sec,  27.12 Mnps   (b=-1.#J)
perft( 6)       167140 moves,   0.02 sec,   9.83 Mnps   (b=-1.#J)
perft( 7)      1049442 moves,   0.02 sec,  65.59 Mnps   (b=-1.#J)
perft( 8)      6483961 moves,   0.10 sec,  68.25 Mnps   (b=-1.#J)
perft( 9)     41022423 moves,   0.56 sec,  72.73 Mnps   (b=-1.#J)
perft(10)    258895763 moves,   3.59 sec,  72.04 Mnps   (b=-1.#J)
perft(11)   1665861398 moves,  22.61 sec,  73.68 Mnps   (b=-1.#J)

     .   .   .   .   .
   w   .   .   w   w
     w   .   .   .   .
   .   B   .   .   w
     w   w   w   B   .
   .   .   .   .   w
     W   .   w   .   .
   .   w   .   .   .
     w   w   w   w   .
   w   .   .   .   .

"B:BK17,K24:W6,9,10,11,20,21,22,23,30,K31,33,37,41,42,43,44,46"

Starting position: searching to nominal depth=9

perft( 1)           14 moves,   0.00 sec,   0.01 Mnps   (b=-1.#J)
perft( 2)           55 moves,   0.00 sec,   0.06 Mnps   (b=-1.#J)
perft( 3)         1168 moves,   0.00 sec,   1.17 Mnps   (b=-1.#J)
perft( 4)         5432 moves,   0.00 sec,   5.43 Mnps   (b=-1.#J)
perft( 5)        87195 moves,   0.00 sec,  87.19 Mnps   (b=-1.#J)
perft( 6)       629010 moves,   0.02 sec,  37.00 Mnps   (b=-1.#J)
perft( 7)      9041010 moves,   0.08 sec, 114.44 Mnps   (b=-1.#J)
perft( 8)     86724219 moves,   0.88 sec,  99.00 Mnps   (b=-1.#J)
perft( 9)   1216917193 moves,  12.11 sec, 100.49 Mnps   (b=-1.#J)

     .   .   .   .   .
   .   .   .   .   .
     .   b   b   b   .
   b   .   b   b   .
     b   .   b   b   w
   b   w   w   .   w
     .   w   w   w   w
   .   w   w   .   .
     .   .   .   .   .
   .   .   .   .   .

"W:B12,13,14,16,18,19,21,23,24,26:W25,27,28,30,32,33,34,35,37,38"

Starting position: searching to nominal depth=15

perft( 1)            6 moves,   0.00 sec,   0.01 Mnps   (b=-1.#J)
perft( 2)           12 moves,   0.00 sec,   0.01 Mnps   (b=-1.#J)
perft( 3)           30 moves,   0.00 sec,   0.03 Mnps   (b=-1.#J)
perft( 4)           73 moves,   0.00 sec,   0.07 Mnps   (b=-1.#J)
perft( 5)          215 moves,   0.00 sec,   0.22 Mnps   (b=-1.#J)
perft( 6)          590 moves,   0.00 sec,   0.59 Mnps   (b=-1.#J)
perft( 7)         1944 moves,   0.00 sec,   1.94 Mnps   (b=-1.#J)
perft( 8)         6269 moves,   0.00 sec,   6.27 Mnps   (b=-1.#J)
perft( 9)        22369 moves,   0.00 sec,  22.37 Mnps   (b=-1.#J)
perft(10)        88050 moves,   0.00 sec,  88.05 Mnps   (b=-1.#J)
perft(11)       377436 moves,   0.02 sec,  22.20 Mnps   (b=-1.#J)
perft(12)      1910989 moves,   0.05 sec,  39.81 Mnps   (b=-1.#J)
perft(13)      9872645 moves,   0.22 sec,  44.88 Mnps   (b=-1.#J)
perft(14)     58360286 moves,   1.17 sec,  49.75 Mnps   (b=-1.#J)
perft(15)    346184885 moves,   6.97 sec,  49.67 Mnps   (b=-1.#J)

BertTuyt · Post by **BertTuyt** » Sun Nov 02, 2008 20:04

Rein, very good result !!!
Did Ed use the same processor as I have ( Q6600) ?
Anyway, tried to do some optimization today, to reach better timings for perft.

I now realize 23.51 sec for the initial board position, which is still 1 second slower then your implementation, but around 3 seconds faster as my previous result.

So the speed-crown is still yours [img]images/smilies/icon_razz.gif[/img] .

Bert

Rein Halbersma · Post by **Rein Halbersma** » Sun Nov 02, 2008 21:53

BertTuyt wrote:Rein, very good result !!!
Did Ed use the same processor as I have ( Q6600) ?
Anyway, tried to do some optimization today, to reach better timings for perft.

I now realize 23.51 sec for the initial board position, which is still 1 second slower then your implementation, but around 3 seconds faster as my previous result.

So the speed-crown is still yours .

Bert

Yes, it's the same processor. The final improvements came after I manually unrolled the loops over 4 capture directions and eliminated some poorly predictable branches. I think you do this already.

Rein

TAILLE · Post by **TAILLE** » Sat Nov 22, 2008 00:09

Hi,

As I said to you I am rewritting my move genrator. I have now finished the generation for position witn olny men (no kings).

The perft function at level 11, starting from the initial position give the result :

1665861398 nodes in 27.85 seconds on a core 2 duo 2.2GHz

Gérard

Ed Gilbert · Post by **Ed Gilbert** » Sat Nov 22, 2008 15:55

Hi Gerard,

TAILLE wrote:The perft function at level 11, starting from the initial position give the result :

1665861398 nodes in 27.85 seconds on a core 2 duo 2.2GHz

This is equivalent to 22.8 seconds on a Q6600, a good result. Can you detect the speedup in a Damy search? The speedup might be more significant in your endgame database builder. Did you try that?

-- Ed

TAILLE · Post by **TAILLE** » Sat Nov 22, 2008 17:26

Hi Ed.

Ed Gilbert wrote: This is equivalent to 22.8 seconds on a Q6600.

How do you calculate this equivalent ?

Ed Gilbert wrote: Can you detect the speedup in a Damy search? The speedup might be more significant in your endgame database builder. Did you try that?

Of course not because I have to finish the move generation with kings. It is now almost done.
Gérard

Ed Gilbert · Post by **Ed Gilbert** » Sat Nov 22, 2008 17:33

TAILLE wrote:How do you calculate this equivalent ?

I thought I scaled your time by the ratio of the clock frequencies, but I must have made a typo on the calculator. The correct time scaled to a Q6600 is 25.5 sec.

-- Ed