Linux friendly engines at all levels

[mhouppin]

Stash should cover a wide zone of your 2000-2700 Elo range, and very easy to build on Linux: https://gitlab.com/mhouppin/stash-bot

Acording to CCRL 40/4 ratings and personal testing:

Code: Select all

v21.0: 2720 Elo
v20.4: 2630 Elo (commit hash: 2056f46e)
v20.0: 2530 Elo
v18.0: 2440 Elo
v17.0: 2350 Elo
v16.0: 2290 Elo
v15.0: 2230 Elo
v14.0: 2100 Elo
v13.0: 2030 Elo
v12.0: 1970 Elo

[hgm]

Does it really makes sense to revive a nearly 2 year old thread?

[D Sceviour]

Does it really makes sense to revive a nearly 2 year old thread?

It depends on the thread. This popular thread has almost 6000 views, so it has obviously been researched by others. The "Linux friendly" topic title makes it useful for others to look for information from a search. It is a good spot to add further engine information.

The last version of Schooner2.2 has Linux capability.

[mvanthoor]

I think that if you take care not to use Windows-specific things in an engine, any engine should be able to run on Linux.

Actually, it's 'best' (IMHO) to write an engine as if on Linux, even if you're running on Windows. If you compile with GCC or Clang under MSYS2 and it works, it should compile on Linux. If you wriite your engine in Visual Studio and/or use Visual C++, you may have problems compiling the engine with GCC or Clang on Linux later.

Personally, I have never written an embedded piece of software or a command-line program using Visual C++; I've always preferred GCC under MSYS2. I don't have a lot of experience with Clang, but I assume that if a program compiles under Clang in MSYS2, it'll compile in Linux, assuming one is not deliberately doing Windows-specific stuff.

[hgm]

In my engines reading the clock is typically platform dependent. I would not know how to do it in a way that works both on Windows and Linux. Things like shared memory (between processes) also need platform-dependent system calls.

[Joost Buijs]

In my engines reading the clock is typically platform dependent. I would not know how to do it in a way that works both on Windows and Linux. Things like shared memory (between processes) also need platform-dependent system calls.

With a modern C++ compiler (C++11 and later) you can use the <chrono> header, this should be platform independent. For shared memory between processes you still need an external library like boost (or to write your own code).

Why do you want to use processes for a chess engine anyway? Nowadays C++ has a pretty platform independent thread-library, very convenient to use.

[mvanthoor]

In my engines reading the clock is typically platform dependent. I would not know how to do it in a way that works both on Windows and Linux. Things like shared memory (between processes) also need platform-dependent system calls.

Something such as GCC on MSYS2 can compile software that uses POSIX-threads to run on Windows. I assume that almost anything that uses POSIX-compatible system calls on Linux can be compiled under MSYS2 for Windows, as MSYS2 is designed for that. (MSYS2 is started as a fork of Cygwin, but in such a way that it doesn't need the external library cygwin1.dll.)

And, as Joost says, there are options in C++11, and in Boost as well; probably not in bare C. (I wouldn't know: I've cheated a lot in the past by writing "C++" programs that were basically C programs that used the C++ Stdlib and Boost...)

[IanKennedy]

I think that if you take care not to use Windows-specific things in an engine, any engine should be able to run on Linux.

Actually, it's 'best' (IMHO) to write an engine as if on Linux, even if you're running on Windows. If you compile with GCC or Clang under MSYS2 and it works, it should compile on Linux. If you wriite your engine in Visual Studio and/or use Visual C++, you may have problems compiling the engine with GCC or Clang on Linux later.

Personally, I have never written an embedded piece of software or a command-line program using Visual C++; I've always preferred GCC under MSYS2. I don't have a lot of experience with Clang, but I assume that if a program compiles under Clang in MSYS2, it'll compile in Linux, assuming one is not deliberately doing Windows-specific stuff.

I'm currently working in VIsual Studio 2019 and cross-compiling and testing in Ubuntu/gcc once a day to ensure its still 100% portable. I don't want to waste time testing something in Windows that I'm going to have to bin because it won't port.

[hgm]

With a modern C++ compiler (C++11 and later) you can use the <chrono> header, this should be platform independent. For shared memory between processes you still need an external library like boost (or to write your own code).

Why do you want to use processes for a chess engine anyway? Nowadays C++ has a pretty platform independent thread-library, very convenient to use.

My engines are not written in C++. And my C compiler (3.4.4) does not support C++11.

I only have one engine that uses SMP, and using processes was a simple way to implement it without extensive changes to the code. With threads I woud have had to split up all global variables (such as board and piece list) into arrays, so that each thread would have its own instance. That would have been a lot of work, and I only had 10 hours to do it. (The duration of a flight to Japan.) It was much simpler to just change the function that allocates the hash table to one that allocates shared memory, and fork off multiple processes all using that memory for hash table.

@mvanthoor - I am using gcc under Cygwin, and there you can use POSIX functions too. But then your program can only run on machines that have the Cygwin1.dll installed. Which is not standard, so you would have to distribute it with your engine. And it measures about 2MB. I like to distribute my engines as single (~40KB) executables, without users having to install all kind of libraries. So I just use the Windows API.

[Ras]

probably not in bare C.

C11 has threading support with the goal of being compatible with C++11 - minus templating of course.

And my C compiler (3.4.4) does not support C++11.

It's not like GCC costs money, so updating it after 15 years doesn't sound too far-fetched.

For my engine, I'm using C99 without threading support, but I encapsulate the platform specific stuff and use some ifdefs. Compared to using Posix functions via MingW (no Cygwin DLL), the Windows executable size shrinks by some 30kB, and I can look up the Win API directly to be sure what I'm doing.