Vladimirovich wrote:
Но Вы же знаете, что механически не получится - нужно понимание

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

Зачем миллиарды - достаточно десятков тысяч

Десятки тысяч это 1 мегабайт информации из таблиц.

Залипание движка на чтение мегабайта на доли секунды может быть важно imho только если у вас партия по минуте без добавления и осталось по паре секунд времени.

Я понимаю что разработчики любят тестить движки в партиях по минуте, но при реальном использовании такой режим мало кому нужен.

Alexander wrote:
Механически нельзя даже водки выпить. Или можно, но без удовольствия

Но я примерно же расписал, как это должно быть
Нода-> Узел -> выбор - Базы или ОФ
И не нужно лохматить бабушку винт

Ruslan73 wrote:
Само собой, если играете в эдванс, то можно и день подождать
Но на самом деле я использовал шестифигурные таблицы, и просто знаю, что иногда сначала скорость сильно падает, а по мере анализа возвращается на приемлемый уровень. Это может длиться минуту например

Vladimirovich wrote:
Дело за малым - как выбирать будете?

Alexander wrote: Ну критерия тут два и оба известны - число фигур и материал (текущая ОФ)
Ферзе против коня далеко не надо рассчитывапть

Alexander wrote: Кэширование идет?

Vladimirovich wrote: Сами настаиваете ведь, что ОФ - вешь ненадежная

Alexander wrote: Я не очень понимаю зачем вообще нужна непроседающая скорость? Если движок залез в таблицы он потерял кучу поддеревьев, ему не нужно считать эти подузлы, которые уже в таблицах они в скорость не пойдут. В чем фетиш сохранения скорости, чтобы движок посчитал еще и бонусные деревья взамен отрезанных? Хотим не только в таблицы залезть но и еще насчитать столько уже узлов в секунду сколько нам отрезали, чтобы к таблицам доступ был незаметным?

Vladimirovich wrote: Вероятно, насчитываются при помощи баз некое критическое количество поз, а далее уже следуют повторы и работа из кэша

Ruslan73 wrote: Чтобы не просчитаться слишком рано до базы

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

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

Ruslan73 wrote: Более того, если на ЧМ по блицу чел вдруг заиграет по базе, то его надо забанить (в свете вышеизложенного) прежде всего за неправильные настройки движка

Ну это совершенно лишнее. Человек на ЧМ позицЫю Филидора в ладейнике или аналогичную вполне может просто знать и на рефлексах играть. Никакой набор битиков ему не ровня в таком случае.

Alexander wrote: По сравнению с движком играющим в классику (три минуты на ход) просчетов не будет.

И все же минутное залипание это imho очень странно. Многовато. Сколько ядер на машине было, что за винт? Таблицы Налимовские с внутреннего винта грузились?

Vladimirovich wrote: Строго наоборот. Вызов ОФ в тысячи раз быстрее вызова таблиц. Вызов таблиц позволяет Вам просто не строить никакого дерева там где не надо.

Alexander wrote: Вот вот. А теперь представим, что будет в семифигурных таблицах. Переходов будет уже сотни тысяч если не миллионы и работать надо будет с монстром в сотни террабайтов. Польза от таблиц ограничена сверху 20 пунктами эло, а значит сравнительно небольшая потеря быстродействия уже может навредить.

Ruslan73 wrote:
Это была база ладья с пешкой против ладьи с пешкой. Огромная, измерялась гигабайтами, это было года 3 назад с не очень быстрым интернетом и я был рад, что вообще ее скачал. Комп был 4-х ядерный, диск внутренний SATA.
Не знаю в чем там дело, но при старте движка в оболочке ChessBase диск начинал усиленно вращаться и сначала падала скорость. Потом через какое-то время ситуация улучшалась. Позиции я рассматривал 7 или 8 фигурные.

PP wrote:
У меня движок и на 6-фигурных таблицах уже подтормаживал. И судя по мануалам это общая проблема.
Кстати интересно, что это за 7-фигурные базы. Для начала надо вообще как-то разместить эти терабайты

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

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

