Пентадекатлон мечты

[Dmitriy40]

Yadryara в сообщении #1722198 писал(а):

Подчеркнул важные слова. Теперь-то понимаете, почему я в быстрых программах об этом писал, а не здесь?

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

Yadryara в сообщении #1722198 писал(а):

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

Выбор (серии) паттерна - это не ускорение работы программы. Потому это для этой темы, а не той.

wrest в сообщении #1722215 писал(а):

А почему мы не можем сконструировать стартовое число цепочки такое что последующие числа имеют нужное количество делителей?

Вообще говоря можем: расставить все простые в нужных степенях кроме одного последнего во все места, останется подобрать len простых чтобы выполнялись len линейных уравнений вида $a_i p_i + b_i = c_i$. Каждая буква - своя для каждого из len уравнений (правда $b_i=i$, но это частности), т.е. это вектора. Если бы можно было ставить любые натуральные числа, то решается методами линейной алгебры, но вот подобрать комбинацию именно всех простых чисел - непонятно как без перебора с проверкой на простоту, что собственно мы пока и делаем.

wrest в сообщении #1722238 писал(а):

Не такой уж большой рост,

Ну как небольшой, $\dfrac{1/\ln(10^{40})^{15}}{1/\ln(10^{49})^{15}}=\left(\dfrac{49}{40}\right)^{15}\approx21$ раз вообще-то. Вы наверное не учли степень, ведь растут все числа в цепочке, не одно какое-то.

wrest в сообщении #1722238 писал(а):

Я не понимаю что это значит, игнорирую.

Это серия паттернов, с 11 неизвестными простыми, с 4 неизвестными полупростыми (pq), и 6 простых в квадратах расставлено (6! вариантов расстановки). Т.е. это 6! очень похожих паттернов, отличаются только расстановкой 6 простых в квадрате (соответственно разные только n0, а m одинаковы).
11 простых - это плохо, в разложении простые встречаются раза в 3-4 реже чем полупростые.
Зато 11 простых - хорошо для моих ускорителей, они то как раз и пытаются подобрать все эти 11 простых (или почти простых), оставив проверку полупростых для PARI. А так как программа на асм с AVX2 работает намного быстрее PARI, то это выгодно, проверять медленным PARI лишь мало возможных кандидатов с 11 вероятно простыми. Если помню, скорость перебора кандидатов порядка 300-500млн/с/поток. И есть путь её повысить ещё раз в 5-7.

[Yadryara]

wrest в сообщении #1722238 писал(а):

Yadryara в сообщении #1722224 писал(а):

Там серия на 11 простых: 11-4-6!

Я не понимаю что это значит, игнорирую.

Видимо, всё-таки не прочитали первые страницы темы. Грубо говоря, это значит, что после расстановки чисел в паттерн, остаётся найти 11 простых и 4 полупростых числа.

-- 13.04.2026, 16:51 --

Dmitriy40 в сообщении #1722242 писал(а):

Выбор (серии) паттерна - это не ускорение работы программы.

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

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

[wrest]

Dmitriy40 в сообщении #1722242 писал(а):

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

Хм... а при этом мы хотя бы уверены, что решение (в простых) существует?

[Dmitriy40]

EUgeneUS
В принципе ускорители можно доработать чтобы они сами перебирали варианты расстановок простых в квадрате, ведь m при этом сохраняется (как и размеры прочих внутренних структур), меняется только n0, вычисляемое по КТО, которую я в общем умею считать на асме (с априорно известными модулями, иначе тоже умею, но медленно). Конечно это прилично работы (например придётся писать сортировку массивов в десятки тысяч элементов и видимо банальный пузырёк на таких размерах в пролёте). Но в любом случае проверка цепочки будет гораздо быстрее генерации паттерна (если не замедлять проверку ради простоты кода). Проверка занимает в среднем 7-10 тактов, за такое время сформировать все внутренние структуры нереально, разве что получить n0, но без предпросчитанных структур проверка цепочек будет на порядки медленнее.

wrest в сообщении #1722251 писал(а):

Хм... а при этом мы хотя бы уверены, что решение (в простых) существует?

