Deep split perft()

[sje]

I've had some minor firmware trouble with the new machine. The Linux PCI handler was reporting a really big bunch of errors of apparent spurious interrupts on the PCI MSI subsystem. I fiddled with this for several hours and finally gave up by setting the boot option "pci=nomsi" to shut the damn thing up.

The problem appears to be specific to the X99 chipset.

A real fix requires a fix to Linux or a fix to the mainboard BIOS.

Just another reason to wait at least a year for a new chipset to mature.

[Joost Buijs]

There is no constant time ratio between running with and without transposition table assistance.

With 128 bit hash keys, memory corruption due to cosmic rays is more likely than a false positive match.

I expect when you run Perft(7) on a single core with and without transposition table that the time difference will always be the same (within a small range though).
The multiprocessing part makes things unpredictable because the order in which the moves are executed varies and therefore the transposition table use also varies because it doesn't has infinite size.

[Joost Buijs]

I've had some minor firmware trouble with the new machine. The Linux PCI handler was reporting a really big bunch of errors of apparent spurious interrupts on the PCI MSI subsystem. I fiddled with this for several hours and finally gave up by setting the boot option "pci=nomsi" to shut the damn thing up.

The problem appears to be specific to the X99 chipset.

A real fix requires a fix to Linux or a fix to the mainboard BIOS.

Just another reason to wait at least a year for a new chipset to mature.

I never tried to put Linux on the 5960X, with Windows it is running fine.
My X99 mainboard is the older version with USB 3.0, it already had 10 BIOS updates, it probably is more mature than the one you have.

[ibid]

There is no constant time ratio between running with and without transposition table assistance.

With 128 bit hash keys, memory corruption due to cosmic rays is more likely than a false positive match.

I expect when you run Perft(7) on a single core with and without transposition table that the time difference will always be the same (within a small range though).
The multiprocessing part makes things unpredictable because the order in which the moves are executed varies and therefore the transposition table use also varies because it doesn't has infinite size.

For me with gperft using one core in a phenom 1090T @ 3.6GHz, perft(7) with no hash table is 3.72 seconds, one core with 128 MB hash 1.00 seconds. (128 MB seems to be best here, at 4 MB it is taking 1.20 seconds, with 4 GB 1.07 seconds -- not including initialization time).

At perft(8), a single core and no hash table is about 99 seconds. A single core with a GB hash table is about 12 seconds.

Obviously the benefit of the hash table goes up as the computation gets longer.

[Joost Buijs]

There is no constant time ratio between running with and without transposition table assistance.

With 128 bit hash keys, memory corruption due to cosmic rays is more likely than a false positive match.

I expect when you run Perft(7) on a single core with and without transposition table that the time difference will always be the same (within a small range though).
The multiprocessing part makes things unpredictable because the order in which the moves are executed varies and therefore the transposition table use also varies because it doesn't has infinite size.

For me with gperft using one core in a phenom 1090T @ 3.6GHz, perft(7) with no hash table is 3.72 seconds, one core with 128 MB hash 1.00 seconds. (128 MB seems to be best here, at 4 MB it is taking 1.20 seconds, with 4 GB 1.07 seconds -- not including initialization time).

At perft(8), a single core and no hash table is about 99 seconds. A single core with a GB hash table is about 12 seconds.

Obviously the benefit of the hash table goes up as the computation gets longer.

Thanks!

This really makes me think about why my perft is so slow.
I don't know gperft, but it seems to be at least 10 times faster.
It is possible that it is the difference between bulk counting or not.
Something I have to look into.

[ibid]

This really makes me think about why my perft is so slow.
I don't know gperft, but it seems to be at least 10 times faster.
It is possible that it is the difference between bulk counting or not.
Something I have to look into.

Use caution comparing to gperft: while it is based on a reasonably standard chess engine, it has been heavily optimized for computing perfts. Bulk counting is a significant part of that. I have also removed any code not needed for perfts (50 move counter, material signatures, etc).

The latest (unreleased) development version whose times I gave above even does some basic null-move perfts (for lack of a better term). That is, when there are 2 ply to go, I make a null move and compute perft information about that position: how many moves does each knight have, what king moves are legal, etc. Then for each simple move (not capture, promotion, not checking, etc), I determine what information can be used from the null-move computation and what needs recomputing. (More accurately, I do quick checks to determine what information I can *guarantee* is correct and what information I am not sure about.)

-paul