perft 12

[ibid]

I've been testing an upcoming release of gperft and wanted to see how it fared on a longer running problem:

Code: Select all

gperft 1.2d (linux)
Low hash table ready (4096 MB, 2-3 ply).
High hash table ready (2048 MB, 4-9 ply).
Using 6 threads (split after 3 ply).
Depth is 12.

rnbqkbnr
pppppppp
--------
--------  w KQkq -
--------
--------
PPPPPPPP
RNBQKBNR

Na3        2,101,612,201,748,156
Nc3        2,731,501,636,365,779
Nf3        2,704,348,041,301,604
Nh3        2,133,059,306,892,947
a3         1,825,396,176,881,632
b3         2,407,514,849,528,875
c3         2,751,675,948,507,059
d3         4,588,998,634,450,632
e3         7,160,631,171,539,800
f3         1,552,858,858,446,419
g3         2,498,600,008,341,437
h3         1,814,268,178,532,771
a4         2,572,564,331,526,038
b4         2,412,357,918,298,534
c4         3,119,892,147,087,203
d4         6,326,899,070,222,383
f4         2,050,768,802,609,121
e4         7,263,638,936,690,183
g4         2,217,762,743,088,597
h4         2,620,620,274,642,577
TOTAL     62,854,969,236,701,747
91570.067 seconds

Which confirms Steven Edward's confirmation of my original computation. :)
More to the point, it confirms his divide numbers http://talkchess.com/forum/viewtopic.php?t=38862
in case they haven't been confirmed yet.

gperft's times for the initial position (using these same settings) on a Phenom 1090T @ 3.6 GHz are now:

Code: Select all

 6     0.016
 7     0.187  x11.69
 8     2.251  x12.04
 9    27.077  x12.03
10   344.756  x12.73
11  4861.682  x14.10
12 91570.067  x18.84

The modest 6GB hash table is starting to slow things down. I imagine things would go faster on
a machine with 32 or 64GB. In any case, computations in the day+ range are noticably faster
starting with a set of unique positions some ply in.

-paul

[sje]

The modest 6GB hash table is starting to slow things down. I imagine things would go faster on
a machine with 32 or 64GB.

I've got a quad core Mac with 32 GiB RAM. Reserving 24 GiB for the transposition table gives 2^30 entries; that's big enough to hold unique(8) if the hashes were well-distributed.

Could you send me a copy of your gperft source that I could compile and run on my 32 GiB machine? I could try varying the table sizes to see how that affected running time.

[sje]

On my 32 GiB machine, Symbolic allocates a 24 GiB transposition table which has 2^30 elements. Each element contains an eight byte count and a sixteen byte signature.

Some perft() results (Pt = processor time, Wt = Wall time):

Code: Select all

[] pctran 7
Count: 3,195,901,860   Pt: 6.645   Wt: 1.677   U: 0.9907   1.92352 GHz   519.88 ps
[] pctran 8
Count: 84,998,978,956   Pt: 1:26.131   Wt: 21.882   U: 0.984005   3.94741 GHz   253.331 ps
[] pctran 9
Count: 2,439,530,234,167   Pt: 14:55.593   Wt: 3:45.172   U: 0.994342   10.8957 GHz   91.7793 ps
[] pctran 10
Count: 69,352,859,712,417   Pt: 2:58:21.016   Wt: 44:49.290   U: 0.994781   25.9238 GHz   38.5745 ps

[Henk]

How do you know your perft calculations are without errors ?

[Dann Corbit]

How do you know your perft calculations are without errors ?

The calculations are verified when someone else performs the same calculation and gets the same number.

Of course, it is still conceivable that both programs have the same bug in them.

However, if both programs give the correct answers for plies 8,9,10,11, and 12 it seems likely that 13 will also be correct.

[syzygy]

How do you know your perft calculations are without errors ?

The calculations are verified when someone else performs the same calculation and gets the same number.

Of course, it is still conceivable that both programs have the same bug in them.

Even if neither program has a bug, hashing errors probably cannot be excluded (unless the programs store the whole position in the hash table, for example, which they most likely don't).

Assuming the programs do not hash in an identical manner, the chances are rather small that both results are off by exactly the same amount due to hashing errors. Still, this cannot really be excluded as the errors due to hashing might be relatively small. The chances that the results returned by both programs are off by the same relatively small error aren't completely negligible.

[sje]

How do you know your perft calculations are without errors ?

https://duckduckgo.com/?q=69%2C352%2C85 ... C417+perft

[Henk]

How do you know your perft calculations are without errors ?

https://duckduckgo.com/?q=69%2C352%2C85 ... C417+perft

Yes engines all make the same errors. They are apes.

[Ajedrecista]

Hello Steven:

https://duckduckgo.com/?q=69%2C352%2C85 ... C417+perft

Thanks for the link, it allowed me to realize that a post by myself was plagiarized in Pastebin:

Untitled BY: A GUEST ON APR 7TH, 2013

Re: Perft(14) estimates thread: my strange method.

Less than two months for copy my weird method in other site without quote the original source. Is it a common practice on Pastebin? Since that post is untitled (and it is not the only one): are there people in Pastebin that copy random posts from other fora just as a kind of a backup?

Regards from Spain.

Ajedrecista.