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.

[свернуть]

[Владимир001]

Stockfish уничтожает Шевенинген!
https://youtu.be/rN0b4ANpSE8

Кони-Камикадзе
https://youtu.be/yhYnKKWBm-w

[Владимир001]

Кстати, поздравляем с новым рекордом NCM:

https://nextchessmove.com/dev-builds...952f510e6a126b

[sergey1963]

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

Пусть.
( 1 ) 2021.08.05 SF14 / nn-46832cfbead3 / MultiPV: 1
( 2 ) Threads: 1 -исключаем многоядерность
( 3 ) Depth: 28 -исключаем тайм менеджмент и Windows-влияние на него
( 4 ) Берём завышенный хэш > 3Gb, который при D28 будет использован не более чем на 7%
( 5 ) Перед каждым анализом очищаем хэш
Тогда почему Сток генерит разные линии ( ? )
Пример для начальной позиции:
3400 MB >> D28 +0.41 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6
3600 MB >> D28 +0.34 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nb3 Be7 8.f3 Be6 9.Qd2 0-0
3800 MB >> D28 +0.46 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6
4000 MB >> D28 +0.35 1.e4 e5 2.Nf3 Nc6 3.Bb5 a6 4.Ba4 Nf6 5.0-0 b5 6.Bb3 Bb7 7.d3 Bc5 8.Nc3 0-0 9.Bg5 h6
По идее "что-то новое" должно возникать, когда хэш заполнен на 100% и движок вынужден перед новой записью в хэш удалить старую запись...
Понятно, что при 3400 MB такой "момент" наступит раньше чем при 4000 MB... Но... Была же ж взята глубина D28, при которой почти весь
хэш пустой... Т.е. программа должна вести себя одинаково... А линии разные : )

Здесь на эти вопросы никто не ответит, кроме... Гударта- это он значительно улучшил работу Гудка 5-6 (это Сток 8-9)- а имено работу с памятью и переписал критические куски кода на Си (вместо С++)... сам движок весил менее 0,5мб, но с защитой от копирования- 2мб...
Мы кстати все видим огромный огрех при работе Стока с памятью- временами самопроизвольно он замирает на несколько минут, а то и десятков минут... Можно предположить, что это "подарок" от больших страниц, но и на 4кб Сток ведет себя также, скорее всего это неумение вовремя стирать память при переполнении ее... Но увы- при тестировании 0,1с, 1с и даже 10с на ход- этого не видно...- как там у Задорнова?- закроем на это глаза, завесим окна и сделаем вид, что все ОК...

[Maratka]

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

кроме... Гударта- это он значительно улучшил работу Гудка 5-6 (это Сток 8-9)- а имено работу с памятью и переписал критические куски кода на Си (вместо С++)... сам движок весил менее 0,5мб,

У меня сборка потянет на 100 или 200 килобайт. И что с того?

[sergey1963]

Мурат- сборка 100кб- это Асм, 200- это Си, 1200- это С++, думаю на Яве и на 10мб потянет...
Правда сие тебе недоступно и непостижимо... сравнение низко- и верхнеуровневых языков програмирования...

[Asunta]

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

Пусть.

( 1 ) 2021.08.05 SF14 / nn-46832cfbead3 / MultiPV: 1
( 2 ) Threads: 1 --- исключаем многоядерность
( 3 ) Depth: 28 ---- исключаем тайм менеджмент и Windows-влияние на него
( 4 ) Берём завышенный хэш > 3Gb, который при D28 будет использован не более чем на 7%
( 5 ) Перед каждым анализом очищаем хэш

Тогда почему Сток генерит разные линии ( ? )

Пример для начальной позиции:

3400 MB >> D28 +0.41 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6
3600 MB >> D28 +0.34 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nb3 Be7 8.f3 Be6 9.Qd2 0-0
3800 MB >> D28 +0.46 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6
4000 MB >> D28 +0.35 1.e4 e5 2.Nf3 Nc6 3.Bb5 a6 4.Ba4 Nf6 5.0-0 b5 6.Bb3 Bb7 7.d3 Bc5 8.Nc3 0-0 9.Bg5 h6


По идее "что-то новое" должно возникать, когда хэш заполнен на 100% и движок вынужден перед новой записью в хэш удалить старую запись...
Понятно, что при 3400 MB такой "момент" наступит раньше чем при 4000 MB... Но... Была же ж взята глубина D28, при которой почти весь
хэш пустой... Т.е. программа должна вести себя одинаково... А линии разные : )

В исходниках с хэшем работают в search.cpp

