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.

[свернуть]

[Maratka]

Самая быстрая ничья против LZ во-франзузской, что я видел, SF - белыми.


[Event "303 LZ 241 net 6xx vs SF_11+, Slow 75m+"]
[Site "?"]
[Date "2020.04.24"]
[Round "1.1"]
[White "Stockfish 220420 64 POPCNT"]
[Black "Lc0 v0.24.1+git.4b8acff"]
[Result "1/2-1/2"]
[ECO "C02"]
[Annotator "0.00;0.24"]
[PlyCount "44"]
[EventDate "2020.04.24"]
[EventType "tourn"]
[SourceTitle "Fritz Engine Tournament"]
[TimeControl "4500+30"]

{AMD FX-8370 Eight-Core Processor 4013 MHz W=45.9 plies; 7*463kN/s;
2*010*225 TBAs B=14.8 plies; 5kN/s} 1. e4 e6 2. d4 d5 3. e5 c5 {0.24/13 120} 4.
c3 {0.00/39 111} Bd7 {0.25/14 100 (Qb6)} 5. Be2 {0.38/37 163 (Nf3)} Nc6 {
0.25/13 142 (cxd4)} 6. Nf3 {0.22/38 78} Rc8 {0.25/14 112 (Nge7)} 7. O-O {
0.00/37 94} cxd4 {0.25/13 10} 8. cxd4 {0.00/40 73} Nge7 {0.26/15 46} 9. Nc3 {
0.00/38 50} Nf5 {0.24/14 103} 10. Bf4 {0.00/42 149 (Bg5)} a6 {0.17/13 177} 11.
Rc1 {0.13/41 37 (Qd2)} Be7 {0.13/16 108} 12. g4 {0.00/45 73 (Qd2)} Nh4 {
0.11/16 109} 13. Nxh4 {0.00/45 51} Bxh4 {0.12/14 55} 14. Na4 {0.11/44 60} Be7 {
0.08/14 121} 15. Nc5 {0.00/43 74 (Kg2)} Qb6 {0.00/15 195 (Bxc5)} 16. Nxd7 {
0.00/48 57} Kxd7 {0.03/14 74} 17. Be3 {0.00/50 54} Qxb2 {0.00/13 107} 18. Rb1 {
0.00/54 64} Qxa2 {0.00/10 87} 19. Ra1 {0.00/55 205} Qb2 {0.01/9 59} 20. Rb1 {
0.00/59 145} Qa2 {0.00/18 0} 21. Ra1 {0.00/57 90} Qb2 {0.00/17 0} 22. Rb1 {
0.00/61 115} Qa2 {0.00/2 264} 1/2-1/2

[Владимир001]

Stockfish and CorChess development builds compiled by I. Ivec

April 24, 2020

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

[Владимир001]

Stockfish Polyglot: Обновлено Avril, 25 2020 .

Список изменений:
- Исправлена ошибка флажка OwnBook
- Соответствие бета-версии Stockfish, имеющей временную метку 1586274421 - истории продолжения при проверке.

https://chess.massimilianogoi.com/download/stockfish/

[sergey1963]

Жила-была видеокарта 1080ti- вполне мощное решение с 3,6 тысяч ядер-cuda и производительностью в вычислениях при fp32- 11тф, Две таких видеокарты не смогли выйти в финал в 13 сезоне ТСЕС, у Стокфиша на 44-ядерном процессоре была производительность в вычислениях при fp32- 1тф, т.е. оказалось 22 к 1- для видеокарт- маловато.
С выходом 2080ti с 4,4 тысяч ядер-cuda и производительностью в вычислениях при fp32- 14тф было решено поставить 4 таких видеокарты против 88-ядерного процессора с производительностью 2тф, т.е 28 к 1. Казалось бы небольшое увеличение для производительности нейронных движков. НО... ДЬЯВОЛ КРОЕТСЯ В ДЕТАЛЯХ... в 2080ti появился режим работы fp16, что автоматически увеличило производительность вдвое до 112тф против 2тф у А-В движков... 56 к 1! Думаете это все? Как бы не так, все еще только начинается...
Сколько составляет восьмая часть от 4352 ядер-cuda? 544- скажете вы и будете совершенно правы- именно "незаметные" 544 тензорных ядра 2080ti способны работать с производительностью в вычислениях при fp16 с троекратной мощностью всех 4352 ядер-cuda- до 84тф... Т.о. только одна видеокарта 2080ti работает с производительностью в вычислениях при fp16- 112тф, четыре же таких бандуры выдают 448тф! Так производительность видеокарт изменилась с 22 к 1 до 28 к 1, затем с 56 к 1 до 224 к 1...
Теперь остановимся на "выдающейся победе" Альфа-Зеро над Стокфишем-8. Про железо А-З говорят скупо 4 "каких-то" ТПУ с 44-ядерным процессором. Все далеко не так просто, 4ТПУ- это вычислительные кластеры, состоящие только из тензорных ядер и если 4х 2080ti с 2176 тензорными ядрами управляются 2 ядрами процессора, то 44 ядерный процессор понадобится 50 тысячам тензорным ядрам с производительностью... 8 тысяч Тера-Флопс... У меня нет слов, а у вас?

