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.

[свернуть]

[Кевин]

И SMP-тест пройден!
https://tests.stockfishchess.org/tes...6c451633a9a162

Надо же: один за другим сразу два успешных поисковых тюнинга прошли.

[Владимир001]

Stockfish and CorChess development builds compiled by I. Ivec

June 13, 2020

[Vizvezdenec]

Цитата: Сообщение от Кевин

И SMP-тест пройден!
https://tests.stockfishchess.org/tes...6c451633a9a162

Надо же: один за другим сразу два успешных поисковых тюнинга прошли.

Рекорд по-моему 4 подряд успешных тюнинга констант проходных в зависимости от ранга.
Причём число игр в тюнинге было 250к - 500к - 500к - миллион и все на длинном временном (это именно сколько тюнилось, патчи проходили быстрее)

[dew]

Очень хотелось бы сейчас знать количество киловатт в час сейчас на фиштесте

[dew]

На фиштесте прям фиерия с идеями, патчами и воркерами )

[Кевин]

https://tests.stockfishchess.org/tes...586124bc2c10ad
А вот и ещё один успешный патч!

[Кевин]

Author: xoto10
Date: Mon Jun 15 08:05:16 2020 +0200
Timestamp: 1592201116

Retuned values after eval quantize patch.

The last search tune patch was tested before the implementation of #2733 which
presumably changed the search characteristics noticeably. Another tuning run was
done, see https://tests.stockfishchess.org/tes...6c451633a9a08c
and the updated values passed these tests:

STC:
LLR: 2.93 (-2.94,2.94) {-0.50,1.50}
Total: 34352 W: 6600 L: 6360 D: 21392 Elo +2.43
Ptnml(0-2): 581, 3947, 7914, 4119, 615
https://tests.stockfishchess.org/tes...6c451633a9a15f

LTC 60+0.6 th 1 :
LLR: 2.97 (-2.94,2.94) {0.25,1.75}
Total: 11176 W: 1499 L: 1304 D: 8373 Elo +6.06
Ptnml(0-2): 69, 933, 3403, 1100, 83
https://tests.stockfishchess.org/tes...6c451633a9a147

SMP LTC 20+0.2 th 8 :
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 54032 W: 6126 L: 5826 D: 42080 Elo +1.93
Ptnml(0-2): 278, 4454, 17280, 4698, 306
https://tests.stockfishchess.org/tes...6c451633a9a162

Closes https://github.com/official-stockfis...fish/pull/2742

Bench 4957812

https://abrok.eu/stockfish/

[Rom77]

FastGM только что выложил на Талкчесс замечательный тест по масштабированию Стокфиша и Комодо на большое количество ядер, ну и на гипертрейдинг заодно:
http://talkchess.com/forum3/viewtopi...=74188#p847345

Я думаю результаты стоят того, чтобы частично скопировать их сюда:

Цитата:

AMD Ryzen Threadripper 3990X, 64 cores, 128 threads
Komodo 14 POPCNT vs Komodo 14 POPCNT, default, 128 MB Hash, TC = 10 + 0.1 sec, 3000 games
Stockfish 11 POPCNT vs Stockfish 11 POPCNT, default, 128 MB Hash, TC = 10 + 0.1 sec, 3000 games

Komodo 14
Threads   2 vs 1   4 vs 2   8 vs 4   16 vs 8   32 vs 16   64 vs 32   128 vs 64
Elo         78       74       59        43        25         33           4
Draw %      67.7     68.8     72.9      77.5      81.0       80.9        84.4

Stockfish 11
Threads   2 vs 1   4 vs 2   8 vs 4   16 vs 8   32 vs 16   64 vs 32   128 vs 64
Elo         91       81       66        49        46         47          14
Draw %      58.8     62.6     67.9      72.4      73.7       76.0        79.8

[alchemist888]

Жаль, что нельзя провести такое же для вменяемых контролей, например блиц, или рапид. Вот там-то преимущества скалинга будут наиболее актуальны.

[sergey1963]

- лет 5 назад проводилось- плавное затухание 2-4-8-16ядер по сравнению с 1-2-4-8 и по 2 минуты на ход- 45, 36, 29, 23эло...
- также и по времени провели 8ядер- 1с, 8с, 1м, 8м на ход- один к одному по эло- 45, 36, 30...

[Maratka]

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

Жаль, что нельзя провести такое же для вменяемых контролей, например блиц, или рапид. Вот там-то преимущества скалинга будут наиболее актуальны.

Кто сказал, что нельзя? Вопрос в ядрах!
На минуте тестировалось, правда 1000 (вроде бы партий), но динамика вполне понятна.