PP wrote: Придется mapreduce - ом с ними работать если только дядя не подарит SSD drive на 300 Тб. Интересно, что практическая польза от всех этих таблиц весьма мала. Про шестифигурки пишут, что это примерно 20 пунктов эло. Основное применение это анализ окончаний, всякие сверхглубокие анализы итд. Интересно было бы сделать выборку из случайных табличных позиций и посчитать процент, когда действительно ОФ сильно врет. Думаю процент такой будет очень низкий, так как в большинстве позиций будет большой дисбаланс сил.

PP wrote: Мы же уже договорились, что это не так.
Ессно, имеется ввиду комплекс ОФ для всего дерева

PP wrote: Во-первых не в сотнИ а в 140. От одна сотня. И 40ТБ еще. Из этих 140 Тб оценки во время 1 партии нужны будут на мегабайты или даже килобайты. Работать придется с ними.

Во-вторых. НащОт миллионов- это не госдолг США и не варианты размещения выселяемых Трампом из Америки мексиканцев в соседней державке, ув.РР.

Никаких миллионов разных переходов в 7е фигурные не должно быть в шахматах в практической позиции. Невозможно из одной той же позиции 8ю фигуру съесть миллионом способов. Вы не найдете таких поз в реальных партиях. Взятие фигуры или пешки относительно редкая операция большинство ходов идут без всякого взятия. И чем меньше остается фигур тем больше пространства на доске для ходов и не факт что вероятность взятия растет. В большинстве случаев взятий будет небольшая доля от числа узлов в дереве. А из этих взятий, взятий именно 8й фигуры - еще меньше. Дай Бог там получатся десятки тысяч обращений к таблицам.

PP wrote: Вы как-то не очень наглядно нарисовали эти деревья...
На самом деле ветки за красными кружочками будут не чахлыми кустиками саксаула, а джунглями.
Даже для 5-фигурок.

И мы уже выяснили, что один красный кружочек быстрее, чем дерево за ним
Почему 10 красных кружочков будут медленнее, чем 10 деревьев?

При этом
quantoforum.ru/lab/523-shakhmaty-chelove...era?start=390#406114
И никто не мешает продолжать использовать ОФ, если число запросов к базе в очереди превышает некое число, скажем тысяч сто, что должно хватать
Да мы байт один по сути должны считать для каждой позиции нужной - 0 или или -500 или +500. Все!
(Понятно, что один, что сто разницы не будет особо, но все таки. Закэшировать можно очень много позиций)
Никто не завис, ничто не зависло

Alexander wrote: Raid 5 из 18ти 10-терабайтных дисков. В обычную персоналку не влезут конечно, надо корзины собирать плюс рейд контроллер.
Третий вариант по ссылке.
servergid.ru/produkciya/servery/diskovye-polki-jbod-das

Думаю порядка 15-20К долларов встанет скорей всего все это счастье в сумме.

Vladimirovich wrote: Только если Вы дошли до таблиц достаточно близко к корню! Если в самом корне, то просто шикарно, дерево уже просто отпадает. Проблема в том, что сперва по определению будут кустики, когда Вы на выходе из миттельшпиля будете досчитывать ветки то таблиц. И в этот момент от таблиц может быть вред если красный кружок занимает много времени, что собственно и происходит на практике уже в шестифигурках. В семифигурках это просто остановит движок скорее всего и этот самый probe depth придется выставить так, чтобы таблица вызывалась только если 7 фигур осталось в корне, а в этом случае и пользы от этих таблиц не так уж много будет.

Vladimirovich wrote: Мы выяснили, что один красный кружок на порядки медленнее одного серого кружочка, а время на ход ограниченно. Деревья более или менее имеют какую то глубину. Красные кружки поначалу возникают снизу и только время отнимают у движка, так как то дерево, которое вырастет потом под ними еще не выросло и никто огромный лес на данном ходе за ними выращивать не будет.

Vladimirovich wrote: Ну вот мы и пришли к консенсусу, то о чем мы с Александром и говорили с самого начала.