World Draughts Forum

Aart, Wow, these numbers are so big I had to look them up to see how they are named. So that is 3 quintillion and counting!
I do hope to be able to verify this, I think it is just within my grasp. I will post back when I am an old man!

Here's my figures:

i7-M620 @ 2.67Ghz

EDIT: These first 2 tables had cumulative times originally by mistake. They now show independent times for each depth.

15/9/2012: Single thread, perft plain (no bulk counting)

1 ply, e = 7, 0.00s, 0 K Leaf Nodes/sec
2 ply, e = 49, 0.00s, 4 K Leaf Nodes/sec ...

I think having a single hash table per core is the only way to guarantee correctness (barring memory errors of course).
I'll try your idea of totally separate hash tables per thread and see how performance goes.

No surprises that using totally separate hash tables per thread vs shared hash ...

I'll try your idea of totally separate hash tables per thread and see how performance goes.
You could also use some spinlocks for mutual exclusion with a single hashtable. A single spinlock would be bad because only one thread could access the hashtable at a time. But if you used say 100 locks ...

But the lock-less hashing method I use does not make this situation better or worse. Type-1 collisions can happen in single threaded or multi threaded (+ lock-less hash) perft apps and can ruin the results either way.


I'm not sure if this old xor-trick (i.e. not using std::atomic_fetch_xor) is ...

Continuing my quest for deeper and deeper perft numbers for 8x8 checkers , I now computed depth 25 with the same distributed implementation I used earlier for depths up to 24. Below you see the perft breakdown per move (called "divide") from the initial position for various depths up to 25 (my ...

Long time no hear from you! Are you still working on Nemesis, or another checkers engine?

Mac Banks mentioned that you were building a 10-piece database. Did you finish building it?

Hello Ed! It's been a while! I haven't worked on a checkers engine for a long time now, since our aborted ...

Correct me if I'm wrong, but I think that lock-less hashing is not guaranteed to be correct for perft counts. In regular searches, almost all (and rare to begin with) read/write races on individual hash entries are filtered out by the alpha-beta mechanism, but for perft any error will certainly ...

Congratulations, Murray. You must have upgraded your hardware because the previous perft(23) also took you 4 days, IIRC. Can you give us some details on your hardware / algorithm (hash? parallelism?) BTW, unless your perft(25) computation is nearly finished, it is generally not a good idea to ...

Hello Aart, I can finally verify perft(24) = 34651381875296000. Although I don't have breakdown figures (I have only just added that feature).
It took 4d 10:08:37 on my laptop to compute. Next: perft(25)!

Murray