Stockfish и его производные

[Харлампий]

Stockfish 14
Stockfish 14 для Android
https://ufile.io/f/8ardx
https://pixeldrain.com/l/ndVpnHXc#item=1

Архив предыдущих версий: https://www.dropbox.com/sh/75gzfgu7q...UfHbBr4r_RwhGa

Официальный сайт стокфиш

Обновления тестовых версий стокфиша: http://abrok.eu/stockfish/

Сборки Stockfish и CorChess от I. Ivec

Развитие движка http://tests.stockfishchess.org/tests

Stockfish_NNUE https://github.com/nodchip/Stockfish

Сети: https://www.comp.nus.edu.sg/~sergio-v/nnue/

AsmFish

Сборки от Maratka

Компиляции движков от ChessMan

Сборка Stockfish от Otodranik

Sugar от Marco Zerbinati

Shark и Orka

О Stockfish

Цитата:

Авторы движка
Двигатель Stockfish был разработан Tord Romstad, Marco Costalba и Joona Kiiski. В настоящее время он развивается и поддерживается сообществом Stockfish.

Авторы приложений
Stockfish для Mac был собран Daylen Yang. Stockfish для iOS был собран Tord Romstad.

История
Проект Stockfish начался с движка Glaurung с открытым исходным кодом, созданного Tord Romstad. В ноябре 2008 года Марко Косталба разветвил код Glaurung 2.1 и представил Stockfish 1.0. Торд и Джоона Кииски присоединились к проекту «Стилфиш», и проект «Гларунг» постепенно исчез. Тем временем, Stockfish быстро поднялся, чтобы стать самым сильным шахматным движком с открытым исходным кодом, с частыми обновлениями каждые несколько месяцев. Сегодня он остается одним из самых сильных двигателей в мире.

О GPL
Stockfish является бесплатным и распространяется в соответствии с GNU General Public License Version 3 (GPLv3). По сути, это означает, что вы можете делать практически все, что хотите, с программой, включая ее распространение среди своих друзей, делая ее доступной для загрузки с вашего веб-сайта, продавая ее (либо самостоятельно, либо как часть некоторого более крупного программного пакета ) или использовать его в качестве отправной точки для собственного программного проекта.

Единственное реальное ограничение заключается в том, что всякий раз, когда вы каким-либо образом распространяете Stockfish, вы всегда должны включать полный исходный код или ссылку на исходный код. Если вы внесете какие-либо изменения в исходный код, эти изменения также должны быть доступны в GPL.

Для получения полной информации прочитайте GPL.

[свернуть]

[Кевин]

Author: protonspring
Date: Thu Jan 17 08:11:09 2019 +0100
Timestamp: 1547709069

Remove AdjacentFiles

This is a non-functional simplification that removes the AdjacentFiles array.
This array is simple enough to calculate that the pre-calculated array provides
no benefit. Reduces the memory footprint.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 74839 W: 16390 L: 16373 D: 42076 Elo +0.08
http://tests.stockfishchess.org/test...bc596a450cfb67

No functional change

http://abrok.eu/stockfish/

[Джонсон]

Насчёт позиции из атаки Кереса. Отнюдь не факт, что Kf8 в данном случае - это баг Стокфиша. Чисто по-человечески у этого хода есть свои резоны.

[byan_mivv]

Stockfish and CorChess development builds compiled by I. Ivec

January 17, 2019

http://chess.ultimaiq.net/stockfish.html

[lobkov62]

Уважаемые знатоки, прошу помочь разобраться. У меня стокфиш 10.
Если я минут 40-60 дал движку на анализ позиции, увидел какие хода наверняка лучшие (так часто бывает, что есть явные хода-лидеры по оценке) и просто на 1-2 хода пошел вперед по варианту, не прекращая анализ - стоит ли после этого перезагружать движок или информацию в кеше лучше сохранить?

возможно ли, что информация оставшаяся в кеше будет мешать верной оценке позиции при перемещении на 1-2 хода вперед?

