Alexander wrote: После каждого взятия не судьба i-- сделать?

Вполне себе судьба, но обратите внимание на дополнительные накладные расходы связанные ос определением, что произошло именно взятие

Alexander wrote: В движке все это давно есть. Иначе он (движок) не смог бы оценить даже банальный выигрыш пешки

Vladimirovich wrote:
В расчете ОФ не обязательно явное знание N. Поэтому возможно потребуются некоторые дополнительные такты

Alexander wrote:
Сама ОФ занимает тысячи, если не более тактов.
Пару тактов на if любая прогга переживет
if (N<=6)
{
TB()
}
else
{
OФ()
}

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

Vladimirovich wrote:
пару тактов - это cmp для регистра, а если со смещением, то больше. Плюс еще jne отнюдь не пара Плюс еще надо поддерживать актуальным это самое N

PP wrote: Неправильно. Пример в Колизее.
Alexander wrote: Не надо крохоборствовать, ув. Alexander
Вы же уже знаете, что я прав

Это общие слова. Нужна практика (с)

Vladimirovich wrote: Что неправильно, где пример?

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

PP wrote:
Все по-моему совершенно правильно - в вариантах (особенно порождаемых ФВ) позы уже из 10-12 фигур будут иногда размениваться до налимовских, а это уже обращение не к оперативке и тем более не к процессорному кэшу

полагаю, что ОФ/ФВ тоже не может напичкать вспаханные варианты в оперативку и тем более не в процессорный кэш

Хайдук wrote:
Да вроде все в оперативке держится. По крайней мере, в параметр движка "Hashtable size" всегда меньше объема памяти

Alexander wrote: Да, но их зато уже считать не надо совсем далее
Положите фсе на SSD и enjoy
PP wrote: У Вас утро не задалось?
Введите там любую позицию до 6 фигур и получите абсолютно точную оценку

Vladimirovich wrote:
Можно еще в будущем будет на 3D XPoint
Но если посмотреть настройки реального движка, то видно, что далеко не все так просто:
http://kvetka.org/houdini_opt.shtml#syzygy_p wrote:

Alexander wrote: Это они что-то тупят... Один if, как описано выше, решает проблемы и с диском

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

Alexander wrote: Шахи и взятия любой уважающий себя программер движка должен отличать. Это форсаж, его надо первым считать.

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

Ruslan73 wrote:
Все это не означает, что никаких действий по фиксации не надо

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

Alexander wrote: Это imho все сущие копейки, добавить атрибут к ходу и во время определения хода, проверить, стояла ли там фигура.

Ruslan73 wrote: Такие. Сколько позиций комп рассматривает? Как только останется 7 фигур, так полетят обращения к таблицам.Ruslan73 wrote: Доли секунды это огромное время.

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

А вызов баз заканчивает всю итерацию ноды нахрен и приговор обжалованию не подлежит.

О чем речь вообще?
Ну поставьте позицию 6 фигурок на комп какую нибудь непростую и сравните, сколько времени уйдет с таблицами и без.

P.S. Тем более, зная тип позиции, загрузить в память нужный файл не составит труда при нонешних размерах памяти
Уж пятифигурки то вообще все влезут, падумаишь 6 гиг всего.

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

PP wrote: Это вообще ничто, 99% там будет потрачено на разовое первое чтение страниц с диска в кэш и все. Таблицы Налимова не меняются в процессе расчёта, значит в кэше могут висеть вечно.

Vladimirovich wrote: И 5 и 6 и 7 влезут, потому как в таблицах все мыслимые соотношения материала и расстановок. В партии такого разнообразия никогда не будет и потребуются считанные проценты от объема таблиц.

Vladimirovich wrote: Вы так и не поняли. Ставить надо например 10 фигурную и сравнивать скорость с таблицами или без.

Ruslan73 wrote: Вы размер таблиц представляете, куда Вы их целиком собираетесь засунуть? Поскольку различные 7 фигурки будут возникать при расчете издалека, неизбежно придется постоянно обращаться к диску, Вы очевидно как и Владимирович не понимаете о чем идет речь. Обращение к таблице, когда осталось только 7 фигур очевидно ускорит и улучшит игру, а вот обращение к таблицам при расчете вариантов издалека уже не обязано усиливать игру движка. Будет зависеть от многих параметров.