TCEC 16 - Чемпионат Мира среди шахматных движков

[sovaz1997]

TCEC 16 начнется 14 Июля 2019 года в 17:00 (по МСК) с участием сильнейших шахматных движков в мире. Впервые в истории движок с нейронной сетью, Leela Chess Zero (Lc0), будет защищать как титул лиги, так и Кубок.



TCEC 16 будет представлен в новом формате. Он сохранит известный Премьер-дивизион и Суперфинал, как и в предыдущих сезонах, но даст больше шансов движкам, чтобы подняться в рейтинге. По этой причине будут созданы три лиги из 16 движков. Мероприятие начнется с Квалификационной лиги, где будут представлены все новички, включая новые движки AB и движки, использующие нейронные сети. Лучшие 6 из Квалификационной лиги перейдут в Лигу 2 (также 6 перейдут в низшую лигу), а лучшие 4 из Лиги 2 перейдут в Лигу 1 (также 4 перейдут в низшую лигу). Наконец, лучшие 2 движка из Лиги 1 будут квалифицированы в Премьер-дивизион (также 2 будут переведены в низшую лигу).

Изменение структуры для TCEC необходимо из-за быстрого развития компьютерных шахмат. С новым форматом больше движков получат шанс подняться и получить шанс войти в элиту.

Вот список участников для Премьер-дивизиона и вновь образованных лиг. Посев двигателей полностью основан на TCEC 15.

Суперфинал (100 игр с контролем 120′+10″ – используется новая дебютная книга от Jeroen Noomen)

Развернуть для просмотра

1. 1-е место Премьер-дивизиона
2. 2-е место Премьер-дивизиона

[свернуть]

Премьер-дивизион (3x DRR с контролем 90′+5″ – используется новая 8-ходовая книга от Cato (Nelson Hernandez))

Развернуть для просмотра

1. Lc0 – текущий чемпион TCEC
2. Stockfish
3. Komodo
4. AllieStein
5. Houdini
6. Komodo MCTS
7. 1-е место из Лиги 1
8. 2-е место из Лиги 1

[свернуть]

Лига 1 (1x DRR с контролем 45+5 - используется 6-ходовая дебютная книга, рандомизированная)

Развернуть для просмотра

1. Ethereal
2. Fire
3. Xiphos
4. Laser
5. Andscacs
6. Fizbo
7. Jonny
8. Chiron
9. Ginkgo
10. ChessBrainVB
11. Booot
12. Rofchade
13. из Лиги 2
14. из Лиги 2
15. из Лиги 2
16. из Лиги 2

[свернуть]

Лига2 (1x DRR with time control 30+5 – using a 4 move book, рандомизированная)

Развернуть для просмотра

1. Fritz
2. Nirvana
3. Arasan
4. Texel
5. Vajolet
6. Gull
7. Pedone
8. Nemorino
9. Rubichess
10. Pirarucu
11. из квалификационного раунда
12. из квалификационного раунда
13. из квалификационного раунда
14. из квалификационного раунда
15. из квалификационного раунда
16. из квалификационного раунда

[свернуть]

Квалификация (1x DRR с контролем 30+5 – используется 2-ходовая дебютная книга, рандомизированная)

18 движков бьются за 6 квалификационных позиций. Это смесь движков из 4-го дивизиона и новых.

Развернуть для просмотра

1. Bagatur 1.7b
2. The Baron 3.44.1
3. Cheese 2.1
4. chess22k 1.12
5. ChessFighterNN v2.1-n8x128c_7411
6. Igel 1.8.0
7. Jumbo 0.6.117
8. Marvin 3.4.0
9. Minic 0.76
10. ScorpioNN v2.9.0-n_maddex_INT8
11. Stoofvlees II a10
12. Topple 0.7.2_dev
13. Tucano 7.07
14. Wasp 3.68
15. Winter 0.6
16. Asymptote 0.6.2
17. Rodent III
18. Lc0 CPU

[свернуть]