Уверены. Правда обосновать у меня сходу не получается, надо VAL звать ...

[VAL]

wrest в сообщении #1722251 писал(а):

Хм... а при этом мы хотя бы уверены, что решение (в простых) существует?

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

[EUgeneUS]

Dmitriy40 в сообщении #1722252 писал(а):

В принципе ускорители можно доработать чтобы они сами перебирали варианты расстановок простых в квадрате, ведь m при этом сохраняется (как и размеры прочих внутренних структур), меняется только n0, вычисляемое по КТО, которую я в общем умею считать на асме (с априорно известными модулями, иначе тоже умею, но медленно). Конечно это прилично работы (например придётся писать сортировку массивов в десятки тысяч элементов и видимо банальный пузырёк на таких размерах в пролёте). Но в любом случае проверка цепочки будет гораздо быстрее генерации паттерна (если не замедлять проверку ради простоты кода). Проверка занимает в среднем 7-10 тактов, за такое время сформировать все внутренние структуры нереально, разве что получить n0, но без предпросчитанных структур проверка цепочек будет на порядки медленнее.

А во сколько раз подготовка медленнее проверки цепочек?
Если проверяем десятки тысяч кандидатов на паттерн, то это в 4 раза больше проверок, чем если бы проверять единицы кандидатов на паттерн.

Грубые оценки:
Пусть тогда нужно для нахождения цепочки $10^{18}$ проверок.
Темп проверки:

Dmitriy40 в сообщении #1722242 писал(а):

Если помню, скорость перебора кандидатов порядка 300-500млн/с/поток.

Берем 500млн/с/поток.
Тогда 63 года в один поток. Уже подъемно, если использовать мои мощности и мощности уважаемого VAL

А если:

Dmitriy40 в сообщении #1722242 писал(а):

И есть путь её повысить ещё раз в 5-7.

То можно и $D(36,15)$ попробовать найти.

[Dmitriy40]

EUgeneUS в сообщении #1722285 писал(а):

Берем 500млн/с/поток.

Я походу ошибся, это скорость перебора кандидатов для кортежей из простых чисел (типа симметричного 19-252), поиск же D(36,13) с 6-ю проверяемыми местами шёл со скоростью 75млн/с/поток (500с на 1e70 при m=7.74e61 и 288 паттернов) или 47 тактов на цепочку.
D(36,15) с 10-ю проверяемыми местами искались со скоростью 530млн/с/поток (440с на 1e85 при m=2.48e77 и 5760 паттернов) или 6.6 тактов на цепочку.
А D(12,15) с 11-ю проверяемыми местами искались со скоростью выходит 4.75млрд/с/поток (2200с на 1e35 при m=4.4e26 и 46080 паттернов) или 0.73 такта на цепочку.
Откуда такая разница не вполне понимаю, программы и паттерны довольно разные, вероятных причин вижу сразу несколько, но насколько они актуальны без проверки не сказать.
И возможно скорость можно ещё поднять: как недавно оказалось все программы делали вычислений в 6-11 раз больше необходимого, но как сильно ускорится без переписывания кода и тестов непонятно (раза 2-3 должны быть).

Про ускорение же в 5-7 раз выше - это из другой оперы, не уверен что оно применимо сюда. У меня просто все мысли про кортежи из простых, ну и путаюсь.

EUgeneUS в сообщении #1722285 писал(а):

А во сколько раз подготовка медленнее проверки цепочек?

Без понятия, ведь такой код ещё не написан, текущая программа оптимизировалась под поиск одного редкого паттерна (частые легко и на PARI найти) и потому часть подготовки вынесена во внешнюю программу на PARI, где формируются две таблицы остатков по всем проверяемым простым (до 2^15) для всех 6-11 проверяемых мест. В асм коде вычисляются ещё две таблицы (в сотни и тысячи раз больших) остатков по всем проверяемым простым (это делается на AVX без делений), плюс ещё таблица начальных остатков на начало проверяемого диапазона (тут уже с делениями). Замерил для D(36,13), оказалось вся подготовка в асм занимает порядка 4млн тактов или чуть больше 1мс. Если перенести и оставшуюся часть подготовки в асм, то думаю за 2мс не вылезет.
Но сравните, пусть 5млн тактов на подготовку и 50 (или 0.7) тактов на цепочку.

