HekaStockfish 0.9

[majkelnowaq]

@Ovyron ok, I uploaded those files. Heka with timing is based on older dev version (middle of 2019?). If anyone would like to test them - has to have strong hardware and a lot of time, because they were designed for longer time controls. Anyway I think these files (especially sources) ll be more useful for programmers interested in presearch function than for end users.

https://www23.zippyshare.com/v/EEIIEboT/file.html
https://wrzucplik.pl/pokaz/1974408---d39u.html

[Ovyron]

Thank you, will check them out.

[MikeB]

@Ovyron ok, I uploaded those files. Heka with timing is based on older dev version (middle of 2019?). If anyone would like to test them - has to have strong hardware and a lot of time, because they were designed for longer time controls. Anyway I think these files (especially sources) ll be more useful for programmers interested in presearch function than for end users.

https://www23.zippyshare.com/v/EEIIEboT/file.html
https://wrzucplik.pl/pokaz/1974408---d39u.html

thanks again - looking very promising!

[MikeB]

For those interested, I have kicked off a 1000 game match between current dev Stockfish ( with large pages) versus current dev Stockfish with the new 'profound' code based on presearched. I have discovered an interesting phenomena with presearch , the longer the tome control, the bigger the value presearch should be.

In this case, the games are 10 min with 6 sec increment - 10x longer than Fishcooking LTC of 1 min 6 sec games.
For my system, the profound value for 5 min 3 sec games was about 9600. I expect the best value for 10 min 6 sec games with a single thread would be some where between 20k and 25k. We shall see. As you increase the profound value, the 2 min and 1 sec results get worse and worse
, but the longer time control games get better and better - I have never seen anything like this before.

Running a test over the next 10 hours and it will either be succesful or a total flop ,we shall see. If I see it going well in the AM, I just need about 5 hrs sleep on most nights), I will post links here so that you can follow the results as games are completed and get the pgn files.

[Ovyron]

For my system, the profound value for 5 min 3 sec games was about 9600. I expect the best value for 10 min 6 sec games with a single thread would be some where between 20k and 25k. We shall see. As you increase the profound value, the 2 min and 1 sec results get worse and worse
, but the longer time control games get better and better - I have never seen anything like this before.

I have... in centaur play

I wonder if this is the beginning of the end, if a high enough profound value could eventually find moves that can NOT be improved by a human, anybody playing correspondence chess could set it and wait and get them automatically, putting the final nail on the coffin of the sport.

If this happens, well, we had a good run. This is looking like what I was fearing, the ultimate equalizer.

[MikeB]

For my system, the profound value for 5 min 3 sec games was about 9600. I expect the best value for 10 min 6 sec games with a single thread would be some where between 20k and 25k. We shall see. As you increase the profound value, the 2 min and 1 sec results get worse and worse
, but the longer time control games get better and better - I have never seen anything like this before.

I have... in centaur play

I wonder if this is the beginning of the end, if a high enough profound value could eventually find moves that can NOT be improved by a human, anybody playing correspondence chess could set it and wait and get them automatically, putting the final nail on the coffin of the sport.

If this happens, well, we had a good run. This is looking like what I was fearing, the ultimate equalizer.

Some links

results: https://www.dropbox.com/s/0ujbxu4rllz4m ... a.txt?dl=0

pgn: https://www.dropbox.com/s/q2a80tcjjkjgq ... d.pgn?dl=0

A special experimental one off windows exe compiled for a threadripper machine with large pages - a source link will be provided upon request:
email mich*** spelled the normal way , byrne 1978 @ gmail dot com - ( cryptic to foil bots). Please give me 24 hours to respond:
https://www.dropbox.com/s/5bw0w71une4qx ... 20.7z?dl=0 This link will be removed in less than 24 hours.

Edit: the code is quite invasive to the search function, although not a lines of code, the search explodes the bench node count signature up to nearly 7 M nodes up from 5 million - one reason why this version sucks at bullet chess - this version is for games 10 minutes plus 6 seconds incrment or longer - will not perform to expectations with shorter time controls.. The true Heka version has a much higher bench node signature , but it also has many other changes which I haven't really study yet - I'm really just looking at presearch now , and even that is way more limited than what Heka already has.