Промо-движок в полевых условиях
Многие движки в настоящее время используют NN, полностью используя графические процессоры. Тем не менее, чемпион Lc0 выпустил сильную версию, играющую только на CPU! Это не уникальный движок по критериям TCEC, но, безусловно, приятно видеть, как он играет против реальных конкурентов с силой, превышающей 3000 пунктов Эло. Таким образом, Lc0 CPU входит в TCEC в качестве промо-движка. Он будет играть в дивизионе, но в конце турнира все результаты движка будут аннулированы.

[dew]

Цитата: Сообщение от Maratka

Занятно кстати... его вот так топорненько профилируют?

Ну да, с помощью команды bench
Ты в студии можешь так же, но мне это напоминает закат солнца в ручную - сначала нужно инициировать pgo, потом сделать какой-то инструментальный билд, потом проадейтить - и в итоге msvc половина кода прооптимизирует хреновенько и сборки от gcc окажутся быстрее

[sovaz1997]

Нормально профилируют, автоматизированно
И не надо никаких тяжеловесных студий.

[dew]

Цитата: Сообщение от sovaz1997

Нормально профилируют, автоматизированно
И не надо никаких тяжеловесных студий.

Ну да, вприципе bench проходится по всем важным веткам кода, которые важны для самой игры

[Maratka]

Цитата: Сообщение от sovaz1997

Нормально профилируют, автоматизированно

Это не значит "нормально", у меня например на реальных партиях (а не 40 позициях) выходит на 1-2% быстрее. Наверняка и там можно, другое дело, что действительно возни много.

[Maratka]

Цитата: Сообщение от dew

Ну да, вприципе bench проходится по всем важным веткам кода, которые важны для самой игры

Таблицы не учитываются, мультипоток не учитывается. Не так уж мало пропускается, выходит.

Зато есть архиважные шахматы Фишера. ;)

[Vizvezdenec]

bench по глубине > 14 не проходит, а для неё некоторые эвристики есть.

[dew]

Цитата: Сообщение от Vizvezdenec

bench по глубине > 14 не проходит, а для неё некоторые эвристики есть.

Ну так оформишь Pull request? ;-)

[dew]

Цитата: Сообщение от Maratka

Таблицы не учитываются, мультипоток не учитывается.

А что там в таблицах учитывать, применяя тафталогию, если учитывать, что они не у всех есть и даже если они есть, то сборка в душе не е.. чает где ты их у себя расположил?

Мульти поток.. А что там оптимизировать? Я реально не знаю - спрашиваю без подколов.. Но знаю, что с оптимизациями не зная броду можно доиграться и таких глупостей натворить, начиная от конкретных, заканчивая плоховоспроизводимыми багами на раз-два..

[Maratka]

Цитата: Сообщение от Vizvezdenec

bench по глубине > 14 не проходит, а для неё некоторые эвристики есть.

Ну вот наверное отсюда и получаются мои +1-2% сверх профилирования через bench

[Maratka]

Цитата: Сообщение от dew

А что там в таблицах учитывать, применяя тафталогию, если учитывать, что они не у всех есть и даже если они есть, то сборка в душе не е.. чает где ты их у себя расположил?
Мульти поток.. А что там оптимизировать?

Вот это и оптимизировать. Скажем поток ждет данные с диска, и ждет целую вечность, ибо любой диск- тормоз, а следовательно может за это время выполнить какую-то полезную работу.

[Maratka]

Цитата: Сообщение от dew

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

uci
setoption name Threads value 7
setoption name Hash value 8192
setoption name SyzygyPath value c:\wdl
position fen 5k2/2b2pp1/1p6/8/1P5P/2P3N1/3P4/4K3 b - - 0 1
go wtime 720000 winc 3000 btime 720000 binc 3000

[dew]

Цитата: Сообщение от Maratka

Вот это и оптимизировать. Скажем поток ждет данные с диска, и ждет целую вечность, ибо любой диск- тормоз, а следовательно может за это время выполнить какую-то полезную работу.