-- 14.04.2026, 17:09 --

EUgeneUS в сообщении #1722233 писал(а):

Для нахождения трех цепочек $D(12,15)$ было выполнено примерно $10^{17}$ проверок. По оценкам Дмитрия, насколько помню.

Нет, чуть меньше: 1e38/4.4e26*46080=1e16. Реальных проверок было в 6 раз меньше (все паттерны позволяют проверять с шагом 6m), но я предпочитаю считать с шагом m так как фильтрацию 6:1 можно считать "терапевтикой", т.е. проверкой по индексам, которая делается и для следующих простых кроме 2 и 3 и она как бы скрыта внутри ускорителей, это их внутреннее дело сколько они реальных проверок (и что вообще считать проверкой!) делают для указанного им диапазона коэффициентов при m=lcm(v).

[EUgeneUS]

Dmitriy40
Поднял свои прошлогодние записи по $D(36,14)$

1. Оптимальный паттерн.
1.1. минимальное количество простых - 9 штук, остальные - pq
1.2. при количестве простых в 9 штук минимальный LCM после расстановки квадратов необязательных простых
а) достигается при таких максимальных степенях простых: $2^8, 3^8$, остальные - квадраты.
б) и при подстановке 17 квадратов необязательных простых. При этом, в 5 позиций подставляется один квадрат, а в 6 позиций - два квадрата.
в) тогда $LCM \approx 3.328 \cdot 10^{69}$

Структура паттерна: 9-5-(17)

-- 14.04.2026, 20:07 --

2. Зависимость количества проверок, от количества проверок на паттерн.

Вот график:


Построен по 4-м точкам, но прекрасно аппроксимируется степенной функцией - формула для линии тренда есть на картинке.

По оси $Y$ - общее количество проверок до вероятности найти цепочку 0.95
По оси $X$ - количество проверок на один паттерн (после подстановки квадратов необязательных простых).

Итого.
1. Если делать 10 проверок на паттерн - нужно всего-то $4.2 \cdot 10^{16}$ проверок. Если их делать со скороcтью, как при нахождении $D(12,15)$, то найдётся довольно быстро. К сожалению, это невозможно - накладные расходы на подготовку паттерна все таки будут велики, они и сожрут время.
2. Если делать $10^4$ проверок на паттерн - нужно $7.6 \cdot 10^{16}$ проверок. Уже много, но и располагаемые мощности выросли
3. А если делать $10^6$ проверок на паттерн - нужно где-то $1.1 ... 1.3 \cdot 10^{17}$ проверок. Уже довольно много, но пока выглядит подъёмным на располагаемых мощностях. Если учитывать мои мощности и уважаемого VAL

У меня есть 56 потоков с AVX2 на 2500 МГц. У VAL - ещё больше

-- 14.04.2026, 20:17 --

Для $D(36,15)$ оптимальный паттерн расширяется добавлением одного простого и двух квадратов.

То есть структура: 10-5-(19)
При этом LCM возрастает в $89^2 \cdot 97^2$ раз.
А вероятность найти цепочку за одну проверку падает в 20-30 раз (можно более точно посчитать, но пока не вижу в этом смысла).

-- 14.04.2026, 20:34 --

Более читабельная картинка

[Dmitriy40]

EUgeneUS
Накидал код по открывшимся обстоятельствам.
Теоретическая оценка для D(36,14) с 9-ю проверяемыми местами и простыми по 83 даёт примерно 6-7 тактов на цепочку при проверке с простого 5 и далее.
Т.е. если можно идти с шагом 2m (это можно всегда), то будет 3-3.5 тактов на цепочку, если можно идти с шагом 6m, то будет 1 такт на цепочку.
Плюс если циклы немного развернуть, вероятно будет ещё чуть меньше. Этим и объясняется скорость 4.5млрд/с/поток (3.5ГГц) для D(12,15), там шаг был 6m.

