|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
| номер сообщения: 54-31-5729 |
|
|
|
|
| Vizvezdenec: Официальный релиз Гудини 6. |
пошел тест на IPON |
|
|
| номер сообщения: 54-31-5730 |
|
|
|
|
Jeweller: | Vizvezdenec: Официальный релиз Гудини 6. |
пошел тест на IPON |
Уже почти прошёл 
Против SF8 в прошлый раз было 52%, в этот раз 54,5%.
Sf dev набирает где-то те же 54,5%.
В общем не особо понятно, кто из данных движков сильнее на данный момент. |
|
|
| номер сообщения: 54-31-5731 |
|
|
|
|
И как раз свежий тест от CCRL, но дело не только в нём...
Fire 6?  |
|
|
| номер сообщения: 54-31-5732 |
|
|
|
|
хорошее дело TCEC, стимулирует)
ps/ SugaR не пустят туда? |
|
|
| номер сообщения: 54-31-5733 |
|
|
|
|
Vizvezdenec:
Против SF8 в прошлый раз было 52%, в этот раз 54,5%.
Sf dev набирает где-то те же 54,5%.
В общем не особо понятно, кто из данных движков сильнее на данный момент. |
У релизного Гуди по умолчанию контемпт повышенный, а какой был в прошлый раз, неизвестно. |
|
|
| номер сообщения: 54-31-5734 |
|
|
|
|
Rom77: Vizvezdenec:
Против SF8 в прошлый раз было 52%, в этот раз 54,5%.
Sf dev набирает где-то те же 54,5%.
В общем не особо понятно, кто из данных движков сильнее на данный момент. |
У релизного Гуди по умолчанию контемпт повышенный, а какой был в прошлый раз, неизвестно. |
Вроде в тесте играется контемпт 0.
А по поводу Sugar... Это же стокфиш слегка по-другому закомпиленный. Не пустят. Как не пустят и McBrain, asmfish и т.д. |
|
|
| номер сообщения: 54-31-5735 |
|
|
|
|
Vizvezdenec:
Вроде в тесте играется контемпт 0.
|
Насколько я знаю, Инго тестирует с настройками по умолчанию. По крайней мере, когда он проверял Комодо с нулевым контемптом (не для рейтинга, для сравнения), то добавлял к названию индекс C0. |
|
|
| номер сообщения: 54-31-5736 |
|
|
|
|
Интересные результаты по распараллеливанию получил Гударт. При переходе с 20-ти на 40 ядер оценочно +64 эло прибавки. И это при достаточно приличном контроле 40+0,4:
40 hyper-threads (on 1 node ) vs 20 threads (on 1 node ): +13±10 Elo
80 hyper-threads (on 2 nodes) vs 40 threads (on 2 nodes): +11±12 Elo
80 hyper-threads (on 2 nodes) vs 20 threads (on 1 node ): +75±15 Elo
|
Он даже на гипертрейдинге с 40 ядер на 80 потоков умудрился получить прибавку, что вообще-то подразумевает линейный тренд масштабирования. Так что, кажется, большое число ядер может оказаться вполне востребовано. |
|
|
| номер сообщения: 54-31-5737 |
|
|
|
|
Rom77: Интересные результаты по распараллеливанию получил Гударт. При переходе с 20-ти на 40 ядер оценочно +64 эло прибавки. И это при достаточно приличном контроле 40+0,4:
40 hyper-threads (on 1 node ) vs 20 threads (on 1 node ): +13±10 Elo
80 hyper-threads (on 2 nodes) vs 40 threads (on 2 nodes): +11±12 Elo
80 hyper-threads (on 2 nodes) vs 20 threads (on 1 node ): +75±15 Elo
|
Он даже на гипертрейдинге с 40 ядер на 80 потоков умудрился получить прибавку, что вообще-то подразумевает линейный тренд масштабирования. Так что, кажется, большое число ядер может оказаться вполне востребовано. |
Если посмотреть тесты от fastgm, можно увидеть, что SMP даёт тем больше прибавки, чем больше временной контроль, как ни странно.
http://www.fastgm.de/schach/SMP-scaling-SF8-K10.4.pdf |
|
|
| номер сообщения: 54-31-5738 |
|
|
|
|
Скажите, а может кто-нибудь просветить меня, как работают движки на Chess24.com и тому подобных? Вот на кубке мира такой же. Полное впечатление, что они для каждого хода начинают считать с нуля, не используя варианты насчитанные для предыдущего хода. Через секунду дают оценку (довольно произвольную) которую хранят в маленьких иконках в расписании. Если я смотрю список партий и вижу большое преимущество игрока, то это не значит, что оно есть когда идешь в партию.
Это действительно трудно использовать дерево рассчитанное на предыдущем ходу или программисты поленились? Ну уж обновлять маленькие иконки через 10 секунд проблем быть не должно.
Кто вообще этот скрипт делал и можно ли им вопросы задавать? |
|
|
| номер сообщения: 54-31-5739 |
|
|
|
|
| Хэш, скорее, труднее не использовать. Ну, это надо после каждого хода каждый раз заново перезапускать движок с пустым хэшем, а зачем? |
|
|
| номер сообщения: 54-31-5740 |
|
|
|
|
Pigeon:
Это действительно трудно использовать дерево рассчитанное на предыдущем ходу или программисты поленились? |
Программы не используют дерево вариантов рассчитанное на предыдущем ходу. Они не запоминают это дерево даже в процессе перебора. От хода к ходу сохраняется только основной вариант, а также часть просмотренных позиций в хэш-таблицах (с оценкой и лучшим ходом), и вроде всё. Более того, даже когда при расчете текущего хода программа переходит на очередную глубину, она начинает расчет с нуля, используя сохраненный основной вариант, хэш, и статистику по перспективным/неперспективным ходам, собранную на предыдущей глубине. |
|
|
| номер сообщения: 54-31-5741 |
|
|
|
|
| Можно добавить, что на всех сайтах стоит почти одно и то же - фиксированное время поиска на ход и поэтому оценка "застревает" на определённом значении. Причём обычно время весьма малое и глубина, как следствие, совсем небольшая и оценка далеко не всегда реально отражает действительность. |
|
|
| номер сообщения: 54-31-5742 |
|
|
|
|
| Мне тоже так казалось. Но на лицо ужасная работа скрипта. Я хочу понять, могу ли я что-то изменить, может у скрипта какие-то настройки есть. |
|
|
| номер сообщения: 54-31-5743 |
|
|
|
|
| Vizvezdenec: Можно добавить, что на всех сайтах стоит почти одно и то же - фиксированное время поиска на ход и поэтому оценка "застревает" на определённом значении. Причём обычно время весьма малое и глубина, как следствие, совсем небольшая и оценка далеко не всегда реально отражает действительность. |
Я вижу, что для разных мест скрипта используют разное время поиска (и оценка разная). |
|
|
| номер сообщения: 54-31-5744 |
|
|
|
|
Rom77: Pigeon:
Это действительно трудно использовать дерево рассчитанное на предыдущем ходу или программисты поленились? |
Программы не используют дерево вариантов рассчитанное на предыдущем ходу. Они не запоминают это дерево даже в процессе перебора. От хода к ходу сохраняется только основной вариант, а также часть просмотренных позиций в хэш-таблицах (с оценкой и лучшим ходом), и вроде всё. Более того, даже когда при расчете текущего хода программа переходит на очередную глубину, она начинает расчет с нуля, используя сохраненный основной вариант, хэш, и статистику по перспективным/неперспективным ходам, собранную на предыдущей глубине. |
То есть даже если сделан лучший ход (по основному варианту) все расчеты идут с нуля? Казалось бы есть лучший ход в основном варианте и заменять его надо только если найден ещё лучше. Как при минимизации. Вы можете искать что хотите, но лучший предыдущий результат фиксируется. |
|
|
| номер сообщения: 54-31-5745 |
|
|
|
|
Pigeon:
То есть даже если сделан лучший ход (по основному варианту) все расчеты идут с нуля? Казалось бы есть лучший ход в основном варианте и заменять его надо только если найден ещё лучше. Как при минимизации. Вы можете искать что хотите, но лучший предыдущий результат фиксируется. |
Да, расчёт ведётся с нуля, но начинается он с сохраненного на предыдущем ходу основного варианта и идёт уже гораздо быстрее, поскольку поиск методом альфа-бета очень чувствителен к порядку рассмотрения ходов, и начинать его лучше с наиболее перспективного варианта, коим и является основной вариант с предыдущего хода/предыдущей глубины. Кроме того, если в процессе перебора встречаются позиции из хэш-таблицы, уже рассмотренные ранее, то информация о них тоже используется. |
|
|
| номер сообщения: 54-31-5746 |
|
|
|
|
| Хэш и хранит оценки просчитанных позиций, и рассчет не ведется "с нуля". Что я неправильно понимаю? |
|
|
| номер сообщения: 54-31-5747 |
|
|
|
|
| onedrey: Хэш и хранит оценки просчитанных позиций, и рассчет не ведется "с нуля". Что я неправильно понимаю? |
Всё верно, просто под расчетом "с нуля" я подразумеваю расчет с исходной позиции (той, что стоит на доске). И при переходе на следующую глубину, расчет снова начинается с исходной позиции. |
|
|
| номер сообщения: 54-31-5748 |
|
|
|
|
| Ну вот Gull, например, делает "easy move" с нулевым временем зачастую, если противник отвечает по его первой линии. Позволяет экономить время для более важных дел, но и игр из-за этого он немало проигрывает. Т.е. он полностью использует данные предыдущих рассчётов и вообще ничего не считает на этом ходу. Остальные движки пользуют стокфишевскую версию той же идеи - изи мув есть, но он не с нулевым временем, просто с маленьким. И если движок напротив играет примерно как ожидалось, график использования времени становится похож на пилу как раз из-за них. |
|
|
| номер сообщения: 54-31-5749 |
|
|
|
|
| номер сообщения: 54-31-5750 |
|
|
|
|
По утверждению автора файр прибавка составляет минимум 30 эло.
Это скорее всего сделает файр топ-4 движком, обойдя шреддер 13. |
|
|
| номер сообщения: 54-31-5751 |
|
|
|
|
http://www.chessdom.com/tcec-season-10-participants/
Шреддер отказался участвовать :( Зато есть Booot и ещё несколько новичков.
И на 1 стадию меньше, сам турнир будет короче. |
|
|
| номер сообщения: 54-31-5752 |
|
|
|
|
Из чата TCEC
Anton Mihailov
(Tournament Director)
More details: Gull will be a benchmark engine, also Gaviota
Benchmark engine: not updated for quite some time, and the advancement of new versions of the other engines can be measured compared between seasons via the performance against the benchmark engines
That sentence is a bit awkward, but I hope you get the idea |
|
|
| номер сообщения: 54-31-5753 |
|
|
|
|
Houdini и Fire обновились до версий 6.1
на XP, последний запускаться не хочет, и он не первый, становится все больше движков, не поддерживающих старые версии винды |
|
|
| номер сообщения: 54-31-5798 |
|
|
|
|
CCRL 40/40 протестировал SugaR XPrO 1.2 (вышла уже версия 1.3), который и возглавил список, впереди Komodo 11.2 и Houdini 6
на коротком контроле 40/4 впереди Houdini 6 в отсутствии Stockfish dev, SugaR и др. стокоподобных
на их сравнительный тест было бы взглянуть любопытно |
|
|
| номер сообщения: 54-31-5799 |
|
|
|
|
заканчивается тест с персоналиями СМ, в попытке воссоздать "эффект Fizbo"
пока посмотрел подробнее сравнительные данные для Fizbo 1.9, Shredder 13 и Fire 5 из CCRL для контролей 40/40 и 40/4
с условием, что сравниваются данные для одинаковых движков, по два представителя Стока, Комодо и Гудини, чтобы не было перекоса в сторону каких-то особенностей игры против определенных движков
по два не получилось, т.к. для обоих контролей Shredder 13 не тестировался против Houdini 6
данные для двух контролей проссумированы
дальше индивидуальные данные для Fizbo 1.9 и Shredder 13 из IPON-RRRL (Fire там не тестируется) против Houdini 6, Komodo 11.2.2 и Stockfish 8, которые также подтверждают наличие эффекта
при том, что рейт Fizbo на 53 пункта меньше, он побеждает более сильных в 2 раза чаще
 |
|
|
| номер сообщения: 54-31-5800 |
|
|
|
|
У Fizbo, кстати, есть ещё одна интересная особенность. Очень низкий процент совпадения выбираемых ходов с ходами других движков. Всего 35% по тесту sim:
см. запись от 2017/09/24 |
|
|
| номер сообщения: 54-31-5801 |
|
|
|
|
Rom77: У Fizbo, кстати, есть ещё одна интересная особенность. Очень низкий процент совпадения выбираемых ходов с ходами других движков. Всего 35% по тесту sim:
см. запись от 2017/09/24 |
это может быть косвенной подсказкой, откуда взялся эффект - одновременное сочетание "эффекта расслоения" с завышенным процентом побед и поражений против более сильных соперников и выражено низкий процент совпадения против всех движков в тестируемой группе, для меня говорит о перекосе в ОФ
и скорее всего, о намеренном перекосе, для достижения желаемого стиля игры
при этом, сила не оптимизирована, такой перекос должен ее снижать
или, с надеждой допускаю , автор нашел что-то такое, чего я не знаю про перекосы ОФ и их последствия
любопытно также видеть, у кого максимальный процент совпадений из всех пар, исключая две версии Стока между собой:
Гуди 5.01 - Сток 8
Гуди 5.01 - Сток 7
к чему бы это? ) |
|
|
| номер сообщения: 54-31-5802 |
|
|
| |
|
|
|
|
|
|
|
| Copyright chesspro.ru 2004-2024 гг. |
|
|
|
