Questions about Alexandria

[Rebel]

PREAMBLE
This is not an investigation, let's say I just like to know what I am doing wrong.

I downloaded Alexandria from user PGG106, compiled with the VS available .sln and started a selfplay match to see if the compile would give about equal results. Unfortunately it did not.

Code: Select all

No. Name                   Win Draw Loss Unf.  Score Games       %
------------------------------------------------------------------
 1 Alexandria-6.1.0-avx2  +21  =20   -0   *0   31.0    41   75.6%
 2 Alexandria-vs-compile   +0  =20  -21   *0   10.0    41   24.4%

No need to play further, a PGN tool (with depth stats) gave the answer.

Code: Select all

Engine                  Depth       Time   Games     Moves  Average Forfeit  Book Depth     MIDG   EARLY    ENDG    LATE
Alexandria-vs-compile   16.47    0:10:33      41      2510    0.25     0      374  9.12    13.64 | 13.34 | 16.89 | 24.10
Alexandria-6.1.0-avx2   21.66    0:09:42      41      2498    0.23     0      374  9.12    18.28 | 18.76 | 22.27 | 30.39

The official version thinks 5 plies deeper than the version compiled with Visual studio.

Some other strange thing I don't understand, the sizes of the executables.

Code: Select all

4.530.238 Alexandria-6.1.0-avx2.exe
   394.240 Alexandria-vs-compile.exe
 1.579.072 nn.net

It looks like (not sure) the official version has the nn.net compiled inside, the VS compile certainly not.

[Nek]

MSVC doesn't support INCBIN so the net wasn't embeded and the stdlib is linked dynamically.

[Ciekce]

responding at cj5716's request, as neither active alex dev has a talkchess account (any more)

as MSVC does not support 128-bit integers, TT indexing in alex falls back to the naive modulo method on MSVC. the problem you're seeing here is that while lemire's 128-bit fixed-point mul trick uses the high bits of the key for indexing, modulo uses the low ones, and the low bits are what is stored in TT entries for verification -> every single TT probe passes key verification, collisions ruin search.

when implementing the same indexing trick in Stormphrax and forgetting to fix this exact problem, I lost about 400 elo on the spot, so this tracks

the non-embedded net is also an MSVC issue, it doesn't support incbin (that's fine in this case, alex is loading the net at runtime automatically)

[Guenther]

PREAMBLE
This is not an investigation, let's say I just like to know what I am doing wrong.

I downloaded Alexandria from user PGG106, compiled with the VS available .sln and started a selfplay match to see if the compile would give about equal results. Unfortunately it did not.

Code: Select all

No. Name                   Win Draw Loss Unf.  Score Games       %
------------------------------------------------------------------
 1 Alexandria-6.1.0-avx2  +21  =20   -0   *0   31.0    41   75.6%
 2 Alexandria-vs-compile   +0  =20  -21   *0   10.0    41   24.4%

No need to play further, a PGN tool (with depth stats) gave the answer.

Code: Select all

Engine                  Depth       Time   Games     Moves  Average Forfeit  Book Depth     MIDG   EARLY    ENDG    LATE
Alexandria-vs-compile   16.47    0:10:33      41      2510    0.25     0      374  9.12    13.64 | 13.34 | 16.89 | 24.10
Alexandria-6.1.0-avx2   21.66    0:09:42      41      2498    0.23     0      374  9.12    18.28 | 18.76 | 22.27 | 30.39

The official version thinks 5 plies deeper than the version compiled with Visual studio.

Some other strange thing I don't understand, the sizes of the executables.

Code: Select all

4.530.238 Alexandria-6.1.0-avx2.exe
   394.240 Alexandria-vs-compile.exe
 1.579.072 nn.net

It looks like (not sure) the official version has the nn.net compiled inside, the VS compile certainly not.

When did you compile it, what version/commit id? Even the size of the nn.net is wrong, it is around 2.3MB since at least 3 weeks.

You should provide more infos at least. What about some output?
(and yes the size of your binary cannot contain even the previous net)

[Rebel]

responding at cj5716's request, as neither active alex dev has a talkchess account (any more)

as MSVC does not support 128-bit integers, TT indexing in alex falls back to the naive modulo method on MSVC. the problem you're seeing here is that while lemire's 128-bit fixed-point mul trick uses the high bits of the key for indexing, modulo uses the low ones, and the low bits are what is stored in TT entries for verification -> every single TT probe passes key verification, collisions ruin search.

when implementing the same indexing trick in Stormphrax and forgetting to fix this exact problem, I lost about 400 elo on the spot, so this tracks

the non-embedded net is also an MSVC issue, it doesn't support incbin (that's fine in this case, alex is loading the net at runtime automatically)

Okay, that makes sense. Makes me wonder why offering ready to use VS link in the download that actually works fine and compiles without errors.

[petero2]

the non-embedded net is also an MSVC issue, it doesn't support incbin

I disagree, incbin works for texel using MSVC, see: https://github.com/peterosterlund2/texe ... 8f17c6e450

I don't think it is a good idea to use MSVC though, at least not for texel, because it generates slower executables than clang and gcc.

[Ciekce]

the non-embedded net is also an MSVC issue, it doesn't support incbin

I disagree, incbin works for texel using MSVC, see: https://github.com/peterosterlund2/texe ... 8f17c6e450

I don't think it is a good idea to use MSVC though, at least not for texel, because it generates slower executables than clang and gcc.

it "works", but requires an extra step, which Alex is not doing

yeah MSVC is in general a horrible compiler to use if you want performance

[RubiChess]

yeah MSVC is in general a horrible compiler to use if you want performance

... but a great debugger integrated in the IDE, that's the main reason I still use MSVC most of the time for development and also provide project files for it although I never would recommend to compile binaries for general use with it.

Regards.