7 фигурные можно самим насчитать, места надо только много.

надеемся, что в результате обсуждения сферху презрение РР к рядовым макакам программерам поубавилось

Vladimirovich wrote: А обрезать цитаты, чтобы исказить их смысл совсем некрасиво. Вот как выглядит оригинал, где я пытаюсь объяснить, что не Вы не Руслан не поняли того случая о котором пишу я.PP wrote: Хайдук wrote: Дискуссия сверху показала мне только что тут у нас есть люди, которые судят о квалификации оппонентов и хамят, когда сами либо никогда не писали high performance code или делали это так давно, что уже просто не могут точно оценить стоимость операций.

Vladimirovich wrote: Ответ зависит от длины цикла, размера файла скорости диска и состояния его кеша. Цикл в привeденном Вами кодe кажется просто идет по фигурам, даже если он двойной его выполнение займет микросекунды. Получить оценку в индексированном файле размера 100 ТБ займет в лучшем случае десятки миллисекунд (если SSD, но очевидно такого огромного драйва нет), а скорее всего значительно больше. Если файл закеширован то конечно поиск будет значительно более быстрым, но на кеширование может уйти уйма памяти ибо в разных ветках могут возникать сильно отличные друг от друга окончания. В любом случае если мы не можем оценить позицию с помощью таблиц близко к корню, то мы имеем дело с trade - off скорости на точность. О чем я изначально и написал, что практическая польза начнет зависеть от технических деталей.Ruslan73 wrote: Я не знаю когда Вы последний раз писали код, но 30М зачитываются сильно быстрее чем за секунды, на несколько порядков быстрее.

Посмотрел что пишут люди, которые занимаются этим вопросом
С форума девелоперов воблы
support.stockfishchess.org/discussions/p...-probe-depth-scalingЧто нам пишут в руководстве пользователя Гудини
www.cruxis.com/chess/manual/index.html?g...game_table_bases.htmНастройки Комодои это все о шестифигурках, а не монстрических семифигурках!

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

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

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

Для больших же объемов действительно могут быть некие проблемы с диском, но, как справедливо сказано выше для Syzygy
Если мы обратимся к тексту выше
То это верно. Незачем рассчитывать такой эндшпиль далее обычно окромя расчета вилки на ближайшем ходу
И не нужно лезть в таблицы. Разумеется, такие экзотические случаи мы можем отключить.

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

Для Комодо выше я вообще не понял, зачем Вы привели это как аргумент
Syzygy Probe Limit по умолчанию на 6, что верно. Ни у кого нет 7-фигурок локально наверно еще
ПоэтомуЧто полностью согласуется с моей трактовкой
PP wrote: Т.е 2 полухода по умолчанию.
Ну это опять же все в мэйнстриме. 99 практически отключит таблицы.А по умолчанию - всего 2 И у всех все работает.

Также я думаю, что грамотный движок, как только нода прибегает к красненькому узлу,
должен запрашивать базы в отдельном треде через некую очередь, чтобы не тормозить основной расчет и не долбить беспорядочно диск запросами.
При превышении вдруг некоего размера очереди использовать ОФ, пока текущие запросы не будут обслужены, но это полагаю экзотические довольно ситуации, о которых уже говорил Руслан.
Если этого не сделано, то да, мы можем ожидать проблем с диском.
Но это все технические недоработки, которые могут быть вполне устранены.

PP wrote: Последний раз я писал код месяц назад, мне за него сказали огромное спасибо, он очень помог. Теперь Вы знаете.

Я думаю что Вы вообще очень мало что знаете в области ИТ. Иначе Вы бы не упоминали бы про код, когда здесь все упирается в особенности железа. 140TB держать на SSD дисках дороговато, обычные диски порядка 50-150МБ/с имеют скорость последовательного чтения в зависимости от года и модели производства (числа оборотов в том числе). Соответственно 50М а может и побольше (не 30М РР читайте внимательно, данные об оценках нужные вам не лежат впритык рядышком в базе, они скорее всего на некотором расстоянии разбросаны). Так вот эти 50-150МБ/с последовательного чтения гигабайтного файла в синтетических тестах как раз превратятся в секунды при чтении реальных 50МБ+ с диска вместе с открытием подключения в софте, выделения памяти и прочего. Их немного, этих секунд будет, но это будут точно не "несколько порядков быстрее". Не сотые и не миллисекунды.

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

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