[Maratka]

Занятная, 100% ничейная шестифигурка.
SF без таблиц, либо с пятифигурками оценивает ее 3.5 за понятно белых.

5b2/6rk/4Q3/8/4P3/8/4K3/8 w - - 0 68

Можно поправить, интересно?

[Vizvezdenec]

https://tests.stockfishchess.org/tes...08f6dd28f34ada
тест книги с закрытыми позициями.

[Кевин]

Да, в закрытых позициях Сток обрёл гораздо больше понимания, судя по тесту!

[Кевин]

А вот прошёл LTC комбо-патч из двух жёлтых патчей:

https://tests.stockfishchess.org/tes...08f6dd28f34bcb

[Vizvezdenec]

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

[sergey1963]

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

Занятная, 100% ничейная шестифигурка.
SF без таблиц, либо с пятифигурками оценивает ее 3.5 за понятно белых.

5b2/6rk/4Q3/8/4P3/8/4K3/8 w - - 0 68

Можно поправить, интересно?

Эта позиция сложнее, чем кажется с первого взгляда- при пешке на вертикалях а,в,с,д- выигрыш- увеличение рычага действия ферзя- короткая и длинные стороны, пешка доходит до 6 горизонтали, ферзь отдается за ладью, слон не успевает и король далеко за квадратом...

[sergey1963]

На матч Альфа-Зеро со Стоком-8 Гугл отрядило 4 ТРU- 50 тысяч тензорных ядер- это 800 видеокарт 1080ti. DeepMind- для генерации первого набора игр для самостоятельной игры использовалось 5 тысяч TPU, затем 16 TPU использовались для обучения нейронных сетей, время обучения заняло 9 часов. Stockfish использовал 44 процессора, AlphaZero использовал 4 TPU и 44 ядра процессора.
4 TPU- это 50 тысяч тензорных ядер с производительностью 8 тысяч ТЕРА-Флопс, для генерации набора игр использовалось свыше 60 миллионов тензорных ядер плюс обучением занимались 200 тысяч тензорных ядер с производительностью 32 тысячи Тера-Флппс... вся эта бесчисленная рать понадобилась лишь для победы над Стокфишем с производительностью в миллион раз меньше... нахрена??? спросите вы- и я о том же!!!

[Hendry]

бан по вам плачет

[Maratka]

Ну то, что сеть у AZ тренировалась единицы часов - факт.
Иначе никакого бы и матча не было, потому как AZ бы не было.

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

Если бы не было тысяч TPU? Очевидно, обучение заняло бы много-много месяцев, скорее даже годы, никто бы в Гугле не позволил этим заниматься столько времени.

Так что правда у sergey1963 в сообщении есть.

[Alex_Zet]

Ну да, прием известный, берешь маленькую часть правды и смешиваешь с кучей дерьма. А выглядит как правда.

[Maratka]

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

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

Я бы принял... Нужно Elo, а не способ его получения.
А потом, были бы упрощающие патчи, которые вырезали бы то, что в этом пачте Elo не дает.

[Asunta]

evaluate.cpp ( ~ Line 830 )

Зачем 2 раза вызывать функцию ( ? )
v = mg_value(score) * int( me->game_phase() ) + eg_value(score) * int( PHASE_MIDGAME - me->game_phase() ) * sf / SCALE_FACTOR_NORMAL;

Стандартное программирование даёт прибавку в скорости около 1%:
int GP = (int)me->game_phase();
v = mg_value(score) * GP + eg_value(score) * int( PHASE_MIDGAME - GP ) * sf / SCALE_FACTOR_NORMAL;

Наверняка таких мест много... Случайно на глаза попалось...
"Оптимизированный" .ехе-шник вполне может пройти фиштест, т.к. делает тоже самое, но быстрее...

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

[Maratka]

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

Зачем 2 раза вызывать функцию ( ? )
v = mg_value(score) * int( me->game_phase() ) + eg_value(score) * int( PHASE_MIDGAME - me->game_phase() ) * sf / SCALE_FACTOR_NORMAL
....
....
"Оптимизированный" .ехе-шник вполне может пройти фиштест, т.к. делает тоже самое, но быстрее...

