A complete 2000 lines of code engine

[xr_a_y]

(but still stuck on the long TC ladder ... http://ccrl.chessdom.com/ccrl/4040/cgi/ ... +opponents)

Hi Vivien,

the problem is that you release so frequently, it's difficult to keep up to date with the testing.
Not a criticism, just saying.

Hi Graham, I was refering to Minic level being stuck, not at all your tested version. I am very thankful for all the test you are performing. Long TC test needs a lot a effort, thanks again.

Because I only test short or very short TC Minic has difficulty to improve on the long TC ladder. That s another reason your tests are very appreciated! Useful inputs.

[Roland Chastain]

Hello Vivien!

I get an error when trying to start Minic 1.47 under Linux:

Code: Select all

[roland@localhost minic]$ ./minic_1.47_linux_x64_x86-64 
./minic_1.47_linux_x64_x86-64: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./minic_1.47_linux_x64_x86-64)

I have glibc installed but it is the version 2.29.

Maybe I will try to compile myself the source code.

Regards.

Roland

[xr_a_y]

Hello Vivien!

I get an error when trying to start Minic 1.47 under Linux:

Code: Select all

[roland@localhost minic]$ ./minic_1.47_linux_x64_x86-64 
./minic_1.47_linux_x64_x86-64: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./minic_1.47_linux_x64_x86-64)

I have glibc installed but it is the version 2.29.

Maybe I will try to compile myself the source code.

Regards.

Roland

Indeed, I build Minic versus g++9 in C++17

Code: Select all

gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)

so that you need quite recent libc++ to run it. You can safely recompile it yourself.
For this you can use the tools/build.sh script given to ensure optimization by profiling is done.

Regards

[Roland Chastain]

For this you can use the tools/build.sh script given to ensure optimization by profiling is done.

Thank you for your answer. Here is what I get:

Code: Select all

[roland@localhost tools]$ sh build.sh
Utilisation des specs internes.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-mageia-linux-gnu/8.3.1/lto-wrapper
Cible : x86_64-mageia-linux-gnu
Configuré avec: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --with-pkgversion='Mageia 8.3.1-0.20191101.1.mga7' --with-bugurl=https://bugs.mageia.org/ --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++ --enable-linker-build-id --build=x86_64-mageia-linux-gnu --host=x86_64-mageia-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --with-linker-hash-style=gnu --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-ssp --disable-libssp --disable-libffi --disable-werror --with-isl --with-python-dir=/lib/python2.7/site-packages --enable-lto
Modèle de thread: posix
gcc version 8.3.1 20191101 (Mageia 8.3.1-0.20191101.1.mga7) 
version dev
definition -DDEBUG_TOOL
target -march=native
Building minic_dev_linux_x64
-s -Wall -Wno-char-subscripts -Wno-reorder -DDEBUG_TOOL -DNDEBUG -O3 -flto -march=native --std=c++14
minic.cc:3574:10: erreur fatale: tbprobe.h : Aucun fichier ou dossier de ce type
 #include "tbprobe.h"
          ^~~~~~~~~~~

[xr_a_y]

You have to clone Fathom is a directory named Fathom inside Minic.

[xr_a_y]

simply

Code: Select all

git clone https://github.com/jdart1/Fathom.git

inside Minic directory

[Roland Chastain]

Compilation successful. Thank you!

[Alayan]

the problem is that you release so frequently, it's difficult to keep up to date with the testing.
Not a criticism, just saying.

It's better when authors make a distinction between regular dev builds and releases that are meant to be tested. Even when giving a version number to all commits, like Ethereal and Xiphos, having some being considered "special" and with official binaries help to get all rating lists to consistently test the same version. Because such releases are not too frequent, they are not skipped by testers.

If the engine is improving very fast, more frequent releases are acceptable, but usually at least 3 months and at least 15 elo gain between releases is best.

Not providing any such special releases and asking testers to pick a dev-build when it pleases them is impractical. For example, Demolito is a good engine that progresses regularly, but it has no release versions whatsoever. In the end, everybody tests it with different versions, and with the date numbering scheme one has to look at the commits history to know if the changes between two dates are significant or not. It's just bad.

I'm not an engine tester, but I've been charting some data and not having a clear release scheme makes it more complicated.

[xr_a_y]

the problem is that you release so frequently, it's difficult to keep up to date with the testing.
Not a criticism, just saying.

It's better when authors make a distinction between regular dev builds and releases that are meant to be tested. Even when giving a version number to all commits, like Ethereal and Xiphos, having some being considered "special" and with official binaries help to get all rating lists to consistently test the same version. Because such releases are not too frequent, they are not skipped by testers.

If the engine is improving very fast, more frequent releases are acceptable, but usually at least 3 months and at least 15 elo gain between releases is best.

Not providing any such special releases and asking testers to pick a dev-build when it pleases them is impractical. For example, Demolito is a good engine that progresses regularly, but it has no release versions whatsoever. In the end, everybody tests it with different versions, and with the date numbering scheme one has to look at the commits history to know if the changes between two dates are significant or not. It's just bad.

I'm not an engine tester, but I've been charting some data and not having a clear release scheme makes it more complicated.

Totally agree. That is more or less my practice and what I explain on Minic github front page. In the repository Minic-Dist I give every builds but i only release as github release on the main repo substential elo gain or important hug fix.

[Alayan]

You've had a rate of over one release per week since the beginning of the year. Even with about half of your dev-versions not being made into releases, that's still a huge amount of releases, no tester can hope to test all of your official releases.

Also, your versioning scheme doesn't help to differentiate these releases from normal dev versions. With Xiphos bumping the middle version number, or Eth now doing a release every 25 commits, it's more obvious.

If I had to give release-for-testing guidelines, it would be something like this :

Code: Select all

Less than 1 month : never except for bugfixes
1 to 1.5 months : 100+ elo
1.5 to 2 months : 50+ elo
2 to 3 months : 30+ elo
3 to 6 months : 20+ elo
Over 6 months : 15+ elo (looking at you, Komodo)

Major features such as FRC can replace some elo.