Single core?

[Gabor Szots]

I have noticed and also read recently (and in the past as well) that some engines use not only the dedicated number of threads but also some threads more to serve for additional tasks. This, allegedly, does not make them multi-threaded because the search is done by one single thread only.
However, if the supplementary threads are always or most of the time active, they do reserve cores which consequently cannot be used by other engines. E.g. with one such engine thus using 2 cores I will be forced to run one tournament less, otherwise the PC will be overwhelmed by the engines' demand.
Of course I cannot force authors to construct their engines so that they use additional threads only sparingly (e.g. for polling input only every now and then), that is their decision. However, to save resources, I will be forced to reject testing those engines, at least while I don't have a PC with much more cores than my current one (which has 4).

Recently we could persuade Walleye author to restrict his engine to less frequent polling (you can see our converstion at his github page) and I am in the hope that other authors will follow suit.

[jdart]

It is pretty common to allocate an extra thread for input polling, but it would be unusual for that thread to consume significant CPU resources. In most cases I think you can ignore it - it is not affecting performance.

[mvanthoor]

I have noticed and also read recently (and in the past as well) that some engines use not only the dedicated number of threads but also some threads more to serve for additional tasks. This, allegedly, does not make them multi-threaded because the search is done by one single thread only.

Yes. With regard to chess playing, they're single-threaded.

However, if the supplementary threads are always or most of the time active, they do reserve cores which consequently cannot be used by other engines. E.g. with one such engine thus using 2 cores I will be forced to run one tournament less, otherwise the PC will be overwhelmed by the engines' demand.

If a thread is not doing an active task, i.e. it waiting for input, it should use 0% cpu. You can see this with Rustic. If you start it on the command line, and then look at the task manager, you'll see it uses no processor power. If a thread is continuously active, even when waiting, it's done wrong.

Of course I cannot force authors to construct their engines so that they use additional threads only sparingly (e.g. for polling input only every now and then), that is their decision. However, to save resources, I will be forced to reject testing those engines, at least while I don't have a PC with much more cores than my current one (which has 4).

A thread should never _poll_ for input. It should _ wait_ for it.

Recently we could persuade Walleye author to restrict his engine to less frequent polling (you can see our converstion at his github page) and I am in the hope that other authors will follow suit.

In that case, Walleye (which is written in Rust) is doing it wrong. The engine should use sender/receiver channels between threads. As soon as a thread hits the "channel.recv()" function, it will be halted there, and only continue itś main thread loop when something is sent to this channel. (By another thread's sender, obviously.)

This is how Rustic works, and therefore it can have 4 threads (main/engine, search, input, output) and still use 0% cpu when not calculating a move. As soon as a command comes in ("go", for example), the input thread wakes up, sends the command to the engine thread, and it goes to sleep again. On reception of the command, the engine thread wakes up, and in the case of "go", it kicks off the search thread... and then goes back to sleep again, waiting for input. When the search is running, it will send statistics to the engine thread, which will send them out to the gui through the output thread, but that takes... what... 0.0001% of CPU power. When Rustic sends stats, it wakes up the engine and output thread in sequence, once every two seconds. In current-day computers, two seconds is almost an eternity.

When Rustic is searching, you'll see that it uses ~25% of a 4-core cpu. (Or 12.5% if you have 8 logical cores.)

Multi-threaded engines that poll for input are doing it incorrectly. If you poll, you could just as well just do it in the search itself.

It is pretty common to allocate an extra thread for input polling, but it would be unusual for that thread to consume significant CPU resources. In most cases I think you can ignore it - it is not affecting performance.

It will affect performance if the author actively polls for input in a while (!quit) {...} loop, instead of blocking the loop to wait for input.

[jdart]

It will affect performance if the author actively polls for input in a while (!quit) {...} loop, instead of blocking the loop to wait for input.

Arasan uses select (Linux/Mac) with a timeout, or ReadFile (Windows), which are blocking functions. Just in a separate thread.

[Carlos777]

I just tested Rustic Alpha 3.0 and it does not use more than 16.7% of 100% (meaning just use 1 out of 6 cores).

[mvanthoor]

As said... Rustic uses 12.5% (12-13%) of a CPU with 8 logical cores when searching; as it should be. If a current-day engine uses more than its fair share of cpu power, then it's doing something incorrectly with regard to threading. As John says, it should use a blocking function to get input.

I just tested Rustic Alpha 3.0 and it does not use more than 16.7% of 100% (meaning just use 1 out of 6 cores).

Thanks for confirming If you set up a 32 MB TT, it should also use exactly 32 MB + 3-4 MB for the engine itself.

[Carlos777]

WallEye, Caffenaited Pawn, Seggz, LittleThought and Lynx use from 16.7% to 27% (old versions of WallEye,Seggz) to 38 or 50% sometimes (LT) or in some ocassion 95% (Lynx)

[mvanthoor]

WallEye, Caffenaited Pawn, Seggz, LittleThought and Lynx use from 16.7% to 27% (old versions of WallEye,Seggz) to 38 or 50% sometimes (LT) or in some ocassion 95% (Lynx)

Jeez... that makes Lynx basically impossible to test.

[Carlos777]

WallEye, Caffenaited Pawn, Seggz, LittleThought and Lynx use from 16.7% to 27% (old versions of WallEye,Seggz) to 38 or 50% sometimes (LT) or in some ocassion 95% (Lynx)

Jeez... that makes Lynx basically impossible to test.

Not all the time, but sometimes Lynx does that. It's very irregular in the use of the cpu.

[amanjpro]

WallEye, Caffenaited Pawn, Seggz, LittleThought and Lynx use from 16.7% to 27% (old versions of WallEye,Seggz) to 38 or 50% sometimes (LT) or in some ocassion 95% (Lynx)

Jeez... that makes Lynx basically impossible to test.

Not all the time, but sometimes Lynx does that. It's very irregular in the use of the cpu.

Lynx is written in C# and probably this thread you are seeing is garbage collector thread. Which is part of the language.

Good chess engines should almost never awaken garbage collector. Counter, Zahak, minimal chess, Combusken are all written in garbage collected languages, but I bet they never awaken it... So they are essentially using one CPU for search only