Подготовка: при перерасстановке простых в квадратах надо поменять лишь n0 и вектор его остатков по модулю проверяемых простых (3500шт до 2^15 и 78500шт до 2^20). Похоже остаток от деления чисел до 10^76 на любое простое до 10^18 можно получить за 10 тактов, т.е. подготовка уложится в 35-40 тысяч тактов для фильтрации до 2^15 и в примерно миллион тактов для фильтрации до 2^20. Остальную подготовку можно делать один раз при запуске, не при смене паттерна. Фильтрация по простым c 5 до 2^15 даёт коэффициент 4830:1, до 2^20 примерно 64000:1, плюс 2:1 или 6:1 в зависимости от шага 2m или 6m.
При работе потребуется память под таблицу 3500*2*170=1.1МБ или (75000*4+3500*2)*170=50МБ. Но она рассчитывается один раз в начале и одинакова для всех потоков (и вся нужна очень редко, ровно с коэффициентом фильтрации). Остальные таблицы рассчитываются быстрее и занимают много меньше.
170 это долина развёрнутого цикла, чтобы размазать время 0.1-0.2 такта на проверяемое простое (т.е. 330 тактов до 2^15 или 14400 тактов для 2^20) не в каждой итерации, а сильно реже. По 170 итерациям оно размазывается как 330/170=1.94 такта на цепочку к 6-7 и 14400/170=85 тактов к 6-7. Мрак, надо или размазывать гораздо сильнее с увеличением памяти, или переделывать проверку простых выше 2^15 (или даже выше 2^12), что очевидно несколько замедлит (сейчас проверка по модулю 8 простых выше 2^15 занимает 3 такта, т.е. 0.4 такта на число). Замена на вычисление остатков за 10 тактов на простое число увеличивает время на цепочку с 6-7 тактов до 10 тактов (не считая эффекта от разворачивания цикла), ценой экономии памяти.

Соответственно жаль тратить основное время на подготовку, а значит перебор проверок каждого паттерна должен занимать сотню тысяч или миллионы итераций, меньше невыгодно.
Оценка теоретическая, код написан лишь внутреннего цикла проверки по простым, подготовка не писалась. Да и написанный код не тестировался, подсчёт чисто по справочным данным, реально может быть и раза в 1.5 медленнее.

EUgeneUS в сообщении #1722344 писал(а):

У меня есть 56 потоков с AVX2 на 2500 МГц. У VAL - ещё больше

А 56 потоков это ядер, без учёта гипертрейдинга? А то он не всегда даёт 100% прироста скорости, вон у Антона и Демиса даёт, а у меня лишь 50% прирост.
Ну а VAL по непонятной причине упорно отказывался от ускорителей.

[EUgeneUS]

wrest
Кстати, обратите внимание на колонку "P(1)" на картинках в моих постах выше. Это и есть вероятность найти цепочку за одну попытку. Рассчитанная в "калькуляторе шансов". Насколько понимаю, это именно то, что Вы хотели посчитать?

Dmitriy40

Dmitriy40 в сообщении #1722368 писал(а):

Фильтрация по простым c 5 до 2^15 даёт коэффициент 4830:1, до 2^20 примерно 64000:1, плюс 2:1 или 6:1 в зависимости от шага 2m или 6m.

Не знаю, сколько допустимых остатков по модулю 3 у этого паттерна, один или два.
Если допустимых остатков всё таки 2, а делать расчет с шагом 6m, то половину кандидатов будем пропускать.
Это приведет к тому, что величина чисел возрастет несколько больше, чем в два раза, вероятность упадет, а количество необходимых проверок возрастет. Рост количества проверок грубо можно оценить в 10-25%

Но в этом случае можно разделить по потокам - в одной пачке потоков считать с одним допустимым остатком по модулю 3 и с шагом 6m, а в другом - с другим остатком по модулю 3 и тоже с шагом 6m.

Dmitriy40 в сообщении #1722368 писал(а):

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

Тогда попадаем на количество проверок примерно $10^{17} \pm (10..15) \text{\%}$, плюс - для миллиона, минус для ста тысяч.
В текущей реальности, наверное, можно найти мощности для поиска за разумное время.
Но, конечно, надо будет посмотреть на фактическую скорость и оценить время.

