7-men Syzygy attempt

[jdart]

One issue: Fathom is MIT-licensed so I can't graft Stockfish code into it (that is under GPL including tbprobe.cpp).

--Jon

[jshriver]

Just a quick question regarding torrent files.

Do the torrent need to be updated for new sets generated apart from those available for now?

Or simply make another torrent for another generated sets when you feel for it.

I will gladly host the torrents and seed once the files are generated and there is an agreement on the quality of the set.
This looks promising and I've been an avid fan of having 7 men for years.

Anxious to see how this progresses
-Josh
http://oics.olympuschess.com/tracker

[syzygy]

One issue: Fathom is MIT-licensed so I can't graft Stockfish code into it (that is under GPL including tbprobe.cpp).

There is no such problem with Cfish's tbprobe.c. (And there is no copyright problem anyway if you just apply the changes that Sesse made to Stockfish, because he took them from Cfish.)

What needs to be changed:
- various arrays must have length 7 instead of 6
- factor[] elements must be uint64_t instead of uint32_t
- initialization should run through all 6v1, 5v2 and 4v3 combinations
- there should be room for 650 pawnless tables and 861 pawnful tables
- in decompress_pairs(), in one place the block number should be cast to uint64_t (or size_t) before shifting by blocksize when locating the block of compressed data that contains the position sought. (In SF the block number was size_t already.)
- most tricky is an alternative step of mapping, after decompression, to the correct DTZ value in probe_dtz_table(). Depending on a bit in the flags byte, there is a 16-bit mapping instead of an 8-bit mapping. This also affects table initialization.

I may have forgotten something.

I have recently rewritten tbprobe.c, so the differences with Fathom might now be bigger than they used to be. On the other hand, the code is now smaller with less duplication. (And it also supports DTM tables, but I have not yet released those.)

[Sesse]

The Lichess mirror seems not to have been updated since May 30. The main FTP server also appears to have dried up a bit (only one file generated May 31). Anything going on?

[noobpwnftw]

The Lichess mirror seems not to have been updated since May 30. The main FTP server also appears to have dried up a bit (only one file generated May 31). Anything going on?

Hit a few slow and big tables.
Uploading to FTP is by hand, while individual file times are kept as when they were built originally.

[Sesse]

Thanks for the update.

Aronian–Mamedyarov is in KRNPvKRPP right now; would be a poster child scenario for 7-man in search, except that we don't have nearly all the relevant tables yet.

[Nordlandia]

At current speed, how long until set KBPPvKPP?

Days if not weeks away at this point?

[Sesse]

KBPPvKPP is among the very last to be produced, since it depends on nearly everything else. So I guess about six weeks?

[noobpwnftw]

I'm building them as fast as I can, and it basically pushes all crucial hardware capabilities to their limits 24*7.
Pawnful tables are naturally slower to build and dependent on other tables.
Generally if you want to build a table with two pawns on one side then you must have built all tables with one pawn or less on that side.

Ronald is working on pawnful generator with NUMA optimizations, which should speed up a bit, but the whole thing is still in matter of months.

[Sharaf_DG]

Just found out that two tables (KQvK.rtbz & KRvK.rtbz) in ftp://112.73.74.24/pub/syzygy/3-6men failed the md5 check of http://kirill-kryukov.com/chess/tableba ... -DTZ-3-4-5. Is the tables correct or is Kiril md 5 incorrect...

D:\syzygy\3-6men>fsum -c Syzygybases-DTZ-3-4-5.md5
SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337
Implemented using SlavaSoft QuickHash Library <www.slavasoft.com>
Copyright (C) SlavaSoft Inc. 1999-2007. All rights reserved.
FAILED MD5 KQvK.rtbz
FAILED MD5 KRvK.rtbz
2 checksums failed