7-men Syzygy attempt

[noobpwnftw]

Regenerated KRBNvKQN, md5sum of KRBNvKQN.rtbz is ec6152ce78872e6dcedee5af925cd756.

Local probe looks fine, uploading.

[noobpwnftw]

Upload finished.
If it turns out well, we could probably call it a milestone: all 7-piece theoretical cases covered by one or more tables "correctly" built.

Note that large DTZ in pawnful tables doesn't seem to exist, and quoted correctly means not verified in an exhaustive way.

[syzygy]

Code: Select all

$ md5sum KRBNvKQN.rtbz
ec6152ce78872e6dcedee5af925cd756  KRBNvKQN.rtbz

md5sum is quite slow on such files

An alternative:

Code: Select all

$ tbcheck --print KRBNvKQN.rtbz
KRBNvKQN.rtbz: da5897e3daba811c7bcf500bca0417a5
$ tbcheck KRBNvKQN.rtbz
KRBNvKQN.rtbz: OK!

The first command just prints out the internal checksum stored inside the file. The second recalculates it and compares it with the stored value. The recalculation can be done with multiple threads (-t) but that might not be much quicker if the file has to be loaded from disk.

[syzygy]

Fen: 5q1n/8/8/4N3/4B3/3K2R1/8/4k3 w - - 0 1
Key: 8AF65EE2CD3390E8
Checkers:
Tablebases WDL: 2 (1)
Tablebases DTZ: 64 (1)
Tablebases DTM: cp 0 (0)
(I said 65, but I should have said 65 +/- 1, so OK)

Fen: 5n2/8/8/7q/3N1R2/3B4/8/k2K4 w - - 0 1
Key: 99AC33FADD29C35A
Checkers: h5
Tablebases WDL: 1 (1)
Tablebases DTZ: 152 (2)
Tablebases DTM: cp 0 (0)
(OK)

Fen: 8/2B5/8/1k6/8/3K4/4N1R1/qn6 w - - 0 1
Key: 87683D8F8EA45EB4
Checkers:
Tablebases WDL: -1 (1)
Tablebases DTZ: -1034 (1)
Tablebases DTM: mate 0 (0)
(OK)

Fen: 8/8/8/q7/8/8/1R3B2/NKnk4 w - - 0 1
Key: 3FF7F318447D441F
Checkers:
Tablebases WDL: -2 (1)
Tablebases DTZ: -100 (1)
Tablebases DTM: mate 0 (0)
(OK)

[Sharaf_DG]

My 2 cpu system with 112 logical cores, 1TB ram, 12 NVMe drives in RAID0. disk read write speed about 30gb/s whilst ram speed 2.666 gb/s. Would it not be faster to just compile on disk directly, if so, how to?

https://tinyurl.com/y74uxhct

[noobpwnftw]

Well, DDR4-2666(memory clock) gives about 21GB/s per channel, and you have 2x6 channel processors.
You might want to try creating a RAM disk and run Random Read/Write benchmarks to compare.
And more importantly, RAM doesn't worn out.

[Sesse]

Even more importantly, NVMe disks (and basically all other storage, save for the DIMM form factors of Optane, which hardly exist yet) work by transferring data to RAM and then having the CPU read it from there. So it would basically be impossible to have storage faster than RAM, since it needs to go through RAM.

[Milos]

Even more importantly, NVMe disks (and basically all other storage, save for the DIMM form factors of Optane, which hardly exist yet) work by transferring data to RAM and then having the CPU read it from there. So it would basically be impossible to have storage faster than RAM, since it needs to go through RAM.

Not if NVMe is accessed through polling or NVMe is PCIe based.

[Sesse]

NVMe is PCIe-based by definition. As for polling… I hope you're not accessing your NVMe disk over PIO, that would be awfully slow :-)

[Milos]

NVMe is PCIe-based by definition. As for polling… I hope you're not accessing your NVMe disk over PIO, that would be awfully slow

Also, if you place communication queues on NVMe device and your device is faster than main memory you can be faster than main memory.