[Ovyron]

a source link will be provided upon request

Thanks, I'm requesting a source link.

I've been doing experiments myself for analysis of correspondence games, it's very interesting that you can get powerful results even if you swap the "<"/">" signs of presearch for an opposite effect, so instead of starting at MultiPV and switching to SinglePV it starts at SinglePV and switches to MultiPV. I wonder if the optimal implementation would have going back and forth in an intelligent manner, because this switching is better than always SinglePV (in finding batter moves) or always MultiPV (it reaches those multilines much faster at the depth surpassing the node count.)

[MikeB]

a source link will be provided upon request

Thanks, I'm requesting a source link.

I've been doing experiments myself for analysis of correspondence games, it's very interesting that you can get powerful results even if you swap the "<"/">" signs of presearch for an opposite effect, so instead of starting at MultiPV and switching to SinglePV it starts at SinglePV and switches to MultiPV. I wonder if the optimal implementation would have going back and forth in an intelligent manner, because this switching is better than always SinglePV (in finding batter moves) or always MultiPV (it reaches those multilines much faster at the depth surpassing the node count.)

earlydeep branch https://github.com/MichaelB7/Stockfish/ ... lydeep.zip

[Ovyron]

Thanks Mike! These are exciting times for analysis!

[MikeB]

Thanks Mike! These are exciting times for analysis!

latest test results getting better
all games 8 mi n with 4.8 sec inc

Code: Select all

Current date : time (EDST)
Date: 03/21/20 : 11:16:30
Rank Name              Rating   Δ     +    -     #     Σ    Σ%     W    L    D   W%    =%   OppR 
---------------------------------------------------------------------------------------------------------
   1 Honey-dev-032120   3554   0.0   11   11   683  347.5  50.9   63   51  569   9.2  83.3  3548 
   2 Stockfish-032120   3552   1.7   11   11   684  345.5  50.5   71   64  549  10.4  80.3  3549 
   3 Stockfish-031420   3544   8.7   11   11   683  332.0  48.6   58   77  548   8.5  80.2  3553 
---------------------------------------------------------------------------------------------------------

https://www.dropbox.com/s/po89jovub1qcf ... a.txt?dl=0

https://www.dropbox.com/s/po89jovub1qcf ... a.txt?dl=0

only change from most recent source above:

Code: Select all

@@ -621,7 +621,7 @@ int ct = int(ctempt) * (int(Options["Contempt_Value"]) * PawnValueEg / 100); //
 #ifdef Add_Features
   int profound = 0;
   if (Options["Profound"]) {
@@ -621,7 +621,7 @@ int ct = int(ctempt) * (int(Options["Contempt_Value"]) * PawnValueEg / 100); //
 #ifdef Add_Features
   int profound = 0;
   if (Options["Profound"]) {
-      profound = 750 * pow(2, int(Options["Profound"]));
+      profound = 2000 * pow(2, int(Options["Profound"]));
       sync_cout << "profound: " << profound <<sync_endl;
     }
   //sync_cout << "Contempt MG: " << dctcp  << sync_endl;// for debug

MichaelB7@
+      profound = 2000 * pow(2, int(Options["Profound"]));
       sync_cout << "profound: " << profound <<sync_endl;
     }
   //sync_cout << "Contempt MG: " << dctcp  << sync_endl;// for debug

other settings tested and failed:

profound = 375 * pow(2, int(Options["Profound"]));
profound = 1125 * pow(2, int(Options["Profound"]));
profound = 1500 * pow(2, int(Options["Profound"])); about even
profound = 1825 * pow(2, int(Options["Profound"])); got worse
profound = 2400 * pow(2, int(Options["Profound"])); bad

I have seen this before where steady increases - can go:
better , better , top, worse, worse
or oscillates:
better worse better worse better worse - this function oscillates , so by the time I am done, the best line of code could be nowhere near where I am at right now

Edit - once you have identified an oscillating pattern, and after about 10/12 runs, one can estimate as to where the next peak should be and then you start testing estimated peak values - so my next test will be around 3200 or - at it appears to be about 1200 or so difference in peaks