Там чтение/запись происходит в нескольких участках кода и по одним и тем же правилам...
В моём примере дело не доходит до "записать новое вместо старого", т.к. используется до 7% хэша...
Т.е. независимо от точного размера ( 3400, 3600, 3800 или 4000 ) происходит "запись на пустое место"...
Вроде как D28-линии и D28-записанное в хэш - всё это должно всегда совпадать, т.к. в тексте программы
нет "нюанса", который генерит случайные числа : )

[sergey1963]

Не так, Сток использует до половины имеющейся памяти, но другая половина не пуста- она уже на четверть-треть занята Виндой и рабочими прилижениями... Да, сток- почем зря засирает "свою память" лепит от всех потоков в разные места и уже при 10% заполненности начинает тормозить, при 50%- сильно, при 100%- нам приходит привет от ОЗУ...
Далее еще чуднее- при активно работающих ядрах (и боже мой, Карл! еще и "недопотоках"), мы пытаемся что-то куда-то впихнуть и что-то где-то вычистить... причем одновременно, а не планово-заранее как в Винде... Делать надо как в играх, все прошлое кроме предыдущей ступени- вычищается, а при большой загрузке вычищается "на лету" и текущая ступень сразу после использования... Перевожу- при рассмотрении 40глубины, мы базируемся на оценках 39-ой, поэтому оценки 38 и ниже- очищаются сразу...
О!- не сразу и заметил- Сток понимает только степень двойки, т.е. хэш может быть 1-2-4-8гб и тд. 1гб=1024мб. То что мы ставим от себя- ему пофиг- смотрим диспетчер задач.

[Alex_Lk]

Может при вычислении места в Хэш-е для позиции, используется "разиер хэша".

При одном и том же хэше результаты повторяются ?

[Asunta]

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

О!- не сразу и заметил- Сток понимает только степень двойки, т.е. хэш может быть 1-2-4-8гб и тд. 1гб=1024мб. То что мы ставим от себя- ему пофиг- смотрим диспетчер задач.

Начиная с SF10, Стоку можно задавать любые цифры... В моём примере реально требуется не более 512MB
Даже если привести "неправильно заданные" ( 3400 ... 4000 ) к 2048MB - линии должны совпадать...

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

При одном и том же хэше результаты повторяются ?

Повторяются... Ещё не хватало, чтобы и здесь не повторялось...
У меня в примере одно ядро... Никаких фокусов : )

До D21 включительно всё совпадает...
До D24 включительно кое-что совпадает...
Начиная с D25, все линии разные...

3400 MB >> D18 +0.39 1.e4 c5 2.Nc3 Nc6 3.Nf3 e6 4.d4 cxd4 5.Nxd4 Nf6 6.a3 d6 7.f3 Be7 8.Be3 d5 9.exd5 Nxd5 10.Nxd5 Qxd5
3600 MB >> D18 +0.39 1.e4 c5 2.Nc3 Nc6 3.Nf3 e6 4.d4 cxd4 5.Nxd4 Nf6 6.a3 d6 7.f3 Be7 8.Be3 d5 9.exd5 Nxd5 10.Nxd5 Qxd5
3800 MB >> D18 +0.39 1.e4 c5 2.Nc3 Nc6 3.Nf3 e6 4.d4 cxd4 5.Nxd4 Nf6 6.a3 d6 7.f3 Be7 8.Be3 d5 9.exd5 Nxd5 10.Nxd5 Qxd5
4000 MB >> D18 +0.39 1.e4 c5 2.Nc3 Nc6 3.Nf3 e6 4.d4 cxd4 5.Nxd4 Nf6 6.a3 d6 7.f3 Be7 8.Be3 d5 9.exd5 Nxd5 10.Nxd5 Qxd5

3400 MB >> D19 +0.42 1.e4 c5 2.Nf3 d6 3.d4 cxd4 4.Nxd4 Nf6 5.Nc3 a6 6.h3 e6 7.a4 Be7 8.g4 d5 9.Bg2 Nxe4
3600 MB >> D19 +0.42 1.e4 c5 2.Nf3 d6 3.d4 cxd4 4.Nxd4 Nf6 5.Nc3 a6 6.h3 e6 7.a4 Be7 8.g4 d5 9.Bg2 Nxe4
3800 MB >> D19 +0.42 1.e4 c5 2.Nf3 d6 3.d4 cxd4 4.Nxd4 Nf6 5.Nc3 a6 6.h3 e6 7.a4 Be7 8.g4 d5 9.Bg2 Nxe4
4000 MB >> D19 +0.42 1.e4 c5 2.Nf3 d6 3.d4 cxd4 4.Nxd4 Nf6 5.Nc3 a6 6.h3 e6 7.a4 Be7 8.g4 d5 9.Bg2 Nxe4

