Pyrrhic, Fathom for Humanoids.

[AndrewGrant]

TL;DR: Cleaned up the Fathom code base and put it up on Github under the name Pyrrhic. Code is faster, easier to look at, and far less likely to have any conflicts with your code names. It also has all the "safety nets" removed.

https://github.com/AndyGrant/Pyrrhic/

So I was looking at compiling Ethereal under C++, as a potential segway to NNUE as it seems I will inevitably be forced to go that route if I want to stay in my current position. So it turns out that the version of Fathom I was using (some time in 2018) was real rough for compiling in C++, so I went to JDart's Fathom and pulled the latest in hopes of grabbing 7man TB support as well.

That was also as mess. As great as Fathom is, it takes up some names in the namespace that it really has no right to. A few examples: WHITE_KING , ... BLACK_PAWN, BEST_NONE, SCORE_ILLEGAL, BOARD_RANK_1, BOARD_FILE_A, BLACK, WHITE, W_PAWN, ... B_KING, and much more. Fathom, or Syzygy, has no right to claim those things. I expected to be able to simply update my Fathom files and have things work -- wrong. There were all sorts of namespace collisions that went undetected, leading to crashes.

So I took Fathom and basically renamed everything. If it appears in tbchess.c, Fathom's "mini" chess implementation to support probing, then it starts with PYRRHIC_ or pyrrhic_. I tried not to touch the actual Syzygy probing code too much, but I also renamed plenty of things there, like #define max, #define min, #define Swap, #define PAWN, #define PIECE.

I also deleted a lot of safety nets that are in Fathom that I see no purpose for. Fathom would check to see if the board was legal -- that's your job not Fathom's. Fathom would check if castling rights were null and that the previous move was zeroing when probing WDL -- that's your job not Fathom's. I also removed some of the DTM probing code, as I currently don't make use if it and therefore cannot test it, and therefore would not feel comfortable releasing something with it in.

Over the course of the cleanup I probably played around 200,000 games at various stages to confirm that nothing was functionally different. The final test, based on the initial commit of the Pyrrhic repo, returned the following: Score of Pyrrhic vs Fathom: 6554 - 6427 - 21019 [0.502] 34000. So at the end of the day, Pyrrhic performs the same as Fathom, with slightly more speed (this has been consistent in the other 166,000 games), and no introduced crashes or segfaults that I could detect.

As of now, I would expect a user to modify about a dozen lines in tbconfig.h, and nothing more. Terje, the author of Weiss, is going to try it as well shortly I believe. You now MUST provide Fathom with your move generation code. No more free lunches for people who cannot encapsulate their attack generation.

I will be replacing Ethereal's Fathom with Pyrrhic today.

[jdart]

Al the defines you mention like WHITE_KING, etc. are in tbchess.c, which is included in tbprobe.c. None are in the interface, and none should be visible to clients of Fathom.

--Jon

[mar]

I find it a bit sad that this

Code: Select all

  Copyright (c) 2011-2015 Ronald de Man
  This file may be redistributed and/or modified without restrictions.

is no longer present in any of the files, probably changed by basil (along with the license)

Ronald still did most of the hard work so I'm curious why/how his name disappeared from his original probing code, even though the original
license technically placed the probing code in public domain.

His beautiful way of decoding huffman is still there, but people don't appreciate such small nuances...

as for name clashes: the original probing code contains defines for TB_KING, ... in the c file, not in the header, so I don't see a problem here
if you want unity build, since those are macros, #undef at the end of the c file is what you're looking for, no problem at all.

[jdart]

Ronald is credited in the README (https://github.com/jdart1/Fathom/blob/m ... nd-credits), which explains the history of the code also.

[mar]

I don't see his name anywhere in the source files, which is what I was referring to. Pyrrhic doesn't mention Ronald at all.

[mar]

What's funny is that basil's original Fathom code still mentions Ronald, so now I'm puzzled who and why removed his name from the source?

Code: Select all

 * tbprobe.c
 * Copyright (c) 2013-2015 Ronald de Man
 * This file may be redistributed and/or modified without restrictions.
 *
 * (C) 2015 basil, all rights reserved,

[jdart]

I think the issue with the defines is this: if you include your own header into tbconfig.h, so that you can use its definitions to define the optional attack macros, then those headers may conflict with bits of the Fathom implementation.

A possible solution to this is to create a module that has an interface like this (header file):

extern tb_knight_attacks(unsigned square);
extern tb_king_attacks(unsigned square);
extern tb_root_attacks(unsigned square, uint64_t occ);
extern tb_bishop_attacks(unsigned square, uinit64_t occ);
extern tb_queen_attacks(unsigned square, uint64_t occ);
extern tb_pawn_attacks(unsigned square, uint64_t occ);

This only depends on types defined in <cstdint>. The macro definitions in tbconfig.h can refer to these functions (they could be in a namespace if you want). Then the implementation (C++ file) for this module can bring in all the datatypes you want from your own sources. (A good optimizer will still inline the implementation even though it is not in the header). Since nothing in this module imports from Fathom at all, and since no non-system headers are made visible to Fathom by including in tbconfig.h, there should be no conflicts.

--Jon

[mar]

why would you do that? one shouldn't insert custom code into library headers
the macros were defined in the c file only and the original code used a TB_ prefix for the defines

[mar]

scratch my last post, it's a nonsense. I see now that tbconfig.h is used to interface with the engine, but I can't delete the post anymore. maybe the mods could help and delete my last two post please?

[jdart]

one shouldn't insert custom code into library headers

Indeed. But tbconfig.h is included via angle brackets. This allows you to override the Fathom version by placing your own version of the tbconfig.h header ahead of it in the include path.

--Jon