По графику: видно, что рост максимальный с 1 до 2 ядра, и с 2 на 4. Дальше оно выходит на более-менее линейную зависимость, по мере роста ядер, и резко падает при включении виртуальных ядер. Но и там рост есть. Т.е. польза от HT имеется. Все остальное от лукавого

[Rom77]

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

Жаль, что нельзя провести такое же для вменяемых контролей, например блиц, или рапид. Вот там-то преимущества скалинга будут наиболее актуальны.

Я думаю сам характер кривых не изменится. Уменьшатся только сами величины. Может быть раза в два, как на этом, уже достаточно давнем тесте (здесь масштабируется время, а не потоки):

http://www.fastgm.de/time-control4.html

[Maratka]

Ну так и будет. Это достаточно очевидно.
Можно попросить TCEC'овцев запустить SF сам против себя на 43 ядра (старая система) и 176 потоков (новая). Должно выйти ~50 Elo, вот и проверим.

В конце концов, я конечно не против 4-х турниров за год, но в целом - это перебор, тут мы ловим блох, вида "SF за квартал достаточно планово развивался, и набрал ~15 Elo, у LZ вроде бы застой" - т.е. итог прогнозируем при тех же дебютах. Другое дело, если и у LZ сеть обновиться.

Ну а т.к. очень вероятно, что не обновится - то почему бы не провести бонус (благо там нужно платить всего-то за один сервер).

[sergey1963]

а зачем? - ну вы и даете стране угля!
- у каждого сегодня есть 4-8ядер- вот и проверьте- 1-2-3-4 или 1-2-4-8 против 1 ядра, также и со временем- 4 или 8 ядер по 1 секунде на ход, затем 8с, 1 минута, 8 минут...
- масштабирование на УКК проходит- потому что его там... нет- мы тестируем процессор, а не связку ОЗУ- кэш-3 процессора...

[Maratka]

Затем, что не у всех 1-2-4-8 ядрер, как у Вас (4 вроде)?

Есть проф-шахматисты, где и 32 не редкость, и им оно важно - что они получат при замене на 64, с возможность запуска 128 потоков (тот самый Ryzen TR)?

А может лучше видеоплату для LZ взять, да не одну?

___
Т.е. им таки нужны такие тесты: 4 RTX купить за в общем-то обычную месячную зарплату, как во многих странах - это проблема?
А вот и систему на 64+ ядер и много видео - уже дорого.

[sergey1963]

для слепых- написал же- на 4 ядрах можно проверить зависимость 1ядро против 2-3-4ядер... чего непонятного для программиста?
мы вообще ищем- есть затухание или нет... дальше можно промасштабировать...
PS- самое слабое место процессора- его выход на ОЗУ- тут начинаются чудеса и если вынуждены ждать 2 ядра, то 32- тем более...

[Maratka]

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

для слепых- написал же- на 4 ядрах можно проверить зависимость 1ядро против 2-3-4ядер... чего непонятного для программиста?
мы вообще ищем- есть затухание или нет... дальше можно промасштабировать...

Так затухание может быть, но быть заметно позже, скажем после 128 ядер (упрется в скорость доступа к таблицам, где даже весьма шустрые SSD и контроллеры для SSD не понянут столько потоков, обращающихся к ним одновременно). Ну а если достаточно полные семифигурки - то совсем даже очень запросто!

[sergey1963]

процессору плевать на ССД или ХДД- он берет данные с ОЗУ, но вот успеют ли они загрузится с диска во время вынужденного простоя проца- другой вопрос, и еще- ядра лезут в таблицу по очереди 2 ядра- это одна очередь, 64- сооовсем другая очередь...

[Maratka]

Если подключены таблицы - движок будет их ждать, в любом случае.

Вот как реализована схема, вида "считаем что есть, а потом, в асинхронном режиме подтягиваем таблицы, и пересчитываем", или "нет оценки, пока нет данных с таблиц", а может третье, вида "оцениваем по шестифигуркам, и ставим предварительную оценку по ним, потом ждем (если контроль позволяет) данных с семифигурок, и если позволяет - то пересчитаем, иначе используем оценку с шестифигурками - то уже вопрос к разработчикам, причем весьма сомневаюсь, что Vizvezdenec сможет помочь (насколько в курсе, он вообще не работал с кодом, где завязаны таблицы).

Отсюда и провал скорости при доступе к таблицам, находящимся на HDD (который на пару порядков медленнее самых дохлый SSD). Но это легкий случай, а так вообще и разница между SSD есть весьма заметная.

[sergey1963]