3400 MB >> D20 +0.47 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nf3 Be7 8.h3 Be6 9.Ng5 d5
3600 MB >> D20 +0.47 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nf3 Be7 8.h3 Be6 9.Ng5 d5
3800 MB >> D20 +0.47 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nf3 Be7 8.h3 Be6 9.Ng5 d5
4000 MB >> D20 +0.47 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nf3 Be7 8.h3 Be6 9.Ng5 d5

3400 MB >> D21 +0.53 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be2 e6 7.f4 b5 8.e5 dxe5 9.fxe5 Nfd7 10.Bf4 Qb6
3600 MB >> D21 +0.53 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be2 e6 7.f4 b5 8.e5 dxe5 9.fxe5 Nfd7 10.Bf4 Qb6
3800 MB >> D21 +0.53 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be2 e6 7.f4 b5 8.e5 dxe5 9.fxe5 Nfd7 10.Bf4 Qb6
4000 MB >> D21 +0.53 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be2 e6 7.f4 b5 8.e5 dxe5 9.fxe5 Nfd7 10.Bf4 Qb6

3400 MB >> D22 +0.49 1.e4 c6 2.d4 d5 3.e5 Bf5 4.c3 e6 5.Nf3 c5 6.Be3 Qb6 7.Qc1 f6 8.Be2 Nc6 9.0-0 fxe5 10.Nxe5 Nxe5
3600 MB >> D22 +0.47 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nb3 Ng4 8.Bc1 Be6 9.f3 Nf6 10.Be3 Nc6
3800 MB >> D22 +0.49 1.e4 c6 2.d4 d5 3.e5 Bf5 4.c3 e6 5.Nf3 c5 6.Be3 Qb6 7.Qc1 f6 8.Be2 Nc6 9.0-0 fxe5 10.Nxe5 Nxe5
4000 MB >> D22 +0.47 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nb3 Ng4 8.Bc1 Be6 9.f3 Nf6 10.Be3 Nc6

3400 MB >> D23 +0.37 1.e4 c6 2.Nc3 d5 3.d4 dxe4 4.Nxe4 Nf6 5.Nxf6+ exf6 6.Nf3 Bd6 7.Bd3 0-0 8.0-0 Re8 9.h3 Nd7 10.c4 Nf8
3600 MB >> D23 +0.49 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nb3 Ng4 8.Bc1 Be6 9.f3 Nf6 10.Be3 Nc6
3800 MB >> D23 +0.33 1.e4 c6 2.d4 d5 3.Nc3 dxe4 4.Nxe4 Bf5 5.Ng3 Bg6 6.Nf3 e6 7.Bd3 Nf6 8.0-0 Bd6 9.a4 Qc7 10.a5 a6
4000 MB >> D23 +0.49 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nb3 Ng4 8.Bc1 Be6 9.f3 Nf6 10.Be3 Nc6

3400 MB >> D24 +0.31 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6 10.Re1 Re8
3600 MB >> D24 +0.39 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 Nc6 6.Bg5 e6 7.Qd2 a6 8.f3 Bd7 9.Be3 Nxd4 10.Bxd4 Be7
3800 MB >> D24 +0.38 1.e4 c6 2.Nf3 d5 3.Nc3 Bg4 4.d4 Nf6 5.Bd3 e6 6.0-0 dxe4 7.Nxe4 Nxe4 8.Bxe4 Nd7 9.c3 Bd6 10.Qe2 Qc7
4000 MB >> D24 +0.39 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 Nc6 6.Bg5 e6 7.Qd2 a6 8.f3 Bd7 9.Be3 Nxd4 10.Bxd4 Be7

3400 MB >> D25 +0.40 1.Nf3 d5 2.d4 Nf6 3.c4 dxc4 4.e3 a6 5.Bxc4 e6 6.0-0 c5 7.dxc5 Qxd1 8.Rxd1 Bxc5 9.Be2 0-0 10.b3 b5
3600 MB >> D25 +0.44 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.h3 e6 7.g4 d5 8.exd5 Nxd5 9.Nde2 Nxc3 10.Qxd8+ Kxd8
3800 MB >> D25 +0.47 1.e4 e5 2.Nf3 Nc6 3.Bb5 a6 4.Ba4 Nf6 5.0-0 Nxe4 6.d4 b5 7.Bb3 d5 8.dxe5 Be6 9.c3 Be7 10.h3 0-0
4000 MB >> D25 +0.49 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.h3 e5 7.Nde2 b5 8.g4 b4 9.Nd5 Nxd5 10.exd5 h5

