А есть информация по конкретному железу сервера? Модель процессора(ов) и включён ли гиперсридинг?
Ещё интересует обоснованность (помимо финансовых возможностей организаторов) использования именно такого количества хэша. С одной стороны 44 потока (особенно если это физические ядра) могут эффективно "провертеть" куда большие хэш-таблицы. Гудини 5, как я понимаю, поддерживает до 128 гигов, а Стокфиш 8 вообще до терабайта. С другой стороны при таком контроле этих 32-ух гигов может быть даже много. То есть эло может даже немного падать из-за слишком больших хэш-таблиц. Как считаете?
Ещё интересна настройка contempt у обоих движков. У Стокфиша 8 она по умолчанию стоит на ноль (то есть сильнейшая игра с максимальными ничейными тенденциями). Разве у Гудини 5 она по умолчанию не смещена в пользу переоценки своей позиции? Я его не покупал, не могу посмотреть. Как организаторы к этому относятся? Типа раз так решил разработчик, значит пусть участвующий движок играет с такой настройкой?
tahoma: А есть информация по конкретному железу сервера? Модель процессора(ов) и включён ли гиперсридинг?
Ещё интересует обоснованность (помимо финансовых возможностей организаторов) использования именно такого количества хэша. С одной стороны 44 потока (особенно если это физические ядра) могут эффективно "провертеть" куда большие хэш-таблицы. Гудини 5, как я понимаю, поддерживает до 128 гигов, а Стокфиш 8 вообще до терабайта. С другой стороны при таком контроле этих 32-ух гигов может быть даже много. То есть эло может даже немного падать из-за слишком больших хэш-таблиц. Как считаете?
Ещё интересна настройка contempt у обоих движков. У Стокфиша 8 она по умолчанию стоит на ноль (то есть сильнейшая игра с максимальными ничейными тенденциями). Разве у Гудини 5 она по умолчанию не смещена в пользу переоценки своей позиции? Я его не покупал, не могу посмотреть. Как организаторы к этому относятся? Типа раз так решил разработчик, значит пусть участвующий движок играет с такой настройкой?
1) Модель процессора и вообще параметры написаны в Rules -
Season 9 Superfinal server
CPUs: 44 Cores -> 2 x Intel Xeon E5 2699 v4 @ 2.8 GHz
Motherboard: Supermicro X10DRL-i
RAM: 128 GB DDR4 ECC
SSD: Crucial CT250M500 240 GB
Chassis: Supermicro
OS: Windows Server 2012 R2
Разумеется, никакого гипертрейдинга :)
2) Насчёт хэша-понятия не имею, почему столько. Честно, не очень хорошо разбираюсь в том, на что это влияет :)
3) По умолчанию настройка contempt у обоих движков стоит 0. А вообще эту настройку разработчик движка вносит, как ему больше понравится, так и будет. Комодо в каждой стадии разные ставит, стокфиш ставит нули всегда. Единственное что включено у Гудини-небольшая отрицательная оценка за троекратное, чтобы игры ими не заканчивались рано.
Vizvezdenec:CPUs: 44 Cores -> 2 x Intel Xeon E5 2699 v4 @ 2.8 GHz
RAM: 128 GB DDR4 ECC
Разумеется, никакого гипертрейдинга :)
2) Насчёт хэша-понятия не имею, почему столько. Честно, не очень хорошо разбираюсь в том, на что это влияет :)
3) По умолчанию настройка contempt у обоих движков стоит 0. А вообще эту настройку разработчик движка вносит, как ему больше понравится, так и будет. Комодо в каждой стадии разные ставит, стокфиш ставит нули всегда. Единственное что включено у Гудини-небольшая отрицательная оценка за троекратное, чтобы игры ими не заканчивались рано.
Очень интересно. Из этого следует, что сервер довольно тонко настроен, чтобы выжать максимальную производительность на каждый поток. Параметры для этого процессора не стандартные. Плюс организаторам.
По хэшу, скорее всего, дело в степени двойки. Многие движки (Стокфиш точно) на самом деле не умеют работать с промежуточными значениями параметра размера хэша, а только с теми, которые являются степенью двойки. То есть можно задать 8, 16, 32, 64 гигов и так далее, но если задать, например, 37, то реально будет использоваться только 32. Если обоим движкам задать хэш в 64 гига, то он не влезет в память (2 по 64), так как хоть сколько-то нужно системе. Поэтому вынужденно используется только 50% всей оперативной памяти.
По contempt вопрос понятен. Как я и предположил - организаторы подразумевают, что разработчик знает лучше всех при какой настройке его движок наиболее силён.
Кстати, наблюдаю у Стокфиша неприятное поведение при использовании Syzygy-таблиц. Он медленно наращивает потребление памяти до бесконечности, пока она не кончится. Есть ли способ борьбы? При отключённых таблицах потребление памяти соответствует настройке хэша.
tahoma: Кстати, наблюдаю у Стокфиша неприятное поведение при использовании Syzygy-таблиц. Он медленно наращивает потребление памяти до бесконечности, пока она не кончится. Есть ли способ борьбы? При отключённых таблицах потребление памяти соответствует настройке хэша.
Ох, что-то такое я в чате TCEC читал, но как бороться-забыл :) Что-то связанное с сизиги в настройках править надо, только совсем не помню что. Да и лично я вообще движки себе никогда не ставил, просто смотрю за их игрой Из нового-забавная ситуация, оценка стокфиша сейчас зависла на +3,03 и показывала лишнюю строенную пешку, которую вроде как нельзя реализовать, гудини тоже это видел, но потом сам разрушил потенциальную крепость и проигрывает.
Что ж, лишнее подтверждение того, что движкам ещё есть куда расти :)
Вот что нашёл
https://groups.google.com/forum/#!topic/fishcooking/kto46FKCGgo
Что-то непонятно, похоже, что организаторы решили серьёзно проверить вариант Тарраша, уже вторая пара партий на эту тему.
После Каспарова этим вариантом наверно никто серьёзно не занимался, и вот опять?
__________________________
pr.ai PRAI Portal of Robotics and Artificial Intelligence
Вот это да!
Похоже, Гудини хочет применить против варианта Тарраша план Смыслова, по которому он действовал в претендентском матче с Каспаровым, - расположить слонов на g2 и g1!
__________________________
pr.ai PRAI Portal of Robotics and Artificial Intelligence
Индусы замутили умную шахматную доску на Кикстартере. Можно играть друг с другом, можно с программой. Фигуры движутся автоматически.
Уже собрали заказов на £131,356
__________________________
pr.ai PRAI Portal of Robotics and Artificial Intelligence
Vizvezdenec:Из нового-забавная ситуация, оценка стокфиша сейчас зависла на +3,03 и показывала лишнюю строенную пешку, которую вроде как нельзя реализовать, гудини тоже это видел, но потом сам разрушил потенциальную крепость и проигрывает.
Что ж, лишнее подтверждение того, что движкам ещё есть куда расти :)
Подобные заскоки традиционно наблюдаются при игре самых разных движков. Собственно, именно поэтому была введена такая "стилистическая" настройка для алгоритма игры - contempt, то бишь "самоуверенность" движка, его "настрой" на бой или на ничью.
Я потому и спрашивал про неё. У меня под рукой есть Гудини 4, 3 и 1.5. В них всех эта настройка имеет минимальный сдвиг в пользу переоценки своей позиции. Иными словами, движок будет пытаться избежать ничьи, даже если это приведёт к поражению. Он может не пойти на троекратное или сдвинуть пешку 50-м ходом, избегая ничьи по правилу 50-ти ходов.
У Стокфиша стоит дефолтный ноль, он будет выбирать сильнейший ход, даже если точно видит, что это ничья. Если у кого-то есть Гудини 5 - проще всего запостить сюда вывод команды UCI в консоли движка. Уже выпущен патч 5.01. Там, кстати, как раз меняли диапазон этой настройки.
Vizvezdenec:Вот что нашёл
https://groups.google.com/forum/#!topic/fishcooking/kto46FKCGgo
Угу, само собой, файл подкачки выключен из общих соображений. Память всё равно заполнится. Там пишут, что винда сама освобождает память при новых потребностях (запуск другой программы, например), удаляя наиболее старые части кэша Syzygy-таблиц. Так то оно так, но винда тем и славна, что может падать в синий экран в такой ситуации. Рисковать этим совсем не хочется.
Короче говоря, это требует от авторов Стокфиша встроить в движок ручную очистку старых блоков кэша Syzygy-таблиц из памяти. Многие движки это делают. В том же Гудини есть настройка ограничения размера памяти под кэш разных видов эндшпильных таблиц.
Недостаток, не баг, но недостаток Стокфиша. Разработчики понадеялись на адекватность виндового управления памятью. Зря.
Во время ближайших партий чемпионского матча (человеческого ) я, конечно, попробую отпустить винду на волю. Посмотрю, рухнет ли оно в синий экран. Но я настроен скептически.
Нет в Cтокфише ни старых блоков кэша, ни новых блоков, да и вообще никакого кэша Syzygy-таблиц нет. Вообще никакого.
Там только memory-mapped файлы (ну и крохотный кусочек памяти фиксированного размера на заголовок таблицы).
Единственный способ принудительно заставить систему освободить память - закрыть mapping и переоткрыть файл таблицы заново.
dm_litv: Нет в Cтокфише ни старых блоков кэша, ни новых блоков, да и вообще никакого кэша Syzygy-таблиц нет. Вообще никакого.
Там только memory-mapped файлы (ну и крохотный кусочек памяти фиксированного размера на заголовок таблицы).
Единственный способ принудительно заставить систему освободить память - закрыть mapping и переоткрыть файл таблицы заново.
Почему другой движок с включёнными Syzygy-таблицами не съедает всю доступную память? Делает именно это? Закрывает-открывает?
Зачем в других движках есть настройка размера памяти под работу эндшпильных таблиц и как тогда эта настройка даёт результат? Магия?
Это не магия, это разные проектно-архитектурные решения, реализованные в разных движках.
Подход #1. Движок запрашивает себе кусок памяти и забивает его позициями из endgame tables (неважно, что там - Налимов/Sygydy/пупкин...). Потом, когда-то, движок этот кусок памяти освобождает.
Как и в случае с "обычным" кэшем не-эндшпильных позиций.
Подход #2 (Stockfish). Движок запрашивает одну позицию из endgame tables. Если позиция/ее_оценка представляются движку интересной/полезной, то движок сохраняет ее в своем "обычном" кэше не-эндшпильных позиций. При этом вся база эндшпильных позиций - для движка как длинная кинолента, из которой он смотрит то кадр(позицию) 01:45, потом кадр 02:37 и т.д.. Но операционная система вытаскивает в память не один кадр, а целую минуту 01:00-01:59, а потом 02:00-02:59. И при этом система не выбрасывает эти минутные фрагменты - "А вдруг хозяин захочет посмотреть что-то рядом?".
А у хозяина нет возможности сказать - "Нет, мне только этот один кадр и выбрось его сразу же".
Кто прав и кто виноват? - "Известно кто".
Подход #2 концептуально проще для реализации (т.к. всё нужное будет перенесено в кэш "обычных" позиций, а управление им уже реализовано).
Да, Вы правы в том, что это основывается на уверенности в корректности базовых механизмов управления памятью в ОС. Да, я понимаю Ваши сомнения в их непогрешимости. Однако мой многолетний опыт участия в разработке высоко-нагруженных программно-аппаратных комплексов (связанных отнюдь не с передвижением деревянных фигурок по черно-белым квадратикам) как-то подсказывает мне, что windows справится. Я не фанат ни windows, ни stockfish; просто мне так кажется.
Ох, чего-то длинно и непонятно получилось. Наверное, офтоп всё это да и мало кому интересно. Пишите в приват, отвечу подробнее.
PS. Да, забыл очевидное сказать.
В linux подход #2 работает, и проблем никаких Вы наблюдать не будете.
А код в stockfish один и тот же.
Ну, кроме, конечно, самого системного вызова, который выполняет мэппинг файла в память.
Пока суть да дело, Гудини выиграл ещё одну партию, причём я не понял как-мне казалось, что из такой намертво закрытой позиции выжать ничего не выйдет уже ни у кого. Впрочем, стокфиш разозлился и катает следующую партию на победу.
dm_litv, спасибо за разъяснения. Не бойтесь, я компьютерщик (средненький такой, коротко говоря), так что суть я полностью уловил, ваши усилия по написанию не пропали даром.
Собственно, я как раз и ратую, чтобы движок использовал подход номер 1, ибо с пелёнок занятия этой профессией приучен, что при виде 99% загрузки ОЗУ под виндой надо срочно бить тревогу. В линукс я как раз очень даже верю.
Затестил Стокфиш на только что окончившейся партии Карлсен-Карякин. Действительно, в какой-то момент все 16 гигов моего компа забились, но потом ещё несколько часов всё работало, не рухнуло. Ладно, буду стараться верить в винду.
tahoma: Вообще, должен сказать, пока рано короновать Стокфиш. При таком разрыве и таком числе ещё не сыгранных партий - победа Гудини очень даже возможна.
Если Гудини победит - куплю.
Ну по всем тестам, там разницы где-то 20 эло в пользу стокфиша(возможно, чуть больше в личном противостоянии).
По партиям видно, что есть позиции, где стокфиш сильнее, есть те, где сильнее Гудини (пока что ни одного дебюта не закончилось дважды победой белых-вторая сторона всегда делала ничью).
Но сейчас, похоже, счёт станет 8-3, стокфиш показывает +3.45 в эндшпиле, да и визуально он должен быть выигран :)
Ну вот и опять-белыми стокфиш потихоньку выкрутил руки, оценка ни разу не падала ниже 0.7, чёрными же после e4! вышел в чуть худший эндшпиль (причём ходов 12 там из PV самого первого хода повторили оба движка) и легко его удержал. А всё почему? Потому что Гудини сделал другой первый ход по выходу из книги :)
Пока стокфиш с гудини делают очередную ничью в сицилианке, незаметно подкрался экватор суперфинала (как раз 50-я игра идёт).
Счёт 9-3 в пользу стока (хотя на деле 8-3 должно быть), 20 с лишним процентов результативных партий-уже успех (в прошлом сезоне было 11 результативных из 100).
Так как код Стокфиша открыт, злые языки говорят, что разработчики Комодо приспосабливают свой движок под самые мелкие особенности Стокфиша, за счёт чего и побеждают его. В прошлом сезоне играли Комодо и Стокфиш - близкие по коду движки имели много ничьих, это логично. Гудини же гораздо более независимая разработка. По наблюдениям он ведёт себя явно иначе и в наборе глубины, и в оценке позиции. Вот и результат.
tahoma: Так как код Стокфиша открыт, злые языки говорят, что разработчики Комодо приспосабливают свой движок под самые мелкие особенности Стокфиша, за счёт чего и побеждают его. В прошлом сезоне играли Комодо и Стокфиш - близкие по коду движки имели много ничьих, это логично. Гудини же гораздо более независимая разработка. По наблюдениям он ведёт себя явно иначе и в наборе глубины, и в оценке позиции. Вот и результат.
Недавно был миниматч, в котором на 20-ядерном процессоре состязались последний сток и комодо с временным контролем 20'+5''. Сток выиграл +15 -1 =84. Так что это такое себе) Да и на деле как приспособить движок под движок противника? Это требует больше тестирования, нежели приспособить его играть против себя (идеология fishtest в этом и состоит, собственно).
А возросшая результативность связана с большей бескомпромиссностью дебютов скорее всего.
Да, распространение злобных завистливых слухов - меня не красит, признаю.
Я понятия не имею о достоверности этих утверждений, читал что-то подобное в обсуждениях на форуме Стокфиша.
Кстати, насколько я понимаю, Стокфиш был традиционно несколько сильнее на коротких контролях в силу методики его тестирования. Разработчики используют в качестве тестирования большое количество очень быстрых партий. И, кстати, вроде (уже совсем давно) читал, что автор Гудини делает также. А вот про Комодо я наименее осведомлён.
Ну а про фиштест я только краем уха слышал. В чём именно заключаются его особенности вообще не знаю.
tahoma: Да, распространение злобных завистливых слухов - меня не красит, признаю.
Я понятия не имею о достоверности этих утверждений, читал что-то подобное в обсуждениях на форуме Стокфиша.
Кстати, насколько я понимаю, Стокфиш был традиционно несколько сильнее на коротких контролях в силу методики его тестирования. Разработчики используют в качестве тестирования большое количество очень быстрых партий. И, кстати, вроде (уже совсем давно) читал, что автор Гудини делает также. А вот про Комодо я наименее осведомлён.
Ну а про фиштест я только краем уха слышал. В чём именно заключаются его особенности вообще не знаю.
http://tests.stockfishchess.org/tests
Собственно, если вкратце-новая версия наигрывает кучу игр против старой на временном контроле 10+0.1 секунды за партию, если там есть прирост минимум в 1 эло, делает то же самое на временном контроле 60+0.6 секунды.
Для определения того, есть ли там такой прирост, используется такая вот математическая модель. Собственно, необходимое условие-+1 эло на коротком и длинном временном контроле.
Ну это если вкратце) На деле там для сокращения кода прирост эло не обязателен, а для изменения констант он меньше, +1 эло это для новых каких-то вещей, которые увеличивают размер программы и её логику меняют.
А по поводу тестирования-автор Гудини достаточно подробно отвечал в чате. В общем-то шахматы среди движков всегда были и будут некоторой игрой со статистикой, то есть оттестировать что-то на временных контролях длиннее нескольких минут вообще не представляется возможным ни для кого-ни у кого нет счётных ресурсов для получения хотя бы сколько-нибудь значащих статистических результатов. Ни у него, ни у разработчиков Комодо, ни у стокфишевцев. Так что поведение программ на супер-длинных временных контролях и очень мощных машинах - вещь, которую толком никто и никогда не тестирует.
Конечно, я видел тесты, где на 32-ядерных машинах на фиштесте считали прирост эло от какой-то там переделки с хэш-таблицами, но они крайне редки, обычно всё делается для 1 ядра.
А что из стокфиша народ берёт успешные идеи-это вообще вполне нормально, да и самих стокфишевцев не особо беспокоит-они занимаются проектом в свободное от работы время и для собственного развлечения, заодно двигают вперёд все движки.
Например, автор Andscacs, ММ из Андорры (кстати, играл на шахматной олимпиаде не так давно :)), говорит, что 70-80% новых идей в его движке - из опен-сорсных движков, в первую очередь из стока. Ничего, движок оригинальный вполне, и неслабый-в 3 стадии даже Комодо белыми разгромил в одной партии.
А вообще автор опенсорсного второго движка по силе Gull в своё время так про это говорил.
Пока там люди выигрывают, сегодня стокфиш делает десятую победу в варианте Дракулы-Франкенштейна венской партии, опять переиграв Гудини в головоломнейшем эндшпиле-я вот совершенно не понял, каким образом, счёт становится +10-3=42.
Уже =43, в обратной партии гудини не смог победить.
) я, конечно, попробую отпустить винду на волю. Посмотрю, рухнет ли оно в синий экран. Но я настроен скептически.
