|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
Похоже, что мне такие матчи точно не увидеть. А также «полуживые» матчи - игру живого Карлсена с Фишером_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 |
|
|
|
|
Vizvezdenec:
Но и там вероятнее всего перелопачиванием книги это лечится. |
Так, забыл написать насчет перелопачивания книги
Если мы будем отбирать из небалансной книги, достигшей 90% процентов ничейных пар, только позиции с низкой статистикой ничьих, то получим набор весьма специфических позиций. Это будут позиции навроде тех, которые сейчас присутствуют в тестовых наборах - а это в свою очередь не очень здорово, по тем же причинам, что и для тестовых наборов.
Кроме того, что получается? Мы уже будем иметь свыше 95% ничьих на балансных позициях, свыше 95% решающих результатов на крайне сверхдисбаланых позициях (оценка больше +1.5) и 95% результатов эквивалентных ничьим на позициях "на два результата" (оценка около +1, небалансная книга). Таким образом мы охватываем всё поле возможных позиций в шахматах и получаем результаты с высокой долей достоверности - две сигмы. Много ли изменят здесь специфические позиции, и не понизят ли они процент у обычных небалансных позиций? Можно проверить (и надо бы), но это уже следующая задача. |
|
|
| номер сообщения: 54-31-8047 |
|
|
|
|
Эло-то рассчитывается по партиям, а вот SPRT по нормализованному эло, которое вообще-то делится на процент ничьих. Так что на самом деле всё существенно лучше.
Ну и да.
Вас не смущает то, что книга для PT отличается от книги для собственно тестирования? На ней процент ничьих и правда выше.
А если брать % ничьих для книги для тестирования, то для LTC обычного он https://tests.stockfishchess.org/tests/stats/6810d0d63629b02d74b16758 56% примерно
А на 60+0.6 8 потоках - https://tests.stockfishchess.org/tests/stats/680e38d53629b02d74b15d86 - 62%.
Ну это очень далеко до того, чтобы там иметь какие-то существенные проблемы в тестировании патчей, и да, особо он не меняется с усилением движка, ну в лучшем случае очень медленно. |
|
|
| номер сообщения: 54-31-8048 |
|
|
|
|
Vizvezdenec:
...
Вас не смущает то, что книга для PT отличается от книги для собственно тестирования? На ней процент ничьих и правда выше.
А если брать % ничьих для книги для тестирования, то для LTC обычного он https://tests.stockfishchess.org/tests/stats/6810d0d63629b02d74b16758 56% примерно
...
Ну это очень далеко до того, чтобы там иметь какие-то существенные проблемы в тестировании патчей, и да, особо он не меняется с усилением движка, ну в лучшем случае очень медленно. |
Да, процент пока не критичен, тем более что тесты идут на одном ядре. А вот изменения процента я определенно наблюдаю. Важна ведь и динамика. И тут не принципиально 62 или 66 процентов. Может быть действительно изменения процента меньше чем кажутся и нас действительно ждет ещё 15 лет разработки. Чтобы уточниться мне интересно бы узнать какой процент даст первый регрешн-тест против SF 18.
А небалансная книга будет постепенно скатываться в весьма специфические позиции. Большинство оценок около +0.9 будут постепенно понижаться к нулю. Оценки около +1.1 стремиться к бесконечности. Эти позиции будут удаляться из набора. С оценкой около +1 будет оставаться все меньше позиций и они будут все более и более своеобразные. То есть книга будет становиться все менее репрезентативной.
У идеального движка оценок около +1 быть не должно бы (если оценочная функция справляется). Они должны быть либо 0, либо мат. Но если оценочная функция не идеальна, то по крайней мере не должно быть результативных пар партий. |
|
|
| номер сообщения: 54-31-8049 |
|
|
|
|
Гроссмейстер Хикару Накамура сыграл с победителем TCEC Swiss 7 Leela Chess Zero промо-матч с форой на коня.
Грэм Бэнкс комментирует: «Хикару Накамура сыграл 16 партий с LeelaKnightOdds на 3'+2″, выиграв первую партию, сыграв вничью последнюю и еще одну, и проиграв 13, включая десять подряд! Его результат в 12,5% был на самом деле намного лучше, чем у других ведущих гроссмейстеров против той же версии; игроки из 50 лучших в мире (ФИДЕ) набрали всего 4% в 80 играх до этого, без единой победы! |
|
|
|
| номер сообщения: 54-31-8050 |
|
|
|
|
Ерунда написана, причём именно фактическая.
Потому что LeelaKnightOdds использует специально натренированную нейросеть отдельную для игры с форой именно в коня, и совсем не ту же самую, которая играла в швейцарке.
Более того, если я правильно понимаю, там что-то и с поиском химичили, чтобы результаты не ухудшались с увеличением времени на ход.
Так что это да, лила, но "всего лишь" имеющая другой поиск и другую оценку, что в целом и делает её по факту достаточно другим движком. |
|
|
| номер сообщения: 54-31-8051 |
|
|
|
|
| А если бы Хикару играл с настоящей Leela Chess Zero с форой в коня, каков был бы прогнозируемый результат в этом случае? |
|
|
| номер сообщения: 54-31-8052 |
|
|
|
|
| Ну тут сложно сказать, но, я думаю, результат был бы лучше на десятки процентов. На какие именно десятки - 10 или 70, судить мне так очень сложно, данных-то никаких по факту. |
|
|
| номер сообщения: 54-31-8053 |
|
|
|
|
| номер сообщения: 54-31-8054 |
|
|
| |
|
|
|
|
|
|
|
| Copyright chesspro.ru 2004-2025 гг. |
|
|
|