3400 MB >> D26 +0.53 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6 10.Re1 Re8
3600 MB >> D26 +0.37 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.h3 e6 7.g4 b5 8.g5 b4 9.gxf6 bxc3 10.fxg7 Bxg7
3800 MB >> D26 +0.49 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 Nc6 6.Bg5 e6 7.Qd2 a6 8.0-0-0 Bd7 9.f3 b5 10.Nxc6 Bxc6
4000 MB >> D26 +0.36 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.h3 e5 7.Nde2 b5 8.Ng3 Bb7 9.Bg5 Nbd7 10.Nh5 g6

3400 MB >> D27 +0.38 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6 10.Re1 Re8
3600 MB >> D27 +0.55 1.e4 c5 2.Nf3 Nc6 3.Nc3 g6 4.d4 cxd4 5.Nxd4 Bg7 6.Be3 Nf6 7.Nb3 0-0 8.Qd2 d6 9.f3 a6 10.h4 b5
3800 MB >> D27 +0.51 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 Nc6 6.Bg5 e6 7.Qd2 a6 8.0-0-0 h6 9.Nxc6 bxc6 10.Bh4 Be7
4000 MB >> D27 +0.43 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Ne8 10.c4 Bf6

3400 MB >> D28 +0.41 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6 10.Re1 Re8
3600 MB >> D28 +0.34 1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Be3 e5 7.Nb3 Be7 8.f3 Be6 9.Qd2 0-0 10.0-0-0 Nbd7
3800 MB >> D28 +0.46 1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Nxe4 5.Re1 Nd6 6.Nxe5 Be7 7.Bf1 Nxe5 8.Rxe5 0-0 9.d4 Bf6 10.Re1 Re8
4000 MB >> D28 +0.35 1.e4 e5 2.Nf3 Nc6 3.Bb5 a6 4.Ba4 Nf6 5.0-0 b5 6.Bb3 Bb7 7.d3 Bc5 8.Nc3 0-0 9.Bg5 h6 10.Bh4 Be7

[Alex_Lk]

Какие вопросы. Найти переменную размер хэша и посмотреть где она используется.
В конце концов найдется...
Вопрос только в объеме работы.

[Alex_Lk]

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

До D21 включительно всё совпадает...
До D24 включительно кое-что совпадает...
Начиная с D25, все линии разные...

А размер используемого при этом хэша ?
Может какую то границу перерос...

[sergey1963]

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

Начиная с SF10, Стоку можно задавать любые цифры... В моём примере реально требуется не более 512MB Даже если привести "неправильно заданные" ( 3400 ... 4000 ) к 2048MB - линии должны совпадать

Увы- это все от лукавого, от оболочки- запустите в консоли- сильно удивитесь- хоть 7гб- а будет 4... И память выделяется в действительности "не сплошняком" а как попало...

[Alex_Lk]

Нельзя ли для отладки сбрасывать текущий хэш на диск.
У кого то такая возможность была.

[sergey1963]

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

[Maratka]

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

Мурат- сборка 100кб- это Асм, 200- это Си, 1200- это С++, думаю на Яве и на 10мб потянет...

менее 100 кб для сборки SF (до NNUE).
С++
И да, я не горец с мусульманскими именами, хотя и не против мусульман, и их культуры.
Но имея у меня Марат. И фамилия - Канжа.
Откуда - MaratKa.

[sergey1963]

Это можно увидеть? скиньте экзэшник... самое малое делали Асм -120кб, Си- 180

[Maratka]

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

Просто всех то дел - поставить в нужном месте чекбокс, вида "использовать внешние либы", ибо иначе- будут они в сам бинарь пихаться, а оно не особо и нужно, т.к. распространяется бесплатно с серверов MS в рамках обычного процесса обновления системы.

А если поверх еще и паккером пройтись...

[Asunta]

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

А размер используемого при этом хэша ?
Может какую то границу перерос...

Перерос : )
1%-2%-3% от задаваемого хэша...

Точным размером хэша Сток начинает интересоваться при перезаписи,
когда хэш на 100% заполнен и надо что-то удалить перед тем как записать...

Пока есть свободное место - тупо пишется...
А этого добра более 90% при D28 и специально завышенном хеше ( 3400 ... 4000 )

[Maratka]

Что в общем-то разумно: зачем чистить нули?
Проще проверить, что там действительно только нули!