А если оптимизировать, бенч будет тот же?

[Maratka]

Имею вопрос: есть ли у движка обратная связь с оболочкой, вида "у меня осталось N времени, у соперника N/k, где k - более единицы".

Т.е. попросту - у кого больше времени на доигрывание партии?

______
Фокус в чем: зная, что у меня 3 минуты, а у соперника 10 секунд, можно позволить себе "подумать" и подольше, расчет на то, что мы его "пересчитаем".

_____
Люди допустим это знают, ибо видят часы соперника, чем и пользуются.

[Maratka]

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

Еще раз для тупых 1 тензорное ядро равно по вычислительной мощности 6 ядернику с 12 потоками 4930к-0,16 тф. Теперь умножим это на 200 тысяч ядер и 9 часов, получим 11 млн-часов времени на 1 неплохом ядре 4 поколения (равное 2 ноутбучным)

Ну это обучение, а не игра.

У SF например "обучение" идет на 1-1,4 тыс ядер, с всплесками до 10-15 тыс.
Понятно, что это не то обучение, что у AZ или LZ, это скорее проверка новых эвристик, но ведь и у LZ новая сеть - это есть проверка против старой, т.е. если очень условно - это равноценные понятия.
Разница лишь в том, что у LZ проверяются автоматически подстроенные коэффициенты сети, а у SF в 80-90% случаев - рукописные.

Но опять же, и у SF есть и автоподстройка коэффициентов (правда запускается вручную), да и у LZ есть "человеческое вмешательство" вида "что тренировать будем".

Т.е. нельзя вот так грубо сравнивать 4 или там 32 ядра x86 c тензорными и по качеству (ибо разную работу они выполняют), и по количеству (SF "тренируется" на очень сильно больше, чем 4, 32 или даже 200 ядер).

[Rom77]

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

Имею вопрос: есть ли у движка обратная связь с оболочкой, вида "у меня осталось N времени, у соперника N/k, где k - более единицы".
Т.е. попросту - у кого больше времени на доигрывание партии?

Да, оболочка отсылает каждому движку оставшееся время обоих движков. Например:

Цитата:

2972 <Asmfish 2018-06(0): info depth 14 seldepth 21 multipv 1 time 97 nps 1511845 score cp 66 nodes 146649 tbhits 0 pv c1b2 e7e5 g1f3 g8f6 e2e3 f8d6 f1b5 d8c7 b1a3 e5e4 f3d4 f5g4 d4e2 e8g8 a3c4 d6h2
2973 <Asmfish 2018-06(0): bestmove c1b2 ponder e7e5
2973 >Houdini 4(1): position fen rn1qkbnr/ppp1pppp/8/3p1b2/2P5/1P6/P2PPPPP/RNBQKBNR w KQkq - 0 1 moves c4d5 c7c6 d5c6 b8c6 c1b2
2973 >Houdini 4(1): isready
2973 <Houdini 4(1): readyok
2973 >Houdini 4(1): go wtime 3600 btime 62064 winc 10 binc 160
2976 <Houdini 4(1): info depth 6
2977 <Houdini 4(1): info depth 7
2979 <Houdini 4(1): info depth 8
2980 <Houdini 4(1): info depth 9
2983 <Houdini 4(1): info depth 10
2984 <Houdini 4(1): info multipv 1 depth 10 seldepth 22 score cp 12 time 11 nodes 22621 nps 2056000 tbhits 0 hashfull 0 pv a8c8 b1c3 g8f6 e2e3 e7e5 h2h3 h7h6 g1f3 e5e4 g2g4 f5e6

[Asunta]

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

Имею вопрос: есть ли у движка обратная связь с оболочкой, вида "у меня осталось N времени, у соперника N/k, где k - более единицы".

http://kvetka.org/UCI_format.shtml --- ( команда go )

[Maratka]

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

Да, оболочка отсылает каждому движку оставшееся время обоих движков. Например:

А теперь вопрос к Vizvezdenec: использует ли SF эту информацию?

[sergey1963]

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

Ну это обучение, а не игра.
У SF например "обучение" идет на 1-1,4 тыс ядер, с всплесками до 10-15 тыс. Понятно, что это не то обучение, что у AZ или LZ, это скорее проверка новых эвристик, но ведь и у LZ новая сеть - это есть проверка против старой, т.е. если очень условно - это равноценные понятия. Разница лишь в том, что у LZ проверяются автоматически подстроенные коэффициенты сети, а у SF в 80-90% случаев - рукописные. Но опять же, и у SF есть и автоподстройка коэффициентов (правда запускается вручную), да и у LZ есть "человеческое вмешательство" вида "что тренировать будем". Т.е. нельзя вот так грубо сравнивать 4 или там 32 ядра x86 c тензорными и по качеству (ибо разную работу они выполняют), и по количеству (SF "тренируется" на очень сильно больше, чем 4, 32 или даже 200 ядер).