Мне прям уже стыдно в своем невежестве, но вопрос задам - PGO уже такой интеллектуальный, что и такое уже может?

[dew]

Цитата: Сообщение от Maratka

uci
setoption name Threads value 7
setoption name Hash value 8192
setoption name SyzygyPath value c:\wdl
position fen 5k2/2b2pp1/1p6/8/1P5P/2P3N1/3P4/4K3 b - - 0 1
go wtime 720000 winc 3000 btime 720000 binc 3000

А ничего, что у многих таблицы разные, но после такой сборки предлагать именно твой бинарь?

[Vizvezdenec]

Цитата: Сообщение от dew

Ну так оформишь Pull request? ;-)

Я не буду оформлять те PR, в которых не понимаю примерно ничего.
Для меня все эти профилирования и флаги компиляции звучат как китайский

[dew]

Цитата: Сообщение от Vizvezdenec

Я не буду оформлять те PR, в которых не понимаю примерно ничего.
Для меня все эти профилирования и флаги компиляции звучат как китайский

Очень жаль, консерваторы быстрее бы тебя послушали.
Хоть бы issue создал в манере вопроса " а вы знаете, что в bench > 14.. Может имеет смысл на эти ветки кода профилирование натравить?"

[dew]

Цитата: Сообщение от Maratka

Ну вот наверное отсюда и получаются мои +1-2% сверх профилирования через bench

А собери gcc-сборку и сравни кто в итоге быстрее?

[Maratka]

Цитата: Сообщение от dew

Мне прям уже стыдно в своем невежестве, но вопрос задам - PGO уже такой интеллектуальный, что и такое уже может?

PGO оптимизирует вызов и использование самых частых функций. Если движок часто ждет таблицы, и потому начинают активничать другие потоки - почему бы и нет?

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

Цитата: Сообщение от dew

А ничего, что у многих таблицы разные, но после такой сборки предлагать именно твой бинарь?

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

Цитата: Сообщение от dew

А собери gcc-сборку и сравни кто в итоге быстрее?

И собирать не нужно. На Abrok'е взял, сравнил: там чуть быстрее мультипоток, зато у меня однопоточный вариант.
Могу дать для "посмотреть". ;)

[Hendry]

я конечно понимаю что все это очень интересно, но тема про другое все же.

[Maratka]

Ничего страшного, чуть позже админы перенесут, куда-нить в обсуждение SF'ша например.

[dew]

Цитата: Сообщение от Maratka

PGO оптимизирует вызов самых частых функций. Если движок часто ждет таблицы, и потому начинают активничать другие потоки - почему бы и нет?

Я, прошу прощения, но поповоду пропустить дисковые операции в стиле I/O wait и заняться чем-то полезным - мне на такое хочется сказать "фантастика - в другом зале!" Но, окей, может я и не прав.. наверное

Цитата: Сообщение от Maratka

В результате код работы с таблицами будет собран по принципу "лишь бы было"

Есть мнение, что без PGO, но с максимальным уровнем статической оптимизации - бинарный код получается очень качественным. И вообще современные компиляторы пишут не дураки, а очень умные люди.

Цитата: Сообщение от Maratka

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

-03(gcc), Ox(msvc) - это общая оптимизация без данных
pgo - берет в учет данные что поступают, если bench для всех будет един и полезен всем, то твои специфичные ручные оптимизации для других могут обернуться бедой, кстати и для тебя тоже (на тесте были одни данные, а в реальности они могу сделать код неэффективным в других ситуациях)

Цитата: Сообщение от Maratka

И собирать не нужно. На Abrok'е взял, сравнил: там чуть быстрее мультипоток, зато у меня однопоточный вариант.
Могу дать для "посмотреть". ;)

аброк сборки медленные по определению: старый тулчейн из под линукса это раз, и как следствие невозможность делать pgo(чтобы запустить код) - это два

[Maratka]

Цитата: Сообщение от Vizvezdenec

Для меня все эти профилирования и флаги компиляции звучат как китайский