А еще проще: знать! Ведь если у нас фиксированного размера хеш (а другого движок не позволяет), то проще паренной репы ставить метки на уже записанные страницы, и писать туда, где меток нет. В этом случае все сводится по сути то просто к проверке флага "писал или не писал", и как следствие, можно быстро писать в свободные страницы даже тогда, когда наполняемость хеша 99,9%

[Vizvezdenec]

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

[Alex_Lk]

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

Для ответа почему размер хэша влияет на анализ, надо смотреть как в Стоке работает хэш.
Первое что я посмотрел бы это где там используется "размер хэша" без этого будет просто гадание.

И еще где нибудь там можно сбросить текущий хэш на диск. Это сильно прояснило бы дело. Смутно помню какой то разговор об этом был даже здесь на форуме. (или это было еще на иммортале ...)

[Maratka]

Т.е. по содержимому страниц памяти не ставятся контрольные их суммы?
Или за счет коллизии?

____
Я понимаю, что подчитать хеш для блока в 64 килобайта - иной раз проще оценить уже оцененное, оно зависит от много чего... ну основной на мой взгляд кандидат - "ленивый поиск", где с высокой вероятностью поток N+m может начать считать то же, что и N, просто за счет перестановки ходов на низкой глубине 2-3-4... Т.е. чем меньше потоков - тем меньше коллизий, но и падает охват поиска.

Соответственно, одна из основных задач его оптимизации - это коэффициенты отрезания в зависимости от глубины.

Или есть еще другие (именно основные, не второстепенные) факторы?

[Alex_Lk]

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

Так как у нас не используется полный 64-битный ключ позиции, а используется только 16-битный,

Что то не так. 16-битный ключ это всего 65 тыс ячеек в хэше.

[Vizvezdenec]

Ну я спросил, в общем-то да, это из-за коллизий и перезаписывания хеша, его слишком большой размер не спасает от этого.
Из-за того, что используются усечённые zobrist-ключи, например, уже в стандартном бенче глубины 13 есть приличные отличия от бенча с 64-разрядными zobrist-ключами.
Так что вполне ожидаемо, что именно от размера хеша с определённой глубины будут идти отличия.

[Alex_Lk]

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

ну основной на мой взгляд кандидат - "ленивый поиск", где с высокой вероятностью поток N+m может начать считать то же, что и N,

Цель получить однозначно повторяемый результат поэтому многопоточнось отключена.

[Vizvezdenec]

https://github.com/official-stockfis...r/src/tt.h#L91
https://github.com/official-stockfis...src/tt.cpp#L69
Короче вот из-за этого это происходит
Мне тут объяснять сложно, т.к. я сам очень сильно плаваю в этом.
Использовать таблицу повторения в поиске я могу, а вот как она работает - с этим я не разбирался особо.
В общем для повторяемого результат хэш надо оставлять таким же, иначе с определённой глубины будут начинаться расхождения.

[Maratka]

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

Ну я спросил, в общем-то да, это из-за коллизий и перезаписывания хеша, его слишком большой размер не спасает от этого.
Из-за того, что используются усечённые zobrist-ключи, например, уже в стандартном бенче глубины 13 есть приличные отличия от бенча с 64-разрядными zobrist-ключами.
Так что вполне ожидаемо, что именно от размера хеша с определённой глубины будут идти отличия.

А значит, с определенной глубины (что подразумевает некое количество и качество ядер) - должны влиять и "большие страницы", условно говоря, в 4 мегабайтах "больших страниц" влазит целых 64 малых страниц по 64 килобайта каждая. Т.е. в 64 раза больше. Таким образом, банально исключаются чисто технические операции по проверке содержимого хеша движка, но.. это когда память измеряется терабайтами, т.е. когда есть в любом случае "много" даже 4-мегабайтных страниц.

А иначе - ну включили мы эти "большие страницы", тем самым да, экономим на расходах по их проверке. Но ведь раз они большие, а памяти мало - оно быстро закончатся! И придется тереть все 4 мегабайта, из которых вполне реально, чо 87% были заполнены еще актуальными данными, т.е. их придется пересчитывать?

[Vizvezdenec]

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

[Maratka]

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


__
Я не особо рассчитывал, что получу исчерпывающий ответ именно от Вас.
Но народ, кто пишет всякие там AVX/SSE оптимизации для движка, вероятно ближе к этой теме. Если не затруднит - можете у них уточнить?

[sergey1963]

Могу ответить словами хорошего знакомого- отличного програмиста-
когда я ему показал использование больших страниц Стокфишем и он увидел пресловутое "алок", то сказал- что у него таких горе-прогеров с работы сразу увольняют- это слишком "беззаботно-вольготный" переход на 2мб страницы... толку от этого будет мало...