Dmitriy40 в сообщении #1722368 писал(а):

А 56 потоков это ядер, без учёта гипертрейдинга?

К сожалению, именно потоков, ядер вполовину меньше.

Dmitriy40 в сообщении #1722368 писал(а):

а у меня лишь 50% прирост.

У меня примерно также. При запуске более 28 потоков скорость отдельного потока заметно падает
Но в целом рост производительности происходит. И ещё от 2 до 6 потоков оставлял для работы системы.

Кстати, заметил следующую неприятную штуку, которую хорошо видно при нагрузке примерно 75%.
100% нагрузка потоков как-бы перепрыгивает с одного потока на другой. А некоторые потоки загружаются, скажем на 85%. Такое впечатление, что система "размазывает" в среднем равномерно нагрузку по потокам. А это накладные расходы на переключения... Как это запретить - не разобрался

Dmitriy40 в сообщении #1722368 писал(а):

Ну а VAL по непонятной причине упорно отказывался от ускорителей.

Тут, конечно, надо его спросить - подключится ли к расчету $D(36,14)$ с ускорителями или нет?

Отмечу только, что в 2022 году было что посчитать и без ускорителей - цепочки с $k=24n, k<100$.
А сейчас, надеюсь, что цепочка на 192 делителя, которая в работе, найдется в обозримом будущем. А дальше считать в общем-то и нечего.

-- 15.04.2026, 06:24 --

Dmitriy40 в сообщении #1722368 писал(а):

Т.е. если можно идти с шагом 2m (это можно всегда), то будет 3-3.5 тактов на цепочку, если можно идти с шагом 6m, то будет 1 такт на цепочку.

А сколько тактов будет, если идти с шагом 30m?
Пусть по модулю 3 - два допустимых остатка, а по модулю 5 - 4 допустимых остатка.
Итого, по модулю 30 будет $1 \cdot 2 \cdot 4 = 8$ допустимых остатков. Так это можно "руками" по потокам развести при запуске. Нет?
Даже $7$ можно зацепить: $1 \cdot 2 \cdot 4 \cdot 6 = 48$ допустимых остатков по модулю 210 (и шаг, соответственно 210m).

-- 15.04.2026, 06:34 --

И даже для $11$:
$1 \cdot 2 \cdot 4 \cdot 6 \cdot 10 = 480$ допустимых остатков по модулю 2310 (и шаг, соответственно 2310m).
Тут, желательно уже иметь какую-то автоматизацию для учёта посчитанных допустимых остатков. Но можно и в эту сторону посмотреть, если увеличение шага даёт такое ускорение (уменьшение количества тактов на проверку).

-- 15.04.2026, 06:43 --

А ещё есть такой нюанс.

$17! \approx 3.5 \cdot 10^{14}$
Если делаем 100 000 проверок на каждую расстановку, это $\approx 3.5 \cdot 10^{19}$ возможных проверок.
Мы их всё равно никогда не сделаем. И это на 2.5 порядка больше, чем нужно.
Так что для шага $6m$ можно вообще не заморачиваться и считать с таким шагом. Но количество проверок на одну расстановку нужно будет снизить в два раза.
А вот для шагов $30m$ и больше - нужно уже учитывать остатки, которые будут посчитаны.

[Yadryara]

EUgeneUS в сообщении #1722374 писал(а):

Но в этом случае можно разделить по потокам - в одной пачке потоков считать с одним допустимым остатком по модулю 3 и с шагом 6m, а в другом - с другим остатком по модулю 3 и тоже с шагом 6m.

У нас это уже давно так и считалось:

Yadryara в сообщении #1720553 писал(а):

И уже ранее писал, что степень 3-ки в нужном месте именно 5-я, так как я делаю 6-кратный шаг, но в отдельных программах задаю остатки 243 и 486 по модулю 729. Но не 0.

Например, себе я обычно беру остаток 243, а Демис считает 486.

[VAL]

Dmitriy40 в сообщении #1722368 писал(а):

