|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
Похоже, что мне такие матчи точно не увидеть. А также «полуживые» матчи - игру живого Карлсена с Фишером_1975, например.
Был такой замечательный фантаст Зиновий Юрьев (Гринман). У него есть несколько романов о переносе содержимого мозга в молодое тело.
Симуляция это, конечно, другое, но все-таки попытка воспроизведения шахматной составляющей гениальных людей. Ладно, не буду офтопить. |
|
|
| номер сообщения: 54-31-8037 |
|
|
|
|
Vizvezdenec: https://tcec-chess.com/#div=svvltc&game=4&season=28
Сенсация, даже сейчас и на очень хорошем железе и с большим контролем вышло как-то так, что стокфиш у лилы выиграл со стартовой позиции.
g5?? грубейший зевок.
Но вроде бы у лилы просто закончилась память, так что она играла вообще без поиска.  |
Что значит, "закончилась память". Баг в коде, забыли где-то free() сделать, грубо говоря?
__________________________
Полюбите нас черненькими, а беленькими нас всякий полюбит. |
|
|
| номер сообщения: 54-31-8038 |
|
|
|
|
romm: Vizvezdenec: https://tcec-chess.com/#div=svvltc&game=4&season=28
Сенсация, даже сейчас и на очень хорошем железе и с большим контролем вышло как-то так, что стокфиш у лилы выиграл со стартовой позиции.
g5?? грубейший зевок.
Но вроде бы у лилы просто закончилась память, так что она играла вообще без поиска. |
Что значит, "закончилась память". Баг в коде, забыли где-то free() сделать, грубо говоря? |
Я слабый спец в лиле, просто могу транслировать то, что говорят её девелоперы.
Ей вроде как надо хранить всё дерево поиска в памяти из-за того, как алгоритм работает, и она его всю игру и хранит.
Что обычно совершенно не проблема, т.к. число посчитанных позиций очень невелико, но вот для таких экстремально больших железяк и времени на игру это заканчивается вот этим.
У стокфиша есть алгоритмы автозамены позиций в хэше в зависимости от их актуальности, но альфабете как раз прямо всё дерево поиска хранить в памяти не обязательно. |
|
|
| номер сообщения: 54-31-8039 |
|
|
|
|
Kazus: Похоже, что мне такие матчи точно не увидеть. А также «полуживые» матчи - игру живого Карлсена с Фишером_1975, например.
Был такой замечательный фантаст Зиновий Юрьев (Гринман). У него есть несколько романов о переносе содержимого мозга в молодое тело.
Симуляция это, конечно, другое, но все-таки попытка воспроизведения шахматной составляющей гениальных людей. Ладно, не буду офтопить. |
Ну попытка сделать играющего Фишера 1975 и т.д. это всё-таки совсем иная плоскость, чем разработка движка, который играет в как можно более сильные шахматы.
Хотя бы потому, что вторая задача имеет чёткие критерии выполнения - новая версия "просто" должна обыгрывать старую с некоторой статистической уверенностью. |
|
|
| номер сообщения: 54-31-8040 |
|
|
|
|
https://old.reddit.com/r/chess/comments/1kdtuku/how_slow_would_stockfish_need_to_run_to_be/
Любопытный пост о том, как нужно отрубать ноги стокфишу, чтобы он был слабее людей.
Что автор не знает, так это то, что у стокфиша очень много вещей оптимизировано под 60+0.6 8 потоков с нормальными процессорами, т.е. по факту многие эвристики поиска на таких малых узлах совсем плохо работают - если оптимизировать под такие контроли, то пару сотен эло, вероятно, вполне можно добрать. |
|
|
| номер сообщения: 54-31-8041 |
|
|
|
|
Vizvezdenec: https://old.reddit.com/r/chess/comments/1kdtuku/how_slow_would_stockfish_need_to_run_to_be/
Любопытный пост о том, как нужно отрубать ноги стокфишу, чтобы он был слабее людей.
Что автор не знает, так это то, что у стокфиша очень много вещей оптимизировано под 60+0.6 8 потоков с нормальными процессорами, т.е. по факту многие эвристики поиска на таких малых узлах совсем плохо работают - если оптимизировать под такие контроли, то пару сотен эло, вероятно, вполне можно добрать. |
Автор может скомпилировать движки из недавнего турнира на Kaggle. Они и по памяти экономичные, так что лучше адаптированы к старым машинам:
https://github.com/linrock/minifish
https://github.com/peregrineshahin/Approvers
https://github.com/AndyGrant/KaggleFish
Vizvezdenec: Когда движок в каждой позиции (хотя бы достижимой с начальной) через достаточно вменяемое время будет выдавать ход, который не меняет её объективную оценку - вот тогда можно будет об этом думать.
Пока что пласт позиций, где движок имеет примерно 50% шанс выиграть, а 50% - шанс не выиграть, очень велик. Причём они и в играх людей регулярно возникают, очень даже есть куда расти и где предел - совершенно не ясно. |
Возможно предел не так далеко, как можно предполагать. Уже сейчас на фиштесте две трети пар партий заканчиваются вничью и это число достаточно быстро растет от релиза к релизу, и кроме того оно растет с увеличением контроля времени. Если учесть что в победных парах половина партий тоже закончились вничью, а пары (1-0,0-1) с точки зрения вычисления эло эквивалентны ничьим, то уже сейчас на фиштесте менее 20 процентов по настоящему результативных партий.
Конечно если фиштест достигнет 95 % партий которые эквивалентны ничьим, то это критично для фиштеста, но ещё не свидетельствует о достижении объективной оценки. Но с другой стороны это уже знак, что мы близко. Могу предложить пару методов, как проверить приближение к объективной оценке позиции (т.е. к выводу оценки неких условных 32-х фигурных таблиц).
P.S. Забыл упомянуть.
Естественно предполагать, что если мы не можем получать в тестах победные пары, то и некоему идеальному движку, чей вывод всегда соответствует объективной оценке позиции (1, 1/2, 0), такое тоже трудно будет. |
|
|
| номер сообщения: 54-31-8042 |
|
|
|
|
Где на фиштесте 2/3 пар заканчивается вничью?
https://tests.stockfishchess.org/tests/stats/681053293629b02d74b1668f
https://tests.stockfishchess.org/tests/stats/680ed6b03629b02d74b160bd
на 10+0.1 типа 51%
https://tests.stockfishchess.org/tests/stats/681474243629b02d74b16b44
https://tests.stockfishchess.org/tests/stats/680e95db3629b02d74b15e7a
на 60+0.6 типа 56%
https://tests.stockfishchess.org/tests/stats/680e82b23629b02d74b15e27
https://tests.stockfishchess.org/tests/stats/680e38d53629b02d74b15d86
на 60+0.6 8 потоках типа 62%
(Distribution {0.00: 0.00022, 0.25: 0.18638, 0.50: 0.62308, 0.75: 0.19019, 1.00: 0.00013} - вот среднее значение это то, что нас интересует)
Ну так это вполне себе ничего.
Более того, как начнёт приближаться к 90% условно (до 90% в принципе всё равно, там без проблем можно разработку вести), нужно будет просто перефильтрацией книги заняться и снова получится там 50-65%.
Но сделать из даже 62% ничьих 90% очень так то непросто, это чуть ли не десяток лет разработки уйдёт.
Да и кстати я не вижу, чтобы прям процент ничьих сильно рос со временем.
Вот возьмём какие-то там случайные тесты полутора годичной давности.
https://tests.stockfishchess.org/tests/stats/6557ca99136acbc57353b8ad
https://tests.stockfishchess.org/tests/stats/653d2a6dcc309ae83956296d
10+0.1 50,7-9% ничьих, целых полпроцента разницы с современностью (:
https://tests.stockfishchess.org/tests/stats/655639ff136acbc5735394dd
https://tests.stockfishchess.org/tests/stats/65561944136acbc573539233
60+0.6 типа 54%, в районе 2% разницы
https://tests.stockfishchess.org/tests/stats/65740ffaf09ce1261f1239ba
с трудом нашёл примерно нейтральный патч того времени на 60+0.6 8 потоках, там 64% ничьих почему-то, что даже больше, чем сейчас  .
Поэтому я не вижу особого восходящего тренда в этом проценте ничьих, но если он и есть, то это пара процентов за полтора года, то есть до серьёзных проблем где-то лет 15, ну если не будет больших прорывов типа NNUE.
Но и там вероятнее всего перелопачиванием книги это лечится. |
|
|
| номер сообщения: 54-31-8043 |
|
|
|
|
Rom77: Vizvezdenec: https://old.reddit.com/r/chess/comments/1kdtuku/how_slow_would_stockfish_need_to_run_to_be/
Любопытный пост о том, как нужно отрубать ноги стокфишу, чтобы он был слабее людей.
Что автор не знает, так это то, что у стокфиша очень много вещей оптимизировано под 60+0.6 8 потоков с нормальными процессорами, т.е. по факту многие эвристики поиска на таких малых узлах совсем плохо работают - если оптимизировать под такие контроли, то пару сотен эло, вероятно, вполне можно добрать. |
Автор может скомпилировать движки из недавнего турнира на Kaggle. Они и по памяти экономичные, так что лучше адаптированы к старым машинам:
https://github.com/linrock/minifish
https://github.com/peregrineshahin/Approvers
https://github.com/AndyGrant/KaggleFish
|
А ещё они оптимизированы для игры на 5 секундах за партию. Точно знаю про второй, я сам давал пару советов по поводу того, как сделать его сильнее конкретно на мизерных контролях, но это сильно ему вредит на более длинных. Да и в целом не так уж им критично нужен какой-то сильно большой объём памяти, там 512 мегабайт у этого Raspberry Pi, что вообще не факт, что меньше, чем было у того, что играло против Крамника так то. |
|
|
| номер сообщения: 54-31-8044 |
|
|
|
|
Vizvezdenec:
А ещё они оптимизированы для игры на 5 секундах за партию. Точно знаю про второй, я сам давал пару советов по поводу того, как сделать его сильнее конкретно на мизерных контролях, но это сильно ему вредит на более длинных. Да и в целом не так уж им критично нужен какой-то сильно большой объём памяти, там 512 мегабайт у этого Raspberry Pi, что вообще не факт, что меньше, чем было у того, что играло против Крамника так то. |
5 секунд все же лучше чем минута у обычного Стокфиша. Хотя конечно дополнительная оптимизация на ещё меньшие контроли не повредит.
Насчет памяти - автор вроде бы хотел на реальном 16-битном железе запускать, а там, насколько помню, 16 Мб доступной памяти. Значит нейросеть - мимо (да и без векторов от неё все равно никакого толку), таблицы истории - порезать, хэш - порезать и т.д. |
|
|
| номер сообщения: 54-31-8045 |
|
|
|
|
Vizvezdenec: Где на фиштесте 2/3 пар заканчивается вничью?
...
Поэтому я не вижу особого восходящего тренда в этом проценте ничьих, но если он и есть, то это пара процентов за полтора года, то есть до серьёзных проблем где-то лет 15, ну если не будет больших прорывов типа NNUE.
Но и там вероятнее всего перелопачиванием книги это лечится. |
У меня следующие данные:
1. Возмем результаты со страницы регрешн-тестов к предыдущему релизу, первый тест:
https://tests.stockfishchess.org/tests/view/64b83cdbdc56e1650abad31a
17820 ничейных пар - 59,4%
Но если считать по партиям (по ним ведь и расчитывается эло тестов, а не по парам),
то получаем процент партий, эквивалентных ничьим - 79,7%
2. Первый регрешн-тест к текущему основному релизу:
https://tests.stockfishchess.org/tests/view/670b8b8086d5ee47d953c2c5
19867 ничейных пар - 66,2%
По партиям - 83,1%
Если проследить динамику текущих регрешн-тестов, то можно заметить, что с повышением отрыва ничейность пар практически не падает (а должна бы), а на одном потоке она вроде бы даже и растет.
Ну и конечно на реальных контролях ничейность будет ещё выше.
Насчет больших прорывов типа NNUE - я по прежнему надеюсь на прогресс в развитии NPU. Чтобы два раза не писать, скопирую свой развернутый ответ с форума 4pda, отсюда:
Недавно пытался разобраться в архитектуре новых процессоров AMD Ryzen AI max с нейропроцессорами (NPU). Я конечно не специалист в электронике, но кажется они настраиваются на быстрый обмен данными (latency) с CPU-ядрами. По крайней мере на инфографике не видно каких-либо промежуточных блоков, куда могли бы загружаться данные:
https://images.anandte…_Vamsi%20Boppan-12.png
https://www.servetheho…rchitecture-scaled.jpg
https://www.servetheho…oint-SoCjpg-scaled.jpg
Шина Infinity Fabric должна обеспечить быстрый обмен данными. Мне только не понято - NPU будет обмениваться данными с CPU Core через оперативную память или через L3-кэш. Задержка (latency) примерно 250 и 50 тактов соответственно. Опять же, если не будет дополнительных задержек.
Если задержка будет небольшая, то открываются шикарные перспективы. Повторюсь, не специалист, но видится так, что в NNUE можно будет вместо крошечных полносвязных промежуточных слоев использовать полноценные сверточные (convolutional). Те, что используются в современных архитектурах, например трансформерах.
Сейчас многие NPU для ноутов имеют пиковую производительность до 50 TOPS, в связи с требованиями Copilot+ в Windows. Так что в перспективе высокопроизводительные NPU могут стать мейнстримом. Пиковая скорость до 50 TOPS на int8 в 5 - 10 раз больше производительности векторных блоков на CPU Core (по моим прикидкам 6 TOPS на int8 для 8 ядер). Грех бросаться такой производительностью.
Если задержка действительно окажется небольшой, то можно будет попробовать новые архитектуры. Например наиболее ресурсоемкие первый-второй слой NNUE выполнять по прежнему на векторах, результаты отправлять на NPU, где считать еще 5-6 сверточных блоков. Тем более сверточные сети экономны с точки зрения расхода памяти и может быть нужные коэффициенты сети можно будет разместить в регистрах NPU. Всё будет быстро, тогда как сеть будет приближаться по качеству оценки к малым сетям Лилы. С увеличением производительности NPU конечно.
Таким образом можно будет закрыть единственное слабое место NNUE-движков - оценку позиции. И в перспективе даже в некотором смысле решить шахматы (я не шучу). Плюсом NNUE-движки получат ещё и некоторые бонусы, например бесплатный policy. Policy можно использовать при сортировке вместо (а лучше вместе) с History. Вместе лучше, потому что History с LMR обеспечивают вариативность для LazySMP.
Вот такие качественные сдвиги в будущем могут нас ожидать. И не сказать что такие перспективы слишком уж нереальны. Индустрия кажется движется в нужном направлении. |
|
|
|
| номер сообщения: 54-31-8046 |
|
|
| |
|
|
|
|
|
|
|
| Copyright chesspro.ru 2004-2025 гг. |
|
|
|
