Andscacs - New version 0.921 with source

[jdart]

I think forfeit is a reasonable rule in this case.

With UCI you could in principle resubmit the previous position and request another search after an illegal move, but I don't think any GUIs are set up to do that. And of course there is the chance you'd still get another illegal move on re-search.

--Jon

[Uri Blass]

I think forfeit is a reasonable rule in this case.

With UCI you could in principle resubmit the previous position and request another search after an illegal move, but I don't think any GUIs are set up to do that. And of course there is the chance you'd still get another illegal move on re-search.

--Jon

I think that it is a good idea for future tournaments to design GUI that is set up to do it.
Of course you cannot change the rules of an existing tournament but I do not like the fact that a program lose by a single illegal move.

I guess that if the bug is not reproducable restarting the engine after the first illegal move and giving the engine the game again is not going to produce another illegal move.

[MikeB]

Thanks!!

As promised , a clang complied version that is a tad faster than the previous macOS exe's. But the most important aspect of this is thattehse should run all Mac with popcnt machines and better.

I dropped the original makefile from SF and went with Fabein Letouzey's Senpai 2 Makefile as the base, It was just easier for me to work with.

Here's the secret to building a PGO version. First let me just describe my system, I do not use Apple's macOS clang . Instead I use use Macports to install clang 5.0:

Code: Select all

Mac-Pro:~ michaelbyrne$ clang --version
clang version 5.0.0 (tags/RELEASE_500/final)
Target: x86_64-apple-darwin17.3.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-5.0/bin

In te makefile, you find these 4 lines:

Code: Select all

CXXFLAGS += -Os -msse3 -Ofast -O3 -mtune=native -mpopcnt -fprofile-instr-use=andscacs.profdata #-mbmi2 -DBMI 
LDFLAGS  += -O3 -fprofile-use  (2nd RUN)


#CXXFLAGS += -Os -msse3 -Ofast -O3 -mtune=native -mpopcnt -fprofile-instr-generate #-mbmi2 -DBMI  1st RUN
#LDFLAGS  += -O3 -fprofile-instr-generate

use the bottom two ( uncomment) to build the instrumented exe
from the terminal (must be from terminal) :

FIRST:

Code: Select all

make clean
make-j 

THEN

Code: Select all

andscacs
go depth 20

you really don't have to much more , this will get about 99% of the potential optimIzations

NEXT:

Code: Select all

llvm-profdata merge -output=andscacs.profdata *.profraw ( you will see this line in the makefile just a reminder of what the command is)
rm *.o

THEN:
comment out the two bottom lines and uncomment the two top lines above

followed by:

Code: Select all

make -j

there you go , you have a PGO version of Andscacs

source, updated makefile and macOS exe's included - adjust debug.h as appropriate for OS

https://www.dropbox.com/s/d0vwitxzt2cqg ... 7.zip?dl=1

the only line of code of the changes that I made which might be macOS specific only is line 85 of hash.cpp :

Code: Select all

	memhash = calloc(sizeof(unahash), xx);  // for macOS
	//	memhash = aligned_alloc(sizeof(unahash), xx); for Linux

All the other changes were to fix the clang errors related to the "goto jump that bypassed variable initialization" , the simple solution was to split the definition+initialisation into a definition + assignment and the error message goes away.

I will be working on a makefile that does the entire pgo build with one command - for both Senpai and Andscacs - two of my favorite engines 👍

[Dariusz]

It's working!!

Thank you Mike )

[cdani]

Many thanks!! I added it all to the zip file.

[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.