Ну а VAL по непонятной причине упорно отказывался от ускорителей.

Уточню, что последний раз это было 4 года назад.

Очередная парочка дроф заколдованной цепочки D(192,15):

591187217295495053623734583286580194820738834135136266651640
537155940622638451458020694801976733545369940550129429915640

[wrest]

EUgeneUS в сообщении #1722374 писал(а):

Это и есть вероятность найти цепочку за одну попытку. Рассчитанная в "калькуляторе шансов". Насколько понимаю, это именно то, что Вы хотели посчитать?

Да, но я хотел бы и "логику" - что и почему учитывается/не учитывается при подсчёте. $10^{-17}$ довольно высокая вероятность. Она же - не больше произведения вероятностей по каждому месту в цепочке?

[Dmitriy40]

EUgeneUS в сообщении #1722374 писал(а):

Но в этом случае можно разделить по потокам - в одной пачке потоков считать с одним допустимым остатком по модулю 3 и с шагом 6m, а в другом - с другим остатком по модулю 3 и тоже с шагом 6m.

EUgeneUS в сообщении #1722374 писал(а):

Пусть по модулю 3 - два допустимых остатка, а по модулю 5 - 4 допустимых остатка.
Итого, по модулю 30 будет $1 \cdot 2 \cdot 4 = 8$ допустимых остатков. Так это можно "руками" по потокам развести при запуске. Нет?
Даже $7$ можно зацепить: $1 \cdot 2 \cdot 4 \cdot 6 = 48$ допустимых остатков по модулю 210 (и шаг, соответственно 210m).

Этого не нужно, проще эти циклы развернуть в коде только по допустимым остаткам (это и так было сделано, это как раз те самые 170 развёрнутых итераций что я писал), тогда просто скорость в расчёте на m будет соответственно меньше (относительно шага 6m или 30m или 210m) и всё, руками делить по потокам излишне. Я вообще предпочитаю чтобы программа делилась по потокам внутри, чтобы запускать один exe и он занимал все потоки (сколько есть или сколько указано). Не всегда так получается, но к этому стремлюсь.

EUgeneUS в сообщении #1722374 писал(а):

Тогда попадаем на количество проверок примерно $10^{17} \pm (10..15) \text{\%}$, плюс - для миллиона, минус для ста тысяч.

Я бы сделал даже 10-100млн проверок, пусть будет 1.5e17, зато >90% времени будут именно проверки, а не накладные расходы. Тут должен быть оптимум, но надо точнее знать время подготовки и скорость итераций, а это надо иметь готовый полнофункциональный код, со всеми подготовительными расчётами и всеми стадиями проверок. Если заморочимся, то можно будет потестировать перед запуском глобального процесса.

Что-то странное, количество команд во внутреннем цикле сократилось раз в 10, а расчётная скорость заметно не выросла, нелогично ...

EUgeneUS в сообщении #1722374 писал(а):

К сожалению, именно потоков, ядер вполовину меньше.

Тогда расчётное количество эквивалентных потоков берём не 56, а 28*1.5=42. Но запускаем конечно 56.

Если при работе AVX кода частота не падает (у меня на сервере вот падает), то Ваша скорость эквивалентна моим 42*2.5ГГц/3.5ГГц=30 "образцовым" потокам (на рабочем компе 4 ядра без гипертрейдинга и падения частоты 3.5ГГц, на нём всё и пишу и тестирую). На сервере у меня 32 ядра и 64 потока, но частота при работе AVX падает с номинальных 2.5ГГц до 1.8ГГц и он получается весь эквивалентен моим 32*1.5*1.8/3.5=25 "образцовым" потокам, хотя реально лишь 22-23 (ну это ещё из-за однопоточного PARI, допроверяющего кандидатов).

EUgeneUS в сообщении #1722374 писал(а):

Такое впечатление, что система "размазывает" в среднем равномерно нагрузку по потокам. А это накладные расходы на переключения... Как это запретить - не разобрался

