Andscacs - New version 0.921 with source

[syzygy]

As the bug happened in only one move situation,

It seems Andscacs performed a 3-ply search which correctly found Kh4 as only move, but then picked the move it had just played.
https://pastebin.com//fvyc06hY

This suggests to me that Andscacs picked a move from a lazy search thread which had not yet been properly initialised and still had the old move (and perhaps the old score and depth) in its PV data structure.

If this is indeed what happened, then the solution is to reset the various thread-specific data structures in the main thread before starting the actual search.

But I am only speculating. My Catalan is not yet at a level that allows me to fully understand your code

[syzygy]

I noticed that my Linux compile of Andscacs starts to use cpu once I set it to 6 threads:

Code: Select all

$ ./andscacs 
Andscacs 0.921 by Daniel Jose
uci
id name Andscacs 0.921
id author Daniel Jose
option name Ponder type check default false
option name Hash type spin default 128 min 1 max 65536
option name Clear Hash type button
option name NullMove type check default true
option name MultiPV type spin default 1 min 1 max 100
option name Threads type spin default 1 min 1 max 128
option name AlwaysFullPv type check default false
option name Contempt type spin default 0 min -100 max 100
option name WinGroupAffinity type check default false
option name NeverClearHash type check default false
option name HashFile type string default hash.hsh
option name SaveHashtoFile type button
option name LoadHashfromFile type button
uciok
setoption name Threads value 6
isready
readyok

Now "top" shows about 20% CPU usage for Andscacs.

This may of course just be a problem of the Linux version.

[syzygy]

It seems you're letting threads sleep by repeatedly calling Sleep(1) on Windows and nanosleep(&ts, NULL) on Linux.

The ts timespec struct is initialised to 1000ns, so that means it wakes up every microsecond. You probably meant to set it to 1,000,000ns, which is 1ms.

Sleep(1) corresponds to a 1ms sleep. So each thread still wakes up 1000 times per second.

I think you should seriously consider changing this.

[cdani]

As the bug happened in only one move situation,

It seems Andscacs performed a 3-ply search which correctly found Kh4 as only move, but then picked the move it had just played.
https://pastebin.com//fvyc06hY

This suggests to me that Andscacs picked a move from a lazy search thread which had not yet been properly initialised and still had the old move (and perhaps the old score and depth) in its PV data structure.

If this is indeed what happened, then the solution is to reset the various thread-specific data structures in the main thread before starting the actual search.

But I am only speculating. My Catalan is not yet at a level that allows me to fully understand your code

Thanks!! Yes, is what I thought. I will solve this bug soon and publish the changed code and new compiles.

[cdani]

It seems you're letting threads sleep by repeatedly calling Sleep(1) on Windows and nanosleep(&ts, NULL) on Linux.

The ts timespec struct is initialised to 1000ns, so that means it wakes up every microsecond. You probably meant to set it to 1,000,000ns, which is 1ms.

Sleep(1) corresponds to a 1ms sleep. So each thread still wakes up 1000 times per second.

I think you should seriously consider changing this.

Thanks!! I will change this also. My knowledge of linux C stuff is not good, and I replicated the windows instruction thinking that was the same.

[syzygy]

It seems you're letting threads sleep by repeatedly calling Sleep(1) on Windows and nanosleep(&ts, NULL) on Linux.

The ts timespec struct is initialised to 1000ns, so that means it wakes up every microsecond. You probably meant to set it to 1,000,000ns, which is 1ms.

Sleep(1) corresponds to a 1ms sleep. So each thread still wakes up 1000 times per second.

I think you should seriously consider changing this.

Thanks!! I will change this also. My knowledge of linux C stuff is not good, and I replicated the windows instruction thinking that was the same.

But you should also the change the Windows implementation. If the engine is not searching, the search threads should really block until it is the engine's turn. On Windows you can use a primitive like WaitForSingleObject().

[cdani]

But you should also the change the Windows implementation. If the engine is not searching, the search threads should really block until it is the engine's turn. On Windows you can use a primitive like WaitForSingleObject().

I see. I will do it. But such change will be for next version.

[MikeB]

But you should also the change the Windows implementation. If the engine is not searching, the search threads should really block until it is the engine's turn. On Windows you can use a primitive like WaitForSingleObject().

I see. I will do it. But such change will be for next version.

In C++11, you can do this with standard library facilities:

Code: Select all

#include <chrono>
#include <thread>

std&#58;&#58;this_thread&#58;&#58;sleep_for&#40;std&#58;&#58;chrono&#58;&#58;milliseconds&#40;1&#41;);

in the snap shot below you can see the after (top) and before (bottom)



Since this change it pretty simple - you might want to make it now

you have three places to change this in analysis.cpp:

Code: Select all

#ifdef LINUX
               //nanosleep(&ts, NULL);  
	        std::this_thread::sleep_for(std::chrono::milliseconds(1));
#endif

also I think this will work under windows as well - so it's should be a code simplification as well

[syzygy]

In C++11, you can do this with standard library facilities:

Code: Select all

#include <chrono>
#include <thread>

std&#58;&#58;this_thread&#58;&#58;sleep_for&#40;std&#58;&#58;chrono&#58;&#58;milliseconds&#40;1&#41;);

But that should not be used when the engine is not searching at all but waiting for its opponent to move.

In particular if two engines are playing each other on the same machine, it is not correct for one engine to continuously wake up while the other engine is searching.

[Ras]

In particular if two engines are playing each other on the same machine, it is not correct for one engine to continuously wake up while the other engine is searching.

In my implementation, there is one thread blocking on stdin, and another thread (which would search if it were the engine's turn) polling on an internal queue, waking up every 10 ms. The Windows task manager shows "00" (in percent) for CPU usage, which is why I didn't bother to use OS specific proper blocking.