Таким образом при обучении среднее количество ядер стокфиша 4 тысячи- в 4 раза больше 1т и в 4 раза меньше 16т. Теперь сравним это с 11 млн А-З почти в 3 тысячи раз больше, т.е. 9 часов А-З обучения равны 4 месяцам Стока... Далее- играла со Стоком-8 на 44 процессорах А-З на 4 ТПУ- 50 тысяч тензорных ядер + 44 ядерный проц, по вычислительной мощности равные 50 тысячам 6-ядерным процессорам 4930к...
О чем тут вообще можно говорить? Вот почему нет убедительной победы в ТСЕС-17 у почти 3 тысяч тензорных ядер А-З над 88 ядерным процессором Стока...

[Maratka]

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

Таким образом при обучении среднее количество ядер стокфиша 4 тысячи- в 4 раза больше 1т и в 4 раза меньше 16т. Теперь сравним это с 11 млн А-З почти в 3 тысячи раз больше

Там другая математика, ее напрямую нельзя сравнивать.

Это вроде как x86 без сопроцессора и x86 с сопроцессором, при расчете с дробной частью: первый сможет выполнить любой код для второго, но на порядок-два медленнее. Т.е. формально ничего не нарушено: то же количество ядер и та же точность вычислений, но результат по скорости очень сильно другой.

Т.е. с точки зрения LZ/AZ TPU - это очередного уровня "сопроцессор", он ускоряет математику, но только вполне конкретного рода математику, (2^8/4,2)^(1/2(17))он не ускорит, это решается за счет SSE/AVX (в зависимости от свежести процессора).

[sergey1963]

Так я вижу эти соотношения на собственных 6600к и 1066, в которой нет тензорных ядер- 0,2тф против 4тф- 1 к 20 и в игре они равны. При тензорных же ядрах (1 к 24 старой видеокарты)- это соотношение будет вообще 1 к 0,8, т.е. в игре 6-ядерный проц действительно будет равен 1 тензорному ядру...

[Maratka]

Еще раз, это "другая" математика.
SF не множит матрицы, а у LZ нет формул для оценки вида:

 kingDanger +=        kingAttackersCount[Them] * kingAttackersWeight[Them]
                 + 185 * popcount(kingRing[Us] & weak)
                 + 148 * popcount(unsafeChecks)
                 +  98 * popcount(pos.blockers_for_king(Us))
                 +  69 * kingAttacksCount[Them]
                 +   3 * kingFlankAttack * kingFlankAttack / 8
                 +       mg_value(mobility[Them] - mobility[Us])
                 - 873 * !pos.count<QUEEN>(Them)
                 - 100 * bool(attackedBy[Us][KNIGHT] & attackedBy[Us][KING])
                 -   6 * mg_value(score) / 8
                 -   4 * kingFlankDefense
                 +  37;

Т.е. алгоритмически SF - это последовательные вычисления, для которых TPU даже не просто не нужен, он вреден, а LZ -ровно наоборот.

[sergey1963]

не надо математики- ищите соотношения- ваши 4(8) ядер 8350 равны в игре видеокарте 960, мои более новых 4 ядра 6600 равны в игре более новой 1066, тензорное ядро сильнее обычного в 24 раза- вот теперь подумайте- а сколько ядер надо процессору для баланса и почему 4х1080ти не справятся с 88 ядрами...
ну раз молчите- подсказываю- 1066- это треть 1080ти, 4х1080ти равны 12х1066, значит для баланса надо 48 новых ядер- 4х12...

[Maratka]

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

не надо математики- ищите соотношения- ваши 4(8) ядер 8350 равны в игре видеокарте 960, мои более новых 4 ядра 6600 равны в игре более новой 1066

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

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

ензорное ядро сильнее обычного в 24 раза

На чем сильнее?
a*b оно быстрее не умножит, скорее даже медленнее.

Вы путаете пиковую производительность, и применимость данной архитектуры к вычислениям того рода, которые от них требуются: SF не множит матрицы, просто в силу алгоритма, а TPU у LZ не складывает a+b.

Т.е. у них да, есть разрыв в производительности, но только для "удобной" для них математике.

[SKY]

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

Ну вот, скоро и Стокфиш будет использовать видяхи...

Уж наверно лет как 20 тому слышал о том что вот-вот движки будут играть на видео ядрах и все что-то никак не получается ни у кого.

[sergey1963]

тензорные ядра очень сильны только при фп16, против процессора при фп64- они загнутся, НО... Лила как раз и использует фп16...