Ну... поверхностно освоить суть можно минуты за три. ;)

Скажем мы в цикле регулярно вызываем функцию, пока она не вернет значение более чем заданное, а т.к. заданное задано с хорошим запасом, то функция вызовется 5-10, а то и миллион раз. После чего мы к полученному результату функции добавляем пять, и вызываем вторую функцию, которой передаем параметр из первой. Это функция тоже вызывается много раз, в конечном итоге ее результат делиться на 12.

В результате, профилировщик (во всяком случае теоретически) должен оптимизировать две наши функции (на что у него есть свои механизмы, скажем в примере выше т.к. обычно выполняется условие "не более чем", то бинарный код будет оптимизирован на спекулятивное выполнение следующего цикла, а не кода за ним), а вот этот самый код, который за циклом - "+5" и "/12" - можно считать очень медленно, ибо это разовые действия, и на скорость выполнения программы в целом практического влияния не оказывают.

[Maratka]

Цитата: Сообщение от dew

Я, прошу прощения, но поповоду пропустить дисковые операции в стиле I/O wait и заняться чем-то полезным - мне на такое хочется сказать "фантастика - в другом зале!" Но, окей, может я и не прав.. наверное

Не готов спорить на счет кода SF, но вообще есть т.н. "асинхронное выполнение", когда недостающие данные обрабатываются потом, и на основе этого корректируется результат.

Цитата: Сообщение от dew

Есть мнение, что без PGO, но с максимальным уровнем статической оптимизации - бинарный код получается очень качественным.

Бенчи показывают обратное. ;)
Хотя... возможно со статикой оно и более стабильно, тут особой статистики не имею: да, мои сборки падали по весне, но... это 2-3 падения за 2-3 сотни партий, может и в сурсах был баг.

Цитата: Сообщение от dew

аброк сборки медленные по определению: старый тулчейн из под линукса это раз, и как следствие невозможность делать pgo(чтобы запустить код) - это два

Я не против идеальной сборки под Win64 popcnt. ;)
Есть возможность собрать - давайте!

[dew]

Цитата: Сообщение от Maratka

Не готов спорить на счет кода SF, но вообще есть т.н. "асинхронное выполнение", когда недостающие данные обрабатываются потом, и на основе этого корректируется результат

Если я правильно понимаю мысль, то такое "асинхронное выполнение" это задача архитектуры приложения, но не как не PGO.

Цитата: Сообщение от Maratka

Я не против идеальной сборки под Win64 popcnt. ;)
Есть возможность собрать - давайте!

Ну, видимо, я выше и собрал - это может каждый, для это нужно:
Windows(для pgo) и gcc(последних редакций)

gcc version 9.2.0 (Rev2, Built by MSYS2 project) <== меня этот пока не подводил

[dew]

Цитата: Сообщение от Alex_Zet

Тут что, кружок программирования?

Анноит?

[Alex_Zet]

Странно. Мои посты про добычу нефти и молока удалили а посты про код Стокфиша оставили, хотя и то и то откровенный офтоп и к ТСЕС отношения не имеют.

[svoitsl]

Ну так код Стокфиша крашанулся не где у Маратки на кухне, а именно на TCEC 16

[dew]

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

[sovaz1997]

Цитата: Сообщение от dew

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

Вообще, есть лекарство - бан дня на 3. Если не поможет, можно увеличить дозу.

[Vizvezdenec]

Когда Лила проиграла из-за поломанных семифигурок на 4с, тоже вполне себе там обсуждали. Краш одного из 2 фаворитов на финал это точно то, что стоит вообще обсуждать в текущей теме.

[ChessMan]

Цитата: Сообщение от dew

аброк сборки медленные по определению: старый тулчейн из под линукса это раз, и как следствие невозможность делать pgo(чтобы запустить код) - это два

На аброке уже давным-давно сборки с PGO. Благо Ubuntu 18.04 умеет делать кросс-компиляции с PGO. Правда, версия компилятора не самая новая - gcc/mingw 7.3