Шахматная страничка Сергея и Дмитрия

    

КАК УСТАНОВИТЬ Что такое Winboard? Все движки WB Другие интерфейсы DOWNLOAD NEW!! TOPLIST-1 TOPLIST-2   TOPLIST-3  TOPLIST-4  TOPLIST-5 TOPLIST-6 Российские движки Движки UCI (ARENA) UTIL   Бесплатные программы/Freechess Движки для ChessBase Шахматные продукты от Chess Assistant Партии А.Д.Петрова   Читатели обсуждают "Человек и компьютер" "Прыжок Ливитского" Совместимость Архив 2001 года   Новости 2002 года Новости 2003 года Новости 2004 года Новости 2005 года Об авторах Наши ссылки (Links) Интервью с авторами программ

Интервью\Interview

Предлагаем вашему вниманию новое  и давно обещанное  интервью с ведущим российским программистом, автором знаменитого движка SmarThink - Сергеем Марковым, который недавно был гостем SDChess!

1. Сергей, скажите, насколько на Ваш взгляд,  имеют под собой почву участившиеся в последнее время разговоры по поводу создания клонов? Насколько возможны прямые заимствования при создании  шахматных программ из открытых исходных файлов других авторов? Или же возможно заимствование только самих идей, что, наверное, неизбежно, а их практическая реализация в той или иной программе всегда носит авторский отпечаток.   Не превращаются  ли в таком случае  открытые исходные файлы известных авторов (Fruit, Crafty  и др.) в священную корову,  и  становится ли в таком случае  их "открытость"  своей полной  противоположностью?

            По сути дела, активное обсуждение проблемы клонирования в компьютерно-шахматном сообществе было подстегнуто появлением движка Fruit, который, будучи программой с открытым исходным кодом, по силе своей игры оказался сравним с лучшими коммерческими движками. Думаю, что сегодня компьютерное сообщество  несколько переоценивает важность проблемы клонирования. Эта переоценка была спровоцирована, во многом, особенностями самого движка Fruit. Его оценочная функция и алгоритм перебора в известной мере тривиальны, и последние версии Fruit с открытым кодом не содержат множества техник, считавшихся весьма ценными по крайне мере последние 10-15 лет, что делает этот движок привлекательным «каркасом» для изготовления потенциально более сильных версий на его основе. Однако, опыт и практика шахматного программирования за последнее десятилетие убедительно показал, что наличие сильного движка с открытым кодом совершенно не гарантирует появления его сильных клонов. Например, на протяжении длительного времени движок Crafty д-ра Хьятта, так же будучи программой с открытым кодом, в то же время был одной из сильнейших бесплатных программ. Да, клоны Crafty периодически появлялись, но они не могли оторваться от своего родителя хотя бы на 15 пунктов. Проблема заключается в том, что каждый движок представляет собой законченную модель и не всякая модификация, которая приводит к улучшению игры движка А, будет в то же время хороша и для движка Б. Как говорится в пословице — «что русскому хорошо, то немцу смерть», да простят меня немецкие читатели. Это особенно касается тех незначительных изменений, которые возможны в движке, достигшем определенного локального максимума в своем развитии. Автор сильного движка имеет куда больше шансов усовершенствовать его, чем те, кто не смогли создать самостоятельно свой сильный движок. В какой-то мере существование сильного движка с открытыми исходниками может помочь начинающим шахматным программистам, но я думаю, что начинающим программистам нужно довольно много времени для того, чтобы достичь определенной глубины понимания проблем и методов шахматного программирования, чтобы суметь самостоятельно усовершенствовать исходный движок. Да и, кроме всего прочего, не сочтите это за нескромность или желание произвести сенсацию, с точки зрения архитектуры тот же Fruit отнюдь не является образцом. Существующая в нем комбинация генератора ходов, основанного на списках, и системы битовых таблиц делает его весьма неудобным прототипом для «движка будущего». В пользу этого мнения во многом свидетельствует успех Рыбки, которая основана на чистой технологии битовых таблиц. Дело в том, что развитие 64-битных процессоров делает этот подход все более привлекательным. Использования таких процессоров со специальными версиями Рыбки и SmarThink (тоже чисто табличного движка) позволяет достичь, порой, 30-35% прироста скорости расчета, в то время как 64-битная версия Fruit вряд ли сможет получить и 10% прироста производительности.

            Что касается второй части вопроса, то здесь ситуация довольно запутанная. Дело в том, что кроме совершенно явных случаев клонирования, существует множество примеров частичного заимствования, так и больших фрагментов кода (с изменением только системы доступа к структурам данных), так и определенных идей. Вообще-то движки с открытыми исходниками как раз и появляются для того, чтобы сделать идеи, использованные автором, доступными компьютерному сообществу. Однако порой довольно сложно провести грань между заимствованием идеи и прямым заимствованием фрагмента кода. Особенно тогда, когда сходны используемые в движках структуры данных. Но мне хотелось бы заметить, что даже в случае, когда структуры данных двух движков похожи, прямое заимствование вряд ли может принести сколь-нибудь значимые результаты.

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

            Есть и другой подход к проблеме клонирования. Мне лично весьма импонирует работа группы CCRL (http://www.computerchess.org.uk/ccrl/4040/). Они рассчитывают степень близости оценок различных движков и долю угаданных движком ходов оппонента. Соответствующие таблицы можно увидеть вот здесь: http://www.computerchess.org.uk/ccrl/4040/eval-difference-table-all.html; http://www.computerchess.org.uk/ccrl/4040/engine-distance-table-all.html. Второй тест наиболее эффективен, т.к. нечувствителен к изменению выводимых значений оценочной функции. Во второй таблице видно, что коэффициент разницы между явным клоном и прямым потомком родителя (Toga 1.1a и Fruit 2.2-2.2.1) составляет 1,68. Далее в таблице следуют пары последовательных версий движков, и, наконец, только на 9 месте появляются действительно разные движки — пара Pharaon 3.3 — Ruffian 2.1.0 «набрала» 3,85 очка. Далее в таблице встречаются уже исключительно пары независимых движков.

            2. Какой язык программирования больше всего подходит для написания шахматных движков и почему?

            Вопрос это на самом деле не простой. 95% нынешних движков написаны на C/C++. Но вызвано это не столь удобством их использования, сколь наличием лучших оптимизирующих компиляторов для этих языков, возможностью использовать эти языки практически для всех аппаратных платформ, ну, и, разумеется, существованием множества наработок в области шахматного программирования именно на этих языках. Мне кажется, что ситуация здесь вряд ли изменится в обозримом будущем. Есть, правда, специфические проекты вроде Symbolic, написанного на языке Lisp, но это именно академические проекты, очень далеко отстоящие от наиболее сильных программ.

             3. Недавно Вы где-то публично сказали, что планируете написать для  SmarThink собственную оболочку? Можно ли поэтому предположить, что все существующие  интерфейсы, включая ChessBase  и Arena,  Вас не вполне устраивают? Если да, то не могли бы Вы остановиться на наиболее существенных недостатках этих GUI, поскольку среди широкого круга любителей шахмат бытует мнение, что эти оболочки (по крайней мере  ChessBase-ие) лишены серьезных изъянов.

            Когда может появиться Ваша собственная оболочка, какие протоколы она будет поддерживать, какие возможности Вы обязательно планируете включить в нее и будет ли она платной?

            Да, такие планы у меня есть. На мой взгляд, оболочки ChessBase и Arena действительно очень хороши, но и они не лишены серьезных изъянов. Для меня, как шахматного программиста, наиболее болезненными являются изъяны в реализации протоколов обмена данными оболочки и движка, низкой степенью прозрачности некоторых механизмов. Не всегда радует и архитектура интерфейса — он недостаточно гибок в большинстве случаев при организации тестирования. Оболочка ChessBase на мой взгляд некорректно учитывает время (в партиях с движками), содержит ряд непонятных ограничений в отношении выбора схемы контроля времени, не имеет открытых стандартов для дополнительных функций движков (например, функция “explanator”). Информация не изо всех панелей может легко копироваться и переноситься в другие приложения, отсутствуют многие, на мой взгляд, весьма полезные функции. У «Арены» тоже есть свои проблемы. Например, в свое время я столкнулся с тем фактом, что движок со сравнительно агрессивным выводом данных существенно замедляет свою работу под «Ареной», по сравнению с ChessBase’овской оболочкой. Конечно, авторы этих оболочек проделали в свое время титаническую работу, но все же их творения далеки от идеала. Именно это и внушает веру в возможность определенного прогресса в этой области.

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

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

            Да, «рыбкомания» действительно захлестнула мир компьютерных шахмат. Впрочем, лавры Васика достались ему вполне по заслугам. Рыбка — это действительно сенсация.

              Конечно, как и, наверное, всех других авторов движков, меня очень интересуют секреты Рыбки. У меня не только есть определенные соображения на этот счет, но, более того, некоторые из новых идей я обсуждал с Васиком лично. Так что, не все, к сожалению, я могу рассказывать… Подход автора «Рыбки» отличается смелостью и прагматичностью. Чего стоит хотя бы заявление о том, что «шахматные знания — это то, что позволяет выигрывать партии, иначе — это не знания». Действительно, Васик подверг сомнению святость многих коров шахматного программирования — методов, которые неизменно кочевали из движка в движок и считались однозначно эффективными. «Рыбка», порой, демонстрирует полное игнорирование некоторых компонентов оценки, причем это игнорирование, обычно, оказывается уместным. Впрочем, сила «Рыбки» обусловлена не только и не столько революционными нововведениями, хотя их важность трудно переоценить, но и очень добротным решением известных проблем — оценки проходных пешек и т.д. Словом, «Рыбка» это сочетание не только двух революций — в оценке позиции и в переборе, но и весьма добротный фундамент. Посмотрим, сколько понадобится времени соперникам, чтобы преодолеть наметившийся разрыв.

5. Помнится, Вы как то говорили, что SmarThink — это движок, который Вы начинали писать довольно давно и некоторые его элементы, сейчас с позиции Вашего сегодняшнего опыта, кажутся Вам не совсем безупречными. Не планируете ли Вы в ближайшее время полностью заново переписать ST или при таком подходе многие сильные стороны движка, его изюминки, могут быть утрачены или их яркость сильно побледнеет?

За последнее время были переписаны существенные фрагменты кода движка. Думаю, что сейчас какая-то кардинальная переделка всего каркаса вряд ли необходима.

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

Вообще говоря, прежде всего я бы посоветовал не бросаться сразу же писать движок, а посвятить, сперва, хотя бы несколько месяцев изучению существующих наработок. Некоторые базовые материалы на можно найти на моем сайте (http://www.aigroup.narod.ru ), хотя он и не обновлялся уже довольно давно, там есть кое-что относящееся к категории «вечных ценностей». Но вообще говоря, этого мало. Самое лучшее место для начинающих шахматных программистов — это архивы CCC (Computer Chess Club) (http://www.talkchess.com; http://hornid.com/cgi-bin/ccc/forum_search.pl — поисковая система по CCC). Именно там и нужно рыться новичкам. Кроме этого очень полезным будет изучение движков с открытыми исходными текстами. Прежде всего, наверное, Fruit, Toga и Crafty. После их изучения можно смело браться за написание своего движка. При этом важно сразу же ставить жесткие требования к архитектуре движка и структурам данных. Именно их продуманность является залогом дальнейшего прогресса программы.

7. Как успешно продается  сегодня ST? Можно ли рассчитывать, что появится версия,  доступная по карману нашим соотечественникам, а также любителям шахмат из стран СНГ?

Продано несколько сотен копий движка. Это не очень много, особенно на фоне объемов продаж ChessBase, особенно во второй половине 90-х — начале 2000-х. Но я бы не сказал, что коммерческая сторона дела меня сильно заботит.

Что касается недорогой локальной версии ST, то я приложу все усилия к тому, чтобы она появилась. Эта версия, по-видимому, будет работать только под русскоязычной Windows, а ориентировочная цена движка на отечественном рынке, по-видимому, будет составлять в районе $8-12.

8.  В прошлый раз мы задавали  Вам вопрос об оптимальном контроле времени, который на Ваш взгляд, лучше всего определяет соотношение сил между движками. Мы сами, как и раньше придерживаемся той точки зрения, что  для выявления  сильнейшего следует проводить турниры с различными контролями времени и только на основе суммарных результатов можно определять сильнейший движок. Вместе с тем, существует точка зрения, согласно которой оптимальным контролем считается длинный контроль, который превышает показатель 1 минуту на ход. Какова Ваша точка зрения?

Конечно, длинный контроль времени позволяет лучше оценить слабые и сильные стороны движка, получить в целом более объективную картину; кроме этого, большинство практических шахматистов используют программы как инструмент анализа, что более соответствует длинным контролям. Однако каждая партия содержит случайный элемент в виде выбора дебюта и, поэтому, множество партий с более коротким контролем позволяют лучше оценить изменение силы игры движка, чем малое количество партий с длинным контролем. Впрочем, мы с Сергеем Оксюзовым и Александром Малютиным проводим и тестирование движка на длинных контролях. Пока что в нашей практике не было такого случая, чтобы версия усилилась на коротких контролях и при этом произошло статистически значимое ухудшение на длинных.

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

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

10. Когда может появиться  новая публичная версия ST и какие параметры шахматного рейтинга для нее вы считаете приемлемыми (полагаем, что текущая  версия ST  имеет рейтинг около 2700 единиц): 2750, 2800 или какие-то другие значения?

Довольно скоро появится версия 1.1, которая будет, ориентировочно, на 20-30 пунктов сильнее 1.0. Точные сроки назвать сложно, так как работу над движком я веду в свободное время, которое имеет тенденцию к неожиданному исчезновению.

11. Сергей, насколько я знаю, тестирование новых версий ST проходит с очень коротким контролем. Явное преимущество этого метода основано на том, что короткий контроль позволяет провести большое количество партий и дать «объективную оценку» той или иной версии. Чем большее количество партий  проводится, тем точнее оценка изменения силы игры движка (разумеется, что тестовая группа движков и компьютер остаются неизменными в течение всего теста). Использование такого контроля основано на допущении, что его изменение в сторону увеличения не приводит к качественному улучшению результатов. Вместе с тем, все мы знаем, что контроль времени прямо связан с силой игры, и, прежде всего, это определяется невозможностью человека рассчитать нужные варианты в течение короткого промежутка времени (речь идет о нескольких секундах или нескольких десятках секунд). В этой ситуации человек  принимает решение в большей  степени интуитивно, опираясь на свой опыт и чувство позиции. Если для человека значительно увеличить контроль времени (от нескольких секунд до нескольких минут в расчете на один ход), то количество ошибок (очевидно неправильно выбранных ходов) заметно снизится.  Программа делает выбор того или иного хода на основе формализованной оценки позиции после цепочки полуходов, на которые программа успевает заглянуть вперед. Чем короче цепочка, тем более вероятна неверная оценка позиции и выбор неверного хода.  Поэтому, на мой взгляд, подобное допущение может быть относительно верным, когда контроль времени изменен значительно, но не критически. Я полагаю, что изменение времени на обдумывание в 3, 5 и даже 10 раз не является критичным для изменения параметров силы движка, но изменение в  50,100 и более  раз может привести к результатам, которые  не всегда адекватны. Полагаю, что ограничиваться сверхкоротким контролем времени не совсем правильно, так как максимальную силу движок показывает именно при игре с контролем 60 минут на партию и более.

Что Вы думаете по этому поводу? Может быть, стоит что-то поменять в технологии тестирования, которую Вы используете?

Я уже говорил об этом выше. Еще 10 лет назад скорость машин была таковой, что контроль 5 минут на партию эквивалентен современным 20 секундам. Если бы системы контроля времени в оболочках и движках не вносили сюда существенной погрешности, то разницы не было бы вовсе. Шахматная игра — очень сложная система с точки зрения статистики. Колебания результатов матчей движок — движок настолько велики, что матча из 100 партий, например, категорически не достаточно чтобы сделать однозначный вывод по поводу того, какой из двух движков сильнее даже в том случае, если сила их игры различается на 50 пунктов. Практика проводимых нами тестовых турниров показывает, что вероятность, с которой один движок выиграет у другого в блиц, мало отличается от вероятности того, что он выиграет при длинном контроле. Именно поэтому при тестировании предпочтение отдается партиям с коротким контролем. Хотя, повторюсь, тесты на длинном контроле нами также осуществляются.

Большое спасибо за интересное и откровенное интервью, желаем новых успехов и будем ждать новых более сильных версий ST!

Спасибо!