это уже давно решено в играх- тройным кэшированием- быстрый ССД- ОЗУ- более быстрая память видеокарты (из-за количества контактов)...
- в адвансе же иногда лучше вообще отключить таблицы, особенно 7-фигурки- зачем они при 20 фигурах?
- помню вы как-то смеялись над двойным-то кэшированием, хотя Самс и примо-кэш это делают даже для корпораций...

[Maratka]

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

это уже давно решено в играх- тройным кэшированием- быстрый ССД- ОЗУ- более быстрая память видеокарты (из-за количества контактов)...

Это не решено: средненький SATA-SSD вполне обслуживает средненький 6-12 поточный процессор. Выше, для 8-12-16 ядер уже нужен nvme, причем не самый дохлый, и это для шестифигурок.

Для полных семифигурок (что на уровне серверов вполне доступно по деньгам, ибо сама платформа недешево тянет) SAS-12 (этакий аналог SATA4, который не был принят) будут задыхаться даже при 5-6 устройств в массиве RAID0.

Упор банальный: лучшие контроллеры массивов обеспечивают ~ миллиона IOPS, т.е. нет возможности наращивания скорости случайного доступа к таблицам путем увеличения количества "дисков" в массиве, ибо лучшие SSD дают ~200 тыс IOPS.

Почему? Потому что каждый поток инициализирует в силу своей рандомности разную последовательность ходов и ответов на его ходы, т.е. сосет разные данные с таблиц.

[sergey1963]

- для вас не решено- для игроманов- нормально- ведьмак идет на ура...
- полные 7-фигурки- 8тб, их можно сократить в 3-4 раза (зачем нам 5ферзей против голого короля?)
- йопс- для лохов, нормальные люди берут скорость случайного чтения при 4кб- плохой ХДД-0,5мбс, хороший- 1,5, плохой ССД- 15, хороший- 60, оптэйн- 200, ОЗУ на ддр4- 2000... ну и посчитайте скорость загрузки Ф+п---Л+С+п- 30гб
- двойное (и тройное) кэширование- это не ваш смех, а хорошо просчитанное взаимодействие данных в цепочке- ХДД- ССД-ОЗУ, а в играх еще и ОЗУ видеокарты- которое гораздо быстрее ОЗУ ПК...
- пример- храним 2тб 7-фигурок на ССД (а где еще?), часть из наиболее запрашиваемых 52гб хранится прямо в кэше ССД-ОЗУ, само ОЗУ в 64гб распределено- 2 гб на ОС, 2-резерв, 8- хэш движка (с оценками без таблиц), 52- на кэширование с ССД...
- вот и получается 8гб ОЗУ (а точнее- L-3кэш процессора) обращается к самому себе за данными, хранящимися в 52гб, но требуемых периодически и все время обновляемых с 2тб ССД...

[Владимир001]

CorChess: Updated June, 15 2020 .
For Windows, Linux and Android (NOT UPDATED), NO MACOS!

Changelog:

- Adjust history threshold for quiet moves futility pruning
- Quantize eval to multiples of 16
- Tuned values for search constants
https://chess.massimilianogoi.com/download/corchess/

[Maratka]

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

- йопс- для лохов, нормальные люди берут скорость случайного чтения при 4кб

Вообще говоря IOPS базово затеряемся как раз на 4K

[Vizvezdenec]

Ну мы делали похожий тест и наблюдали примерно +20 эло на 192 ядра -> 384 потока.
Но там было 60+0.6, т.е. может быть повезло, а может и временной контроль влияет как-то, тут судить сложно - тут только омегазиро смогла бы вывести какие-то закономерности, я не берусь что-то утверждать, помимо того, что "прирост есть". Кстати говоря, у Комодо его фактически нет, я теперь понимаю, почему они не просят себе ставить гипертрейдинговые ядра обязательно.
Ну из данных графиков можно заключить, что стокфиш прилично лучше работает с мультипроцессингом, что и неудивительно - натура LazySMP такая, что он расширяет дерево поиска, соответственно, движок, который сам по себе его делает более узким, должен с этого больше получать, более того, у нас есть специальные эвристики за авторством Вонделе и моей последующей доработкой (которая, кстати, была уже после 11 релиза, так что тут её нет), которые дают искусственное сужение дерева поиска в зависимости от числа используемых ядер, т.е. этот эффект делают ещё сильнее.

[Владимир001]

Stockfish and CorChess development builds compiled by I. Ivec

June 15, 2020

[sergey1963]

