A few days ago I released Winter 0.3. The version that played in TCEC was a bit weaker than the release version, maybe 20 Elo. Some interesting Winter games from TCEC S14 division 4 are given at the bottom. Here is an overview of some of the changes between Winter 0.2 and 0.3.
Awesome logo thanks to Kan from TCEC. Thanks again!
Self play on 1 core improved by around +120 Elo.
Android executable may be released at a later date. Originally I planned to have Android support for this release, but I am not particularly motivated for that at the moment.
Winter now supports multithreading.
Lazy SMP with helpers skipping depths like in Wasp and Ethereal. Furthermore Winter perturbs root move ordering in helper threads stochastically.
Due to time constraints, I took a look at how Stockfish implemented its threadpool. My implementation was inspired by it and ended up being very similar.
Score of Winter 0.3RC1 64c vs Winter 0.3RC1 32c: 113 - 75 - 212 [0.547] 400
Elo difference: 33.11 +/- 23.33
Time management adjusted to use more time earlier and use less time if PV move stays constant at root.
Nodes counted differently. Count should be higher than in TCEC version, however there seems to be a significant slowdown since first SMP version which I have not recognized the source of.
Clustering algorithm changed from Gaussian Mixture Model to Fuzzy C-Means
Paper: Bezdek, J.C., Ehrlich, R. and Full, W., 1984. FCM: The fuzzy c-means clustering algorithm. Computers & Geosciences, 10(2-3), pp.191-203.
Fuzzy C-Means is a more direct generalization of tapered eval. In fact with the right choice of parameters we could implement tapered eval via Fuzzy C-Means.
This was done after the version participating in TCEC and is the primary functional difference to that version.
Still using 4 centroids, this performed more or less on par with 3 centroids, but better than 2 centroids.
Now relying on just piece sums and l2 norm. No longer takes distance between kings or material differences into account.
LMR is now even more agressive, significantly more than SF.
Captures now effected by LMR, but at reduced rate.
Improved move sorting
Weights differ based on whether or not player is in check
Passed pawns taken better into account
Added Counter Move Heuristic (not history)
PVS changes
Full Window PVS is done until depth 4
Initial window size is now based on a rough score standard deviation estimation, except if previous scores contain a mate score.
Selective depth was removed during SMP implementation and has been added back after TCEC version.
TT entry is now 16 bytes
Cleaned up code.
Some comments. Shoutout to Andrew Grant (Ethereal) and SF dev team in this regard, they do this very well and are something to aspire to in this regard.
Clustering code has been separated from eval function. This is much more generic and modular than it previously was.
Eval training has been separated from evaluation.cc where it was misplaced. Still have to do the same for the search param training.
Executable is now self contained. There are no longer separate files for evaluation and search param weights.
On my PC Winter 0.3 had load errors under Fritz 15 so I had to transfer the tournament to the Shredder 13 GUI. Still, using the engine simultaneously with a game I play often, I frequently get multiple messages of 'waiting for engine Winter..." when activating the Shredder window, and have to wait some time till a new game is started. Not particularly troublesome but inelegant. I have to say that I expreienced the same behaviour on the part of some other engines too.
I don't know if this is due to the size of the executable or some other thing.
Thanks anyway, I am in the hope I can confirm your optimism regarding playing strength improvement.
Gabor Szots wrote: ↑Sun Dec 16, 2018 9:41 pm
On my PC Winter 0.3 had load errors under Fritz 15 so I had to transfer the tournament to the Shredder 13 GUI. Still, using the engine simultaneously with a game I play often, I frequently get multiple messages of 'waiting for engine Winter..." when activating the Shredder window, and have to wait some time till a new game is started. Not particularly troublesome but inelegant. I have to say that I expreienced the same behaviour on the part of some other engines too.
I don't know if this is due to the size of the executable or some other thing.
Thanks anyway, I am in the hope I can confirm your optimism regarding playing strength improvement.
Very interesting. Unfortunately I don't have access to either software at the moment, so I can't easily investigate this on my own. If you notice anything else like, that I would be very grateful for the information!
Gabor Szots wrote: ↑Sun Dec 16, 2018 9:41 pm
On my PC Winter 0.3 had load errors under Fritz 15 so I had to transfer the tournament to the Shredder 13 GUI. Still, using the engine simultaneously with a game I play often, I frequently get multiple messages of 'waiting for engine Winter..." when activating the Shredder window, and have to wait some time till a new game is started. Not particularly troublesome but inelegant. I have to say that I expreienced the same behaviour on the part of some other engines too.
I don't know if this is due to the size of the executable or some other thing.
Thanks anyway, I am in the hope I can confirm your optimism regarding playing strength improvement.
Very interesting. Unfortunately I don't have access to either software at the moment, so I can't easily investigate this on my own. If you notice anything else like, that I would be very grateful for the information!
EDIT: How many cores were you running it with?
I am running it on 1 core, 2 of the remaining 3 cores are running other tournaments and the 4th core is left for other things.
The thing seems to happen only while I am also playing a game (an Everett Kaser puzzle in this case). Maybe running other software would cause the same thing but I haven't tried.
jorose wrote: ↑Sun Dec 16, 2018 9:23 pm
Due to time constraints, I took a look at how Stockfish implemented its threadpool. My implementation was inspired by it and ended up being very similar.
You don't need a thread pool. Stockfish over engineered in this area. Simply create/join searching threads, as done in Demolito, or Ethereal, for example (and many others I'm sure).
You should start with the KISS approach, until you can measure that a more complex alternative is better. I strongly doubt that the SF logic is measurably better (ie. wake up threads sleeping on condition variable instead of just creating them).
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
