PP wrote: От миттельшпиля до таблиц как до Луны пешком. 7 фигур это с королями.
На выходе из миттельшпиля 16-18 фигур может быть легко на доске.

PP wrote: Ну посчитайте ладейник выше 5-фигурный? Дерево отпадает? Нет?
Если нет, все остальное Вами сказанное теряет смысл

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

Ruslan73 wrote: А как же SSD? Хотя один черт движок надорвется общаться с такими таблицами.

PP wrote:
Ну большие таблицы надо уже по сети нормальной. Пусть роутит на комп с нужной таблицей

Vladimirovich wrote: Я не игнорирую. Я не вижу как этот аргумент опровергает написанное мной выше. Давайте зафиксируем позицию.
Вы утверждаете, что использование таблиц в партии всегда увеличивает силу игры движка?

PP wrote: SSD будет дороже раз в 10,

Но это и не нужно RAID 5 заметно ускоряет чтение за счет размещения данных и паралелизации чтения. Скорость чтения на массиве из 10 дисков даже будет вполне сравнима с 1 SSD.

Никто из движков еще не надорвался ни разу. Случаев 0. Все живы здоровы.

Ruslan73 wrote: А вот шахматные программисты пишут, что движки досчитывают. Зависит конечно от позиции, глубины поиска итд. Например идет серия разменов и бац Вы обратились к таблицам в каких то ветках и тем самым замедлили расчет в куче других.

PP wrote: Досчитывают конечно но не от миттельшпиля.

PP wrote: С какой стати? У меня в телефоне даже 8 ядер. Каким образом 1 нитка, запросившая оценку в таблице остановила нитки на 7 других ядрах работающих?

PP wrote: Это поддавки скорее. Тоже разновидность шахмат. Там брать обязательно. Но там и таблицы не нужны вообще.

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

PP wrote: Что такое сила? Практический результат? Статистика?

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

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

И я исхожу из того, что один "красный" узел считается быстрее для обычных практически важных пятифигурок.
Поэтому, при прочих равных и 10 узлов будут считаться быстрее и т.д.
Согласно принципу мат. индукции

Технические сложности есть, но не стоит из-за них все переворачивать с ног на голову.

PP wrote: Я тоже этого не понимаю.
Ушел запрос в базу. Расчет ноды ушел в Idle. Времени не жрет. Все остальные работают.
Когда тред менеджера базы отработает, он вызовет коллбэк и узел получит точную оценку
Эта оценка может закончить расчет кучи параллельных нодов.
Как-то так

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

PP wrote: Не рассматривает. Нет таких процессоров в продаже пока чтобы рассматривали сотни миллионов. Есть единицы миллионов и пара десятков миллионов в секунду самые продвинутые. Причем я думаю он не рассматривает их всех всерьез а просто опознает как ходы непротиворечащие правилам из которых львиную долю мусора типа зевки ферзей в 1 ход быстро выкидывает.

PP wrote: В поддавках не нужны. Там цель игры противоположная.

Vladimirovich wrote: Но мы не обязаны все понимать. Есть эмпирические факты на шестифигурных таблицах.Vladimirovich wrote: А как насчет базы, которая получает кучу запросов и бегает по диску и ищет судорожно? Или грузит в память сотни гигабайтов тем самым отжирая память доступную для вычислений, да много чего может быть. Как только комп начнет заниматься I/O тут и конец наступит скорости поиска.

PP wrote: С такой что вероятность взятия 8й фигуры из всех возможных ходов в течении среднестатической партии крайне мала. Большинство партий заканчиваются наверняка вообще без этого взятия.

PP wrote: Поделите 2 сотни гигабайтов на размер одной оценки и посчитайте сколько оценок вы запросили. Чтобы комп их грузил в память нужна причина.

Ruslan73 wrote: Но и этого достаточно, чтобы нагрузить не одну нитку, так ведь? Сколько будет выполняться в среднем поиск в индексированном файле размеров в сотни терабайт?

PP wrote: О Майн Готт... Не надо судорожно.
PP wrote:
Комп не должен заниматься I/O напрямую. Должен быть специальный диспетчер, который принимает запросы.
Тред, сделавший запрос, уходит в Idle и процессор не грузит
Процессорное время отдается расчету другихнодов и узлов,
Если данный нод перволинейный, его можно приоритизировать в очереди запросов
А также можно оставить расчет этого же нода через ОФ в этом случае.

Никто не тормозит

Vladimirovich wrote: Эло рейтинг движка при игре с другими движками очевидно. Практический результат, я с самого начала об этом и писал.Vladimirovich wrote: С этим кто то тут спорит? Я даже приводил цифры, при правильном использовании 20 пунктов рейтинга прирост.Vladimirovich wrote: А есть уже даже и маты в 500 с чем то ходов, которые никакая ОФ никогда точно не оценит. Кто то утверждает, что ОФ точнее таблицы? ОФ в каком то проценте случаев будет давать неверную оценку.Vladimirovich wrote: Что конкретно Вам кажется было перевернуто?

PP wrote: Где Вы видели терабайты? Терабайты это у Ломоносова в облаке.
Вопрос уже в скорости сетки и производительности сервера. К нашей дискуссии это имеет такое же отношение, как Меркурий в седьмом доме

Vladimirovich wrote: Мы семифигурные таблицы и обсуждаем. Вы же не собираетесь на удаленный сервер Ломоносову запросы отправлять по ходу партии?

PP wrote: Вы упираетесь в некие технические сложности, вместо того, чтобы принять общую картину.
И делаете из них культ.
Технические сложности приходят и уходят, как показывает история. Их просто нужно решать
А Diamonds forever как пела Ширли Бэсси

PP wrote: Именно
Вы полагаете, их кто-то себе уже скачал?

Vladimirovich wrote: Русские хакеры? Мы как бэ и обсуждали, что польза в реальном времени от огромных таблиц не всегда очевидна. Речь шла о том, что тупое обращение к таблицам может даже ослабить практическую силу движка, в зависимости от размера таблиц и связанными с этим "техническими трудностями". Все. Ни я, ни Александр не писали, что таблицы не нужны или обязательно все портят. По какой то причине Вас потянуло спорить и доказывать некоторые очевидные вещи, которые тут никто не опровергал.

PP wrote: В рэйде из 10Тб дисков думаю порядка 50-100мс при этом все нормальные СУБД не читают по 20 байт с диска, а читают страницами или экстентами по 32-64К, т.е. с первой же оценкой прилетят в кэш и тысячи оценок соседних позиций.Если немножко повозиться с размером кэша наверняка можно тащить и десятки тысяч оценок. Скорость чтения из оперативной памяти на 4-5 порядков выше насколько помню.

PP wrote: Подтверждений чему мы нигде не увидели.

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