Разумеется размазывает. Причём если винда новая (новее 7 или 8, не помню), то ещё и в зависимости от прогрева конкретных ядер. Но время перескока на другое ядро - мизер по сравнению с временем тика. На Intel процессорах с inclusive кэшем (всё содержимое L1 и L2 есть и в L3) даже кэш перегружать по идее не надо, на AMD с exclusive кэшем (содержимого L1 и L2 может не быть в L3) достаточно записать L2+L1 в L3 и прочитать оттуда новое содержимое (уже в процессе работы), это грубо 600КБ туда и обратно, 1.2МБ на переключение задачи, при скорости L3 в 32Б/такт и 2.5ГГц скорость 80ГБ/с, т.е. смена L2+L1 занимает 1.2МБ/80ГБ/с=15мкс или менее 0.1% от 18мс тика переключения задач.

Запретить скакать по ядрам и потокам можно руками указав доступные потоки в диспетчере задач после запуска программы или параметром /affinity в команде start - запустить новое окно консоли cmd.exe с желаемым распределением по ядрам/потокам (start /affinity 0xFF001155 cmd.exe), можно сразу и /low указать, а потом уже в нём запускать программы счёта. В параметре битовая маска, обычно по паре бит на ядро с гипертрейдингом начиная с младших бит, явно это не знаю где документировано, надо копаться в вызовах WinAPI, проще определить на практике по загрузке в диспетчере задач, а какие потоки на одном ядре - по снижению скорости счёта. Это можно выяснить один раз и навсегда, по моему распределение потоков по битам маски никогда не меняется (если не меняется состав ядер).

-- 15.04.2026, 09:24 --

Dmitriy40 в сообщении #1722382 писал(а):

Что-то странное, количество команд во внутреннем цикле сократилось раз в 10, а расчётная скорость заметно не выросла, нелогично ...

А, дошло: за счёт отказа от вычисления остатка в той программе каждое простое дублировано 9 раз, зато в цикле проверки вместо 8 команд достаточно всего двух. Ну скорость соответственно не 3 такта, а 1 такт.
Плюс ещё и фильтрация по 11 местам для простых с 41 существенно сильнее чем по 9 местам для простых с 79, потому циклы обрываются быстрее.
Плюс в D(12,15) шаг был 6m, а в D(36,13) он оказался 2m и соответственно перебирает втрое больше кандидатов (и почему-то по модулю 3 цикл не развернулся, перебирал бы 2 из 3 и работал бы чуть быстрее, не в 1.5 раза конечно). Да ещё и проверка по индексу (более быстрая чем проверка по остаткам) непонятно почему не проверяет модули 3-37. В общем пример с D(36,13) неудачный (излишне медленный), хотя кортеж был найден помнится аномально быстро.
Зато при смене паттерна (расстановки простых в квадрате) придётся менять несколько десятков столбцов из 3500 в той большой таблице (3500*9*2*170 для 9 проверяемых мест). В принципе не долго ...

[Yadryara]

wrest в сообщении #1722381 писал(а):

Да, но я хотел бы и "логику"

Ура!

Будет вам логика. Причём без кавычек.

Кстати, вспомнил как называется этот коротенький поиск Дмитрия по интервалу, а не по паттернам. Брутфорс.

Ну так вот. У вас есть программа которая ищет D(48,21). Есть программа Владимира с первой страницы, которая ищет D(12,15).

Вы примерно понимаете как работает ваша. А понятно ли вам, что для того интервала, где ведётся поиск D(12,15), найти 11 простых и 4 полупростых гораздо вероятнее чем 12 простых и 3 полупростых?

И есть брутфорс Дмитрия для D(24*u,6), коротенькая прога. А понятно ли вам, что найти D(24,6) и уж тем более D(48,6), D(96,6) гораздо вероятнее именно по паттерну?

Видите, специально говорю "вероятнее", а не "быстрее". Хотя, разумеется одно из другого обычно следует.

Dmitriy40 в сообщении #1722368 писал(а):

Ну а VAL по непонятной причине упорно отказывался от ускорителей.

Кстати, совсем недавно это вспоминал. И не только Владимир, но и Хьюго.

Я вот не отказывался от ускорителей. И от замедлителей не всегда отказываюсь