Vizvezdenec, не надо лукавить 192 дополнительных потока дали 20 эло при 1 минуте на партию??? И что- вон в тестах Бурконтовка при 0,1с на ход четко +80 эло получается при каждом удвоении ядер- ура? или не совсем?, а теперь поставьте 1мин на ход- дай бог 20 получить от просто ядер, а уж про НТ- промолчим.
Еще раз- в тестах УКК до часа на партию (по одной минуте на ход) вы тестируете сам процессор, в адвансе же мы встречаемся с хэшем ОЗУ и эндшпильными таблицами, а при наличии более 64 ядер- еще и со "странностями винды". Процессор большую часть просто простаивает в ожидании ответа от таблиц или гигантского хэша и разница даже от учетверения минимальная, т.е. 16 ядер дай бог будут хуже 64 при 1 минуте на ход на 20 эло.
Это прекрасно видно просто установкой хэша- 16гб- скорость разительно отличается от 16мб, без таблиц вообще- также. А ведь- чем больше ядер- тем больше должен быть и хэш... Тут нужен оптимум именно при УДК- т.е. даже не минуте а часе на ход. Такие тесты проводились и разницы между хэшем 1гб и 8 гб на 8 ядерном проце не было совсем... Да это и понятно- 64 ядра найдут выигрывающее продолжение за 10 минут (если оно есть), 4 ядра- за час- разницы в адвансе- никакой, от слова совсем... НО 64 ядрам нужно и хэш в 16!!! раз больше, а уж про стоимость проца и "периферии"- промолчим- там уже и не в 16 раз... а поболе будет...

[Asunta]

Какой бы ни был хэш ( 1Gb или 64Gb ) - во время SF-анализа всё равно наступает критический момент,
когда этот хэш заполняется на 100%... 1Gb хватает примерно для глубины Depth( 30 .. 32 )
Потом движок начинает подтормаживать, т.к. свободной памяти нет и нужно выискивать "менее ценные"
данные, чтобы на их место записать что-то свежее.. Это как бы ( момент #1 )...

Но есть ещё и ( момент #2 ), до которого пользователь доходит редко.. Это когда на очень большой
глубине движок вынужден перетряхивать хэш несколько раз ( или несколько десятков раз )
Т.е. размер хэша уже не позволяет нормально продолжить анализ, т.к. "менее ценные" данные настолько
свежи, что их замена ещё более свежими прямо или косвенно анализ исказит...

Для простоты можно взять ( начальную позицию, 1 ядро, хэш 1Gb ) и рвануть в бесконечность...
На глубине D45..D50 торможение будет очевидным, а до глубины D60..D65 можно добежать через месяц...
Или вообще не добежать : )

Если мы настроились на анализ до глубины, скажем, Depth(50) - хэша в 16Gb будет достаточно,
чтобы он не успел заполниться на 100% и мы не увидели торможение из ( момента #1 )
На глубине D50 конфигурация ( 1 ядро / 16Gb ) вполне может конкурировать с ( 4 ядра / 4Gb ),
т.к. 4Gb заполняются на 100% уже при D38..D40 и последующие 10 полуходов до D50 будут анализироваться
медленно...

[sergey1963]

Немного сумбурно- но в принципе правильно- не надо мерять просто ядра процессора с почти отсутствующим хэшем ОЗУ- если измеряем для адванса- меряем глубину за 4, 8, 16 минут (минимальная последовательность- больше 1 минуты, но меньше 1 часа) на 1, 2, 3, 5 ядрах без гипертрейдинга, без эндшпильных таблиц (т.е. максимальное количество ядер процессора минус 1 ядро, в котором и решаются задачи ОС), например такая позиция-
с виду безобидная, сыгранная гросом в очном турнире (для знатоков- мы сковали жертвой ладьи ферзя и слона соперника, но ценой своего ферзя- смотрим на оставшиеся фигуры- 2 слона и ладья против 2 ладей и слона- это видит и Сток- оценка-не в пользу черных- как подтянуть резервы?- пресловутый нулевой ход, но наш-черных- 2 хода подряд- слоны- никак- ладья-о!- если поставить ее перед ферзем- все- каюк- белым- мат... дальнейшее для человека проще- находим после идеи правильную подстановку ходов, с прогой- сложнее- она этого не понимает, но считает на 3 порядка лучше...)

r5k1/p1pb2bp/3p3r/P1pPp1p1/2B1Pq2/1R2QPp1/1P4PP/5RBK b - - 0 1

вот и смотрим- досчитается ли 1 ядро 1гб хэш, 2-2, 3-3 за 3-6-12 минут- достигнутая глубина без таблиц- 9 измерений на 4 ядернике, 15- на 6, 21- на 8... затухание производительности от количества ядер будет сразу видно... свои результаты выложу в теме железа...

[Maratka]

Пешечный патч:

https://tests.stockfishchess.org/htm...e8aec816ab756a