Andscacs - New version 0.921 with source

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

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
syzygy
Posts: 4255
Joined: Tue Feb 28, 2012 10:56 pm

Re: Andscacs - New version 0.921 with source

Post by syzygy » Sat Nov 11, 2017 5:52 pm

cdani wrote: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
Posts: 4255
Joined: Tue Feb 28, 2012 10:56 pm

Re: Andscacs - New version 0.921 with source

Post by syzygy » Sat Nov 11, 2017 6:26 pm

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
Posts: 4255
Joined: Tue Feb 28, 2012 10:56 pm

Re: Andscacs - New version 0.921 with source

Post by syzygy » Sat Nov 11, 2017 6:36 pm

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.

User avatar
cdani
Posts: 2047
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Andscacs - New version 0.921 with source

Post by cdani » Sat Nov 11, 2017 7:03 pm

syzygy wrote:
cdani wrote: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.

User avatar
cdani
Posts: 2047
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Andscacs - New version 0.921 with source

Post by cdani » Sat Nov 11, 2017 7:05 pm

syzygy wrote: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
Posts: 4255
Joined: Tue Feb 28, 2012 10:56 pm

Re: Andscacs - New version 0.921 with source

Post by syzygy » Sat Nov 11, 2017 7:20 pm

cdani wrote:
syzygy wrote: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().

User avatar
cdani
Posts: 2047
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Andscacs - New version 0.921 with source

Post by cdani » Sat Nov 11, 2017 7:29 pm

syzygy wrote: 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.

User avatar
MikeB
Posts: 2527
Joined: Thu Mar 09, 2006 5:34 am
Location: Pen Argyl, Pennsylvania

Re: Andscacs - New version 0.921 with source

Post by MikeB » Sat Nov 11, 2017 11:42 pm

cdani wrote:
syzygy wrote: 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)

Image

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&#40;&ts, NULL&#41;;  
	        std&#58;&#58;this_thread&#58;&#58;sleep_for&#40;std&#58;&#58;chrono&#58;&#58;milliseconds&#40;1&#41;);
#endif
also I think this will work under windows as well - so it's should be a code simplification as well

syzygy
Posts: 4255
Joined: Tue Feb 28, 2012 10:56 pm

Re: Andscacs - New version 0.921 with source

Post by syzygy » Sun Nov 12, 2017 11:55 am

MikeB wrote: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
Posts: 951
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: Andscacs - New version 0.921 with source

Post by Ras » Sun Nov 12, 2017 12:07 pm

syzygy wrote: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.

Post Reply