[Кевин]

Author: Jonathan D
Date: Sun Jan 20 12:20:21 2019 +0100
Timestamp: 1547983221

Tweak initiative and Pawn PSQT (#1957)

Small changes in initiative(). For Pawn PSQT, endgame values for d6-e6 and d7-e7 are now symmetric. The MG value of d2 is now smaller than e2 (d2=13, e2=21 now compared to d2=19, e2=16 before). The MG values of h5-h6-h7 also increased so this might encourage stockfish for more h-pawn pushes.

STC
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 81141 W: 17933 L: 17777 D: 45431 Elo +0.67
http://tests.stockfishchess.org/test...bc5902bb5cf237

LTC
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 83078 W: 13883 L: 13466 D: 55729 Elo +1.74
http://tests.stockfishchess.org/test...bc5902bb5cff09

Bench: 3266398

http://abrok.eu/stockfish/

[Кевин]

Author: marotear
Date: Sun Jan 20 12:24:03 2019 +0100
Timestamp: 1547983443

Simplify pvHit (#1953)

Removing unnecessary excludedMove condition (there is not excluded move for PvNodes) and re-ordering computation.

Non functional change.


Author: protonspring
Date: Sun Jan 20 12:21:16 2019 +0100
Timestamp: 1547983276

Clean-up some shifting in space calculation (#1955)

No functional change.

http://abrok.eu/stockfish/

[zasada]

Author: protonspring
Date: Sun Jan 20 12:21:16 2019 +0100
Timestamp: 1547983276

Clean-up some shifting in space calculation (#1955)

No functional change.

[Кевин]

Author: Joost VandeVondele
Date: Sun Jan 20 19:14:24 2019 +0100
Timestamp: 1548008064

Simplify pondering time management (#1899)

stopOnPonderhit is used to stop search quickly on a ponderhit. It is set by mainThread as part of its time management. However, master employs it as a signal between mainThread and the UCI thread. This is not necessary, it is sufficient for the UCI thread to signal that pondering finished, and mainThread should do its usual time-keeping job, and in this case stop immediately.

This patch implements this, removing stopOnPonderHit as an atomic variable from the ThreadPool,
and moving it as a normal variable to mainThread, reducing its scope. In MainThread::check_time() the search is stopped immediately if ponder switches to false, and the variable stopOnPonderHit is set.

Furthermore, ponder has been moved to mainThread, as the variable is only used to exchange signals between the UCI thread and mainThread.

The version has been tested locally (as fishtest doesn't support ponder):

Score of ponderSimp vs master: 2616 - 2528 - 8630 [0.503] 13774
Elo difference: 2.22 +/- 3.54

which indicates no regression.

No functional change.

http://abrok.eu/stockfish/

[Кевин]

Author: protonspring
Date: Tue Jan 22 09:54:10 2019 +0100
Timestamp: 1548147250

Simplify TrappedRook

Simplified TrappedRook to a single penalty removing the dependency on mobility.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 106718 W: 23530 L: 23577 D: 59611 Elo -0.15
http://tests.stockfishchess.org/test...bc5902bb5d4131

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 54053 W: 8890 L: 8822 D: 36341 Elo +0.44
http://tests.stockfishchess.org/test...bc5902bb5d4d59

bench 3665090

http://abrok.eu/stockfish/

[Александр Руденко]

А кто знает , чем отличается Cfish от Cichess и cichess и corchesse 2.6 это одно и тоже ? А то столько много фишев что путаешся в них. И где можно скачать этот cichesse? Может он и есть корчесс 2.6.
А что лучше использовать эти движки ? Или все-таки стокфиш который каждый день обновляется. (Мне вот Напрмер понравился очень асмфиш , он правда только в декабре был. Но у него быстро набирается глубина , даже на старых компах и больше точная оценка позиции , и еще не знаю почему его все дают в аренду на плече когда их комп многоядерный берешь в пользование) да и я сам остановился на асмфише, но он давно не обновляется.
И чью компиляторы наших форомучан советуете ? (Маратка, отодранник или чессмен?)

[ChessMan]

Цитата: Сообщение от Александр Руденко

А кто знает , чем отличается Cfish от Cichess и cichess и corchesse 2.6 это одно и тоже ? А то столько много фишев что путаешся в них. И где можно скачать этот cichesse? Может он и есть корчесс 2.6.
А что лучше использовать эти движки ? Или все-таки стокфиш который каждый день обновляется. (Мне вот Напрмер понравился очень асмфиш , он правда только в декабре был. Но у него быстро набирается глубина , даже на старых компах и больше точная оценка позиции , и еще не знаю почему его все дают в аренду на плече когда их комп многоядерный берешь в пользование) да и я сам остановился на асмфише, но он давно не обновляется.
И чью компиляторы наших форомучан советуете ? (Маратка, отодранник или чессмен?)

CiChess это порт движка CorChess на язык "С".
Можно скачать в моих компиляциях: http://forchess.ru/showthread.php?p=41189#post41189
и http://forchess.ru/showpost.php?p=85274&postcount=776

Так как я не планирую в ближайшее время делать новые версии CiChess'a - советую использовать CorChess.

asmFish сильно устарел - примерно на полгода по сравнению со Стокфишем (декабрьская версия не содержит всех патчей со Стока).
В ближайшее время (может завтра???) появится новая версия - на ГитХабе уже обновились исходники, скорее всего разработчики делают какие-то тесты.

[ChessMan]

@Aster Вы как-то задали вопрос: почему СиФиш быстрее Стокфиша - думаю дело в более быстрой инициализации и, возможно, быстрее работает с оперативной памятью. А возможно и из-за языка программирования (не зря асмФиш самый быстрый)?

Во всяком случае, моё предположение о скорости инициализации не беспочвенны:

2 ГБ хэша



8 ГБ



16 ГБ



Может у кого другая разница в скорости?

Движки:
http://s000.tinyupload.com/index.php...50971985198600

=============
P.S.: В Аквариуме нет такой огромной разницы в скорости при 16 ГБ хэша и на 8-ми ядрах - Стокфиш инициализируется несколько секунд (на 2-3 секунды дольше чем СиФиш), затем скорость сразу "максимальная".
АсмФиш инициализируется практически мгновенно, но скорость стартует от 6-7 тыс и потом уже она становится выше чем у СиФиша и Стокфиша

[Кевин]

19-01-22 sni master
ELO: 13.98 +-1.8 (95%) LOS: 100.0%
Total: 40000 W: 6323 L: 4714 D: 28963
40000 @ 60+0.6 th 1 Regression/progression test against SF10 after "Simplify TrappedRook" of January, 22th

[Aster]

Цитата: Сообщение от ChessMan

@Aster Вы как-то задали вопрос: почему СиФиш быстрее Стокфиша - думаю дело в более быстрой инициализации и, возможно, быстрее работает с оперативной памятью. А возможно и из-за языка программирования (не зря асмФиш самый быстрый)?

Скорость меряется не скоростью аллокации памяти, ИМХО. Если она приемлемая, то проблемы будут только у самых экстремалов с 128гб памяти

ИМХО, билд тестер должен отображать тестирование скорости, и то что он включает в себя аллокацию памяти - не гуд

[ChessMan]

Цитата: Сообщение от Aster

Скорость меряется не скоростью аллокации памяти, ИМХО. Если она приемлемая, то проблемы будут только у самых экстремалов с 128гб памяти

ИМХО, билд тестер должен отображать тестирование скорости, и то что он включает в себя аллокацию памяти - не гуд

В командной строке Стокфиш также демонстрирует очень плохую скорость при большом хэше.

bench 16384 8 15



Cfish: bench 16384 8 15

[Chess762]

Цитата: Сообщение от lobkov62

возможно ли, что информация оставшаяся в кеше будет мешать верной оценке позиции при перемещении на 1-2 хода вперед?

Информация в хеше будет не мешать, а помогать верной оценки позиции.

[ChessMan]

@Vizvezdenec
Спасибо, что подняли на гитхабе вопрос на счет замедления Стокфиша.
Отмечу, что в моем случае это не из-за большого количества ядер, а из-за большого хэша.

На одном ядре:

[Vizvezdenec]

Ну я смотрел 4с и заметил, что первый ход идёт со скоростью 25-60 mnps в то время как остальные - 90+.

[ChessMan]

Цитата: Сообщение от Vizvezdenec

Ну я смотрел 4с и заметил, что первый ход идёт со скоростью 25-60 mnps в то время как остальные - 90+.

Это скорее всего тоже из-за большого хэша. Там вроде тоже 16 ГБ используют.

[ChessMan]

Кстати, если увеличить глубину в бенче, скажем bench 16384 8 20 - то скорость значительно возрастает.

[Кевин]

Author: Maciej Żenczykowski
Date: Tue Jan 29 17:26:24 2019 +0100
Timestamp: 1548779184

Use int8_t instead of int for SquareDistance[]

This patch saves (4-1) * 64 * 64 = 12KiB of cache.


STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 176120 W: 38944 L: 38087 D: 99089 Elo +1.69
http://tests.stockfishchess.org/test...bc593af5d4a7ce

LTC
As a pure speed up, I've been informed it should not require LTC.

No functional change

http://abrok.eu/stockfish/

[Кевин]

Author: Miguel Lahoz
Date: Tue Jan 29 17:32:41 2019 +0100
Timestamp: 1548779561

Change pinning logic in Static Exchange Evaluation (SEE)

This changes 2 parts with regards to static exchange evaluation.

Currently, we do not allow pinned pieces to recapture if *all* opponent
pinners are still in their starting squares. This changes that to having
a less strict requirement, checking if *any* pinners are still in their
starting square. This makes our SEE give more respect to the pinning
side with regards to exchanges, which makes sense because it helps our
search explore more tactical options.

Furthermore, we change the logic for saving pinners into our state
variable when computing slider_blockers. We will include double pinners,
where two sliders may be looking at the same blocker, a similar concept
to our mobility calculation for sliders in our evaluation section.
Interestingly, I think SEE is the only place where the pinners bitboard
is actually used, so as far as I know there are no other side effects
to this change.

An example and some insights:

White Bf2, Kg1
Black Qe3, Bc5

The move Qg3 will be given the correct value of 0. (Previously < 0)
The move Qd4 will be incorrectly given a value of 0. (Previously < 0)

It seems the tradeoff in search is worth it. Qd4 will likely be pruned
soon by something like probcut anyway, while Qg3 could help us spot
tactics at an earlier depth.

STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 62162 W: 13879 L: 13408 D: 34875 Elo +2.63
http://tests.stockfishchess.org/test...bc593af5d49c55

LTC: (Thanks to @alayant)
LLR: 3.40 (-2.94,2.94) [0.00,3.50]
Total: 140285 W: 23416 L: 22825 D: 94044 Elo +1.46
http://tests.stockfishchess.org/test...bc593af5d49ea8

Bench: 3937213


http://abrok.eu/stockfish/

[Кевин]

Author: DU-jdto
Date: Tue Jan 29 17:40:00 2019 +0100
Timestamp: 1548780000

Don't update pvHit after IID

This patch removes line 875 of search.cpp, which was updating pvHit after IID.
Bench testing at depth 22 shows that line 875 of search.cpp never changes the
value of pvHit at NonPV nodes, while at PV nodes it often changes the value
from true to false (and never the reverse). This is because the definition of
pvHit at line 642 is :

```
pvHit = (ttHit && tte->pv_hit()) || (PvNode && depth > 4 * ONE_PLY);
```

while the assignment after IID omits the ` (PvNode && depth > 4 * ONE_PLY) `
condition. As such, unlike the other two post-IID tte reads, this line of code
does not make SF's state more consistent, but rather introduces an inconsistency
in the definition of pvHit. Indeed, changing line 875 read

```
pvHit = (ttHit && tte->pv_hit()) || (PvNode && depth > 4 * ONE_PLY);
```

to match line 642 is functionally equivalent to removing the line entirely, as
this patch does.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 62756 W: 13787 L: 13746 D: 35223 Elo +0.23
http://tests.stockfishchess.org/test...bc5902bb5d4b75

LTC
LLR: 3.19 (-2.94,2.94) [-3.00,1.00]
Total: 61900 W: 10179 L: 10111 D: 41610 Elo +0.38
http://tests.stockfishchess.org/test...bc5902bb5d5d62

Bench: 3796134


http://abrok.eu/stockfish/

[Vizvezdenec]

Одно уменьшение кода, один небольшой элогейнер, одна небольшая ускорялка (на 200% уверен, что ей просто повезло, в Ethereal то же самое не прошло [0;4], да там и изменений-то - int на int_8).
Ну хоть что-то в общем-то

[Asunta]

Файл 2moves_v1.pgn более чем активно используется для тестов. Он включает более 40.000 случайных позиций
после двух ходов ( 4-х полуходов ). Позиции не спарены, т.е. если играть матч тупо по файлу, то одна из сторон вполне
может иметь преимущество долгое время. Есть надежда, что за счёт "случайности" позиций шансы постепенно подравняются,
что также ещё нужно доказать.

Возможно, дополнительные настройки в некоторых оболочках ( не всех! ) позволяют разыгрывать каждую позицию 2 раза
( белыми и чёрными ), что обеспечит РАВНЫЕ условия для участников матча в любой момент времени. Это важно, если 100.000 партий
набирают на 500 компьютерах ( по 200 партий на каждом ).

Если представить, что в первых 200 позициях из 2moves_v1.pgn есть перекос в пользу одной из сторон, то его можно помножить на 500 тестеров.
При этом тест может пройти абсолютное фуфло, которое попало в "правильную" сторону перекоса. Ну и наоборот. Что-то стоящее может быть
провалено.

Теперь вопрос. Почему нет файла со спаренными позициями ( пусть их будет 80.000 - какая разница ), который в любой оболочке и при любой
длине матча обеспечит ГАРАНТИРОВАННО РАВНЫЕ ШАНСЫ ( ? )

[Maratka]

Мне так думается, что на достаточно длинном отрезке партий из этой книги шансы сторон и так равны.
Во всяком случае, без всякого повтора за белых и черных, у меня совершенно нет уверенности, что
1. a4 h5 2. Na3 Na6 чем то сильно лучше или хуже, чем
1. h4 h5 2.Nh3 Nh6

[Asunta]

А почему не сделать ЖЕЛЕЗНО РАВНЫЕ ШАНСЫ ( ? )

Зачем анализировать 40.000 позиций, чтобы доказать отсутствие перекоса,
если можно просто разыграть их и белыми и чёрными ( !!! )


Например, в первых 50 позициях перевес на стороне того, кто играет 1-ю партию белыми
Если кто-то начнёт тестировать новую идею и получит со старта ( +2 =40 -8 ), то может
прекратить тест и не досмотреть кино до конца.

[Maratka]

Цитата: Сообщение от Asunta

Например, в первых 50 позициях перевес на стороне того, кто играет 1-ю партию белыми
Если кто-то начнёт тестировать новую идею и получит со старта ( +2 =40 -8 ), то может прекратить тест и не досмотреть кино до конца.

На 10 секундах и даже 3 потоках (в случае старых i5/i3) это займет минуты 4-5. Неужто подождать больше ну никак? ;)

[Asunta]

Стратегического ответа получено не было!

Вялые "тактические" отмазки.

[Maratka]

Стратегические вопросы нужно задавать составителям книг, и тем, кто их использует.
В Вашем случае например совершенно несложно составить книгу из 50 позиций со сменой сторон. Либо просто сыграть 100 партий в два круга (потребуется книга из 49 или 51 позиций).