Хотя меня лично устроит любой вариант, последуете Вы этому совету или нет.

PP wrote: Может быть проблема отчасти и в этом. Слишком много внимания kn/s. Еще со времен рыбки было известно kn/s не единственный показатель. Там насколько понимаю постоянный компромисс между качеством оценки и kn/s.

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

Vladimirovich wrote: Еще раз повторюсь, Вы не поняли мысль, которую я и Александр пытаемся донести. Мы не пишем, что таблицы всегда замедляют расчет. Мы написали, и это подтверждается настройками движков на шестифигурки (семифигурки были бы на порядки больше), что обращаться к таблицам выгодно если это можно сделать в начале расчета, и может ухудшить практическую силу из за падения скорости если это делать ближе к концу расчета. Ваша картинка это никак это не опровергает.Vladimirovich wrote: Погуглите. Probe Limit не относится к размеру таблиц, а регулирует глубину расчета на которой к ним оптимально обращаться. Тоесть уже у шестифигурок без SSD рекоммендуют быть осторожней. Для семифигурок, постоянное обращение к таблицам просто тупо затормозит движок плюс у Вас и нет такого огромного SSD. А какой навар ЭЛО при оптимальной работе таблиц? Спецы пишут что шестифигурки дают +20, а от семифигурок ожидают +40. Иными словами падение скорости может легко этот навар перекрыть если обращаться к таблицам всегда.

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

PP wrote: Я Вам объяснил, что это чисто технический момент и как с этим бороться в движке
Но если движок кривой, тогда это не мои проблемы
В общем случае см. мою картинку
PP wrote: Ни то ни другоеЯ так и писал. Перечитайте

Итог
Пока фигур больше Syzygy Probe Limit = 6 (7) движок юзает ОФ. Никаких проблем оттого, что начало расчета или конец, нет
Мы говорим о конкретном узле всегда.
Как только Limit см. картинку

PP wrote: Тем что придрались только к секундам и не по делу. Очевидно по делу придраться не к чему.

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

Vladimirovich wrote: Пардон в Комодо этот параметр называется probing depth scale.

Ruslan73 wrote: По делу придраться можно будет, когда Вы обоснуете 30МБ, откуда Вы Ее взяли. Почему создатели движков уже на шестифигурках придумывают всякие probing depth?

PP wrote: Ну значит не судьба. Когда раздобудете браузер с функцией просмотра предыдущих страниц, тогда и продолжим.

Ruslan73 wrote: Это тех, где Вы уложили семифигурные базы в 50Гб вместо сотен Тб? Я бы предпочел, чтобы Вы дали оценку числа различных семифигурных окончаний, до которых движок доходит на глубине скажем в 10 полуходов и средний размер одного такого класса окончаний которые придется загрузить в кеш. Я предполагаю, что придется грузить на два порядка большее число данных чем в шестифигурных (где это уже проблема иначе не было бы параметра probing depth) и достигать эти позиции движки будут раньше. На сегодняшнем железе работать движок не сможет, он погрязнет в медленных I/O операциях. А поскольку общее усиление игры от таблиц весьма незначительно, то я вижу основания для сомнений о пользе их использования за исключением сравнительно низкой глубины.

Давайте зафиксируем промежуточный итог
1. Ув.РР признает, что однократный запрос к базе в табличной позиции (красненькой) быстрее ее расчета
2. Ув.РР НЕ признает, что многократные запросы к базам в N узлах для табличных позиций быстрее расчета N этих позиций (красненьких)
И даже говорит, что напротив, медленнее
3. Мне это странно
4. Для ув.РР это априори НЕ странно
quantoforum.ru/lab/523-shakhmaty-chelove...era?start=270#405810
Правильно изложил?

Vladimirovich wrote: Но когда фигур становится 6, движок смотрит на параметер probe depth и решает есть ли смысл лезть в таблицы. Если движок вылез на табличную позицию в конце расчета, то обращение к таблице уже может навредить. В гипотетическом варианте семифигурок, просто убьет перформанс. Очевидно, что само наличие таких параметров в большинстве движков указывает на проблему.

Vladimirovich wrote: 1. Yes
2. Not exactly. Обращение к таблице, на высокой глубине расчета может сильно тормозить движок и ослабить практихескую силу игры.

PP wrote: Это не я уложил это продавцы. Таков размер дистрибутива. Я не торгую базами Налимова.

Один из признаков разумного человека- способность признавать ошибки, да я ошибся признаю. Посмотрел на число DVD но забыл про упаковку. Вы с секундами не признали свой косяк. Это все вам в минус а не мне.

Однако размер БД играет в основном значение для вопроса где разместить. Скорость и объем памяти зависят от объема требуемых для работы данных, объем базы рояли не играет практически.
PP wrote: Без нового браузера вы не справитесь а мне лень повторяться.

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

PP wrote: Очевидно, что все эти параметры суть обычная конфигурируемость, которая может быть использована для различных экзерсисов любителей и энтузиастов
PP wrote: Я не понимаю данной логики.
Что значит "в конце расчета" ? Кто знает, где у движка "конец" ?

Движок строит граф беспрерывно, постоянно увеличивая глубину полуходов. Нес па?
По достижению "красного" узла движок должен послать запрос в базу. АСИНХРОННЫЙ!! Не тормозящий.
Как мы уже знаем, для данного узла он получит результат быстрее, чем его рассчитывая.PP wrote:
Если полученный граф в данный момент времени будет иметь N красных узлов, то за счет чего мы получим обратный результат?
ПОЧЕМУ N запросов в базу вдруг станут медленнее, чем N расчетов?PP wrote: С логической точки зрения это абсурд. Нес па?

Объяснение может быть только одно... Много запросов к винту может быть неким аналогом DDOS атаки на сервак
Что может случиться есть 8 ядер в 128 тредах беспрерывно энтот винт долбят.
Но, как я уже сказал, это проблема уже совсем другого уровня - квалификации разработчиков и железная притом.
Это просто нужно грамотно упорядочить.

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

НО
Учтите...
1. Таблицы хранят слишком много информации для оценки движка
Реально нужна только сама оценка,это одно число для одной позиции, а там лежат ВСЕ ходы с глубиной мата
Т.е смысл имеет не более 10% от объема таблиц.

2. Для конкретной 8-фигурки количество нужных 7-фигурок позиций будет штук эдак несколько, а вовсе не всеь объем терабайтный
К этому можно заранее подготовиться, загрузив нужны 100 метров.

3. Получение точной оценки отрубает расчет множества параллельных линий

И какие возражения мы имеем на Вашей стороне?
PP wrote: PP wrote:
Это все теоретические рассуждения?
Ничего не забыл?

PP wrote: Не, я вообще не знаю, что такое "кусочнотраспаковывать" в наших ВУЗах такое не преподают и курсов повышения квалификации по этой теме нет. Что я предложил и откуда берутся 20-30М расписано в постах на этой и предыдущей странице. Но вам несовершенство браузера очевидно мешает это узнать. Без услуг ИТ-шной макаки к сожалению учОному тут не обойтись.

Vladimirovich wrote: Очевидно потому, что длина ФВ ограничена, и точно в пресловутом конце N запросов будут на 3 порядка медленнее

Alexander wrote: Что такое ФВ в данном контексте?
Alexander wrote:
Если при N=1 все быстрее, при каком N это тормозит и за счет чего?

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

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

Alexander wrote: Ну так никто не мешает НЕ использовать базы в этом случае

И я об этом и похожих вещах уже говорил

quantoforum.ru/lab/523-shakhmaty-chelove...era?start=360#406053
Vladimirovich wrote:
Опять же, не нужно использовать частные случаи для понимания ощей картины

Vladimirovich wrote: Допустим ОФ выдает результат за 1 еденицу времени, а ТБ за 1024. Рассмотрим простой случай бинарного сада расходящихся тропок где счет обрывается на глубине 10. Вызов таблицы будет мне экономить время только если я смог заглянуть в нее уже на первом уровне. Теперь смотрим, что получится если только на глубине 10 я добрался до таблиц. В этом случае я получу замедление на три порядка, которое только с небольшой вероятностью усиливает игру (эмпирический факт).