New engine releases & news 2021

[mvanthoor]

Sorry. Accidental double post.

[mvanthoor]

Notice: Alpha 2 release retracted due to a massive bug in saving moves in the transposition table. (Saving the wrong move while doing a beta-cutoff.) I'll have to fix this first, and then retest.

[amanjpro]

A new version of Zahak (https://github.com/amanjpro/zahak/releases/tag/0.3.0)
fixes some issues with UCI, and small bug fixes. This version should be some 40 ELO points stronger too

[Frank Quisinsky]

Hi there,

MrBob 1.0.0
https://github.com/bobsquared/Mr_Bob_Chess/

Scorpio 3.0.12
https://github.com/dshawul/Scorpio/releases (have a look to the end of the site, update history started with 3.0.1)

A lot of updates from Nibbler GUI in the last days.
Current version 1.7.4

For Java based engines:
J.D.K 16.0.0 (I am working with 15.0.1, later 15.0.2 is available).
15.0.2 and 16.0.0 not tested with latest java based engines like: Bagatur, chess22k, pirarucu and others
https://www.oracle.com/de/java/technolo ... loads.html

Best
Frank

[abulmo2]

I released Amoeba 3.3 today on github:
https://github.com/abulmo/amoeba/releases/tag/v3.3
Version 3.3 is just a compilation of small code enhancements, simplifications and bug fixes. I expect it to be about 30 Elo stronger than Version 3.2 and I hope you will enjoy using it.

OOPS !
I just saw I miscompiled the Windows executables, no popcount and no pgo were used. This oversight should probably cost enough ELO to make this executables not much stronger than version 3.2. I fixed that and the released zip file now contains faster executables. I am sorry for the inconvenience.

[Werner]

Thanks Richard ,
much faster now...

[mvanthoor]

The release for Rustic Alpha 2 has been republished:

https://github.com/mvanthoor/rustic/rel ... ag/alpha-2

Binaries have been added for Rustic Alpha 1.1, which fixes the omission of taking GUI overhead into account in MoveTime mode:

https://github.com/mvanthoor/rustic/rel ... /alpha-1.1

For rating list testers: If you don't use MoveTime mode (i.e., 5 seconds per move), there's no need to test Alpha 1.1.

Thanks to mar and emadsen for the sparring thread regarding the transposition table. That made finding the problem easier than expected

[Gabor Szots]

The release for Rustic Alpha 2 has been republished:

Thanks Marcel. I guess the incredible speed increase is due to using hash tables, isn't it?

[mvanthoor]

Thanks Marcel. I guess the incredible speed increase is due to using hash tables, isn't it?

Yes, but also because of the hash move ordering.

The TT itself (cutting on finding exact positions) gives about 116 Elo, and the hash move ordering provides another 50 Elo. The bug that caused me to retract the Alpha 2 release broke hash move sorting. I could have put that into the next release and/or fixed the bug there of course. It would just have split the rating increase over two releases; but I was just in time to remove the buggy release.

In my own gauntlets against 10 other engines in the 1650-1900 range, Alpha 2 performs +165 Elo over Alpha 1. In self-play, head-to-head, Alpha 2 is +200 Elo stronger than Alpha 1 (but self-play is not really a useful measure for rating lists). Here's the rating list, with the gauntlet included (rc6 is now the release version, rc5.1 is the one with the bug). The list is calculated with BayesElo and calibrated against Alpha 1's current CCRL rating.

Code: Select all

Rank Name			Elo    +    - games score oppo. draws
   1 Clueless 1.4		1874   43   42   200   60%  1789    8%
   2 Deepov 0.4			1854   40   40   200   58%  1789   20%
   3 Rustic Alpha 2 rc6		1843   18   18  1000   59%  1773   18%
   4 Pigeon 1.5.1		1824   38   38   200   55%  1789   35%
   5 Wukong JS 1.4		1824   40   40   200   54%  1789   17%
   6 CDrill Build 4		1801   42   41   200   51%  1789   11%
   7 Rustic Alpha 2 rc5.1	1793   23   23   600   57%  1741   20%
   8 TSCP 1.81			1742   41   41   200   44%  1789   13%
   9 Celestial 1.0		1730   40   41   200   43%  1789   17%
  10 Shallow Blue 2.0         	1708   41   42   200   40%  1789   14%
  11 FracTal 1.0		1706   38   39   200   38%  1789   35%
  12 Rustic Alpha 1           	1677   23   24   600   42%  1741   19%
  13 Mizar 3                  	1667   41   43   200   34%  1789   15%
  14 MinimalChess 0.3         	1582   40   41   200   29%  1735   25%

1677 -> 1843 is a 166 Elo improvement.

I've decided to implement together if they naturally go together, such as "hash table + hash move sorting", "killer heuristic + history heuristic" (alpha 3) and "aspriation window + PVS" (alpha 3, or alpha 4, depending on how much the rating increases with the killers and history heuristic.)

I have no idea what the killer/history heuristics are going to add; neither do I know for aspiration windows and PVS. We'll see.

[mvanthoor]

Thanks Marcel. I guess the incredible speed increase is due to using hash tables, isn't it?

Oops. You said "speed increase" instead of "strength increase". I misread that. Sorry.

The engine hasn't actually become faster; as said in the changelog, it counts nodes differently now.

- Count all nodes visited, instead of only nodes which generated moves.

Before, it counted only the nodes it actually searched: the ones where the engine generates moves and then goes through the move list. Nodes that are only visited without moves being searched (for whatever reason; tt cut-offs, move sorting, etc) where not counted.

I was told that's not the standard way of doing things; I should be counting nodes visited, even if it's only created, entered, and then abandoned immediately for whatever reason. So, I moved the node counter up: from just after the move generation, to directly under "depth == 0" where the engine goes into quiescence search. That counts all nodes, but prevents nodes where the QSearch starts being counted twice. I did the same for QSearch: moving the counter up from just under the move generation, to the beginning of QSearch, so even a node left because of stand-pat gets counted.

In short:

Before: count only nodes where moves are generated.
Now: count all nodes ever visited, even if they're abandoned right after being visited with no work done (this happens with hash cuts, prunings, etc... that sort of thing).

So it's a counting difference, not a speed difference.