A complete 2000 lines of code engine

Discussion of anything and everything relating to chess playing software and machines.

Moderators: Harvey Williamson, Dann Corbit, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
xr_a_y
Posts: 1338
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Thu Feb 27, 2020 9:31 pm

Graham Banks wrote:
Thu Feb 27, 2020 8:52 pm
xr_a_y wrote:
Thu Feb 27, 2020 8:21 pm
(but still stuck on the long TC ladder :oops: :oops: ... 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. :P
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.

User avatar
Roland Chastain
Posts: 442
Joined: Sat Jun 08, 2013 8:07 am
Location: France
Full name: Roland Chastain
Contact:

Re: A complete 2000 lines of code engine

Post by Roland Chastain » Fri Feb 28, 2020 9:01 am

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
Qui trop embrasse mal étreint.

User avatar
xr_a_y
Posts: 1338
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Fri Feb 28, 2020 9:10 am

Roland Chastain wrote:
Fri Feb 28, 2020 9:01 am
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

User avatar
Roland Chastain
Posts: 442
Joined: Sat Jun 08, 2013 8:07 am
Location: France
Full name: Roland Chastain
Contact:

Re: A complete 2000 lines of code engine

Post by Roland Chastain » Fri Feb 28, 2020 9:27 am

xr_a_y wrote:
Fri Feb 28, 2020 9:10 am
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"
          ^~~~~~~~~~~
Qui trop embrasse mal étreint.

User avatar
xr_a_y
Posts: 1338
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Fri Feb 28, 2020 10:47 am

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

User avatar
xr_a_y
Posts: 1338
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Fri Feb 28, 2020 11:21 am

simply

Code: Select all

git clone https://github.com/jdart1/Fathom.git
inside Minic directory

User avatar
Roland Chastain
Posts: 442
Joined: Sat Jun 08, 2013 8:07 am
Location: France
Full name: Roland Chastain
Contact:

Re: A complete 2000 lines of code engine

Post by Roland Chastain » Fri Feb 28, 2020 12:20 pm

Compilation successful. Thank you!
Qui trop embrasse mal étreint.

Alayan
Posts: 489
Joined: Tue Nov 19, 2019 7:48 pm
Full name: Alayan Feh

Re: A complete 2000 lines of code engine

Post by Alayan » Fri Feb 28, 2020 1:33 pm

Graham Banks wrote:
Thu Feb 27, 2020 8:52 pm
the problem is that you release so frequently, it's difficult to keep up to date with the testing.
Not a criticism, just saying. :P
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.

User avatar
xr_a_y
Posts: 1338
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Fri Feb 28, 2020 2:01 pm

Alayan wrote:
Fri Feb 28, 2020 1:33 pm
Graham Banks wrote:
Thu Feb 27, 2020 8:52 pm
the problem is that you release so frequently, it's difficult to keep up to date with the testing.
Not a criticism, just saying. :P
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
Posts: 489
Joined: Tue Nov 19, 2019 7:48 pm
Full name: Alayan Feh

Re: A complete 2000 lines of code engine

Post by Alayan » Fri Feb 28, 2020 3:39 pm

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.

Post Reply