Но представьте себе, что например в 10-фигурном окончании диск слишком завертелся от "испробывания" баз и в результате движок точно посчитал шестифигурники, но не успел заметить удар на 10-м ходу в и восьмифигурнике
Да не будет там такого числа переходов в 6 фигурники чтобы это играло роль. Не бывает таких позиций из практической игры чтобы миллиарды разных переходов были и нужно было тащить десятки гигабайт оценок из таблиц. Это научная фантастика к шахматам не имеющая отношения.
Десятки тысяч это 1 мегабайт информации из таблиц.
Залипание движка на чтение мегабайта на доли секунды может быть важно imho только если у вас партия по минуте без добавления и осталось по паре секунд времени.
Я понимаю что разработчики любят тестить движки в партиях по минуте, но при реальном использовании такой режим мало кому нужен.
Десятки тысяч это 1 мегабайт информации из таблиц.
Залипание движка на чтение мегабайта на доли секунды важно только если у вас партия по минуте.
Само собой, если играете в эдванс, то можно и день подождать
Но на самом деле я использовал шестифигурные таблицы, и просто знаю, что иногда сначала скорость сильно падает, а по мере анализа возвращается на приемлемый уровень. Это может длиться минуту например
Но на самом деле я использовал шестифигурные таблицы, и просто знаю, что иногда сначала скорость сильно падает, а по мере анализа возвращается на приемлемый уровень.
Само собой, если играете в эдванс, то можно и день подождать
Но на самом деле я использовал шестифигурные таблицы, и просто знаю, что иногда сначала скорость сильно падает, а по мере анализа возвращается на приемлемый уровень. Это может длиться минуту например
Я не очень понимаю зачем вообще нужна непроседающая скорость? Если движок залез в таблицы он потерял кучу поддеревьев, ему не нужно считать эти подузлы, которые уже в таблицах они в скорость не пойдут. В чем фетиш сохранения скорости, чтобы движок посчитал еще и бонусные деревья взамен отрезанных? Хотим не только в таблицы залезть но и еще насчитать столько уже узлов в секунду сколько нам отрезали, чтобы к таблицам доступ был незаметным?
Но на самом деле я использовал шестифигурные таблицы, и просто знаю, что иногда сначала скорость сильно падает, а по мере анализа возвращается на приемлемый уровень.
Кэширование идет?
Вероятно, насчитываются при помощи баз некое критическое количество поз, а далее уже следуют повторы и работа из кэша
В чем фетиш сохранения скорости, чтобы движок посчитал еще и бонусные деревья взамен отрезанных? Хотим не только в таблицы залезть но и еще насчитать столько уже узлов в секунду сколько нам отрезали, чтобы к таблицам доступ был незаметным?
Я смотрю обычно классику с движком в онлайне или анализ партии из книжки или своей когда уже прошелся сам по партии белковым движком своим. Мне несколько секунд не играют роли никакой. А точность важна.
Я согласен при онлайнах чемпионата мира по блицу можно таблицы совсем отключать, там каждая секунда на счету и только грубые зевки от проги интересны.
Я согласен при онлайнах чемпионата мира по блицу можно таблицы можно совсем отключать, там каждая секунда на счету и только грубые зевки от проги интересны.
Более того, если на ЧМ по блицу чел вдруг заиграет по базе, то его надо забанить (в свете вышеизложенного) прежде всего за неправильные настройки движка
Ну это совершенно лишнее. Человек на ЧМ позицЫю Филидора в ладейнике или аналогичную вполне может просто знать и на рефлексах играть. Никакой набор битиков ему не ровня в таком случае.
По сравнению с движком играющим в классику (три минуты на ход) просчетов не будет.
И все же минутное залипание это imho очень странно. Многовато. Сколько ядер на машине было, что за винт? Таблицы Налимовские с внутреннего винта грузились?
Вот вот. А теперь представим, что будет в семифигурных таблицах. Переходов будет уже сотни тысяч если не миллионы и работать надо будет с монстром в сотни террабайтов. Польза от таблиц ограничена сверху 20 пунктами эло, а значит сравнительно небольшая потеря быстродействия уже может навредить.
И все же минутное залипание это imho очень странно. Многовато. Сколько ядер на машине было, что за винт? Таблицы Налимовские с внутреннего винта грузились?
Это была база ладья с пешкой против ладьи с пешкой. Огромная, измерялась гигабайтами, это было года 3 назад с не очень быстрым интернетом и я был рад, что вообще ее скачал. Комп был 4-х ядерный, диск внутренний SATA.
Не знаю в чем там дело, но при старте движка в оболочке ChessBase диск начинал усиленно вращаться и сначала падала скорость. Потом через какое-то время ситуация улучшалась. Позиции я рассматривал 7 или 8 фигурные.
Вот вот. А теперь представим, что будет в семифигурных таблицах. Переходов будет уже сотни тысяч если не миллионы и работать надо будет с монстром в сотни террабайтов. Польза от таблиц ограничена сверху 20 пунктами эло, а значит сравнительно небольшая потеря быстродействия уже может навредить.
У меня движок и на 6-фигурных таблицах уже подтормаживал. И судя по мануалам это общая проблема.
Кстати интересно, что это за 7-фигурные базы. Для начала надо вообще как-то разместить эти терабайты
Попробую визуализировать свою мысль. Предположим для простоты, что движок отводит себе фиксированное время на ход. В варианте слева он использует таблицы, но поскольку дошел до таблиц на глубине, а не в самом начале то отрезал очень мало ответвлений, но пришлось потратить уйму времени на загрузку этих чертовых таблиц.
За это же время движок без таблиц сумел просчитать на большую глубину несмотря на то, что пришлось смотреть лишние синие позиции. В результате если оценка позиции синих позиций не критична, то движок просто глубже смог просчитать позицию. Вот для того, чтобы этого не происходило и придумали параметер probe depth.
В семифигурных цена вызова таблиц только повысится, а значит этот параметер будет просто критичным иначе просто тупо движок на очень низкой глубине расчета зависнет как только в достаточном количестве мест возникнут красные кружочки. С другой стороны если красный кружочек возникает сразу (мы уже в эндшпиле), то тогда очевидно от таблиц только польза ибо отсекут кучу ненужных вычислений.
Кстати интересно, что это за 7-фигурные базы. Для начала надо вообще как-то разместить эти терабайты
Придется mapreduce - ом с ними работать если только дядя не подарит SSD drive на 300 Тб. Интересно, что практическая польза от всех этих таблиц весьма мала. Про шестифигурки пишут, что это примерно 20 пунктов эло. Основное применение это анализ окончаний, всякие сверхглубокие анализы итд. Интересно было бы сделать выборку из случайных табличных позиций и посчитать процент, когда действительно ОФ сильно врет. Думаю процент такой будет очень низкий, так как в большинстве позиций будет большой дисбаланс сил.
Переходов будет уже сотни тысяч если не миллионы и работать надо будет с монстром в сотни террабайтов.
Во-первых не в сотнИ а в 140. От одна сотня. И 40ТБ еще. Из этих 140 Тб оценки во время 1 партии нужны будут на мегабайты или даже килобайты. Работать придется с ними.
Во-вторых. НащОт миллионов- это не госдолг США и не варианты размещения выселяемых Трампом из Америки мексиканцев в соседней державке, ув.РР.
Никаких миллионов разных переходов в 7е фигурные не должно быть в шахматах в практической позиции. Невозможно из одной той же позиции 8ю фигуру съесть миллионом способов. Вы не найдете таких поз в реальных партиях. Взятие фигуры или пешки относительно редкая операция большинство ходов идут без всякого взятия. И чем меньше остается фигур тем больше пространства на доске для ходов и не факт что вероятность взятия растет. В большинстве случаев взятий будет небольшая доля от числа узлов в дереве. А из этих взятий, взятий именно 8й фигуры - еще меньше. Дай Бог там получатся десятки тысяч обращений к таблицам.
В семифигурных цена вызова таблиц только повысится, а значит этот параметер будет просто критичным иначе просто тупо движок на очень низкой глубине расчета зависнет как только в достаточном количестве мест возникнут красные кружочки.
Вы как-то не очень наглядно нарисовали эти деревья...
На самом деле ветки за красными кружочками будут не чахлыми кустиками саксаула, а джунглями.
Даже для 5-фигурок.
И мы уже выяснили, что один красный кружочек быстрее, чем дерево за ним Почему 10 красных кружочков будут медленнее, чем 10 деревьев?
Красные узлы закончат не только эту линию, но и множество других, если там выиграно, или ничья при прочих плохих
И никто не мешает продолжать использовать ОФ, если число запросов к базе в очереди превышает некое число, скажем тысяч сто, что должно хватать
Да мы байт один по сути должны считать для каждой позиции нужной - 0 или или -500 или +500. Все!
(Понятно, что один, что сто разницы не будет особо, но все таки. Закэшировать можно очень много позиций)
Никто не завис, ничто не зависло
На самом деле ветки за красными кружочками будут не чахлыми кустиками саксаула, а джунглями.
Даже для 5-фигурок.
Только если Вы дошли до таблиц достаточно близко к корню! Если в самом корне, то просто шикарно, дерево уже просто отпадает. Проблема в том, что сперва по определению будут кустики, когда Вы на выходе из миттельшпиля будете досчитывать ветки то таблиц. И в этот момент от таблиц может быть вред если красный кружок занимает много времени, что собственно и происходит на практике уже в шестифигурках. В семифигурках это просто остановит движок скорее всего и этот самый probe depth придется выставить так, чтобы таблица вызывалась только если 7 фигур осталось в корне, а в этом случае и пользы от этих таблиц не так уж много будет.
И мы уже выяснили, что один красный кружочек быстрее, чем дерево за ним
Почему 10 красных кружочков будут медленнее, чем 10 деревьев?
Мы выяснили, что один красный кружок на порядки медленнее одного серого кружочка, а время на ход ограниченно. Деревья более или менее имеют какую то глубину. Красные кружки поначалу возникают снизу и только время отнимают у движка, так как то дерево, которое вырастет потом под ними еще не выросло и никто огромный лес на данном ходе за ними выращивать не будет.