Что дальше-то делать, если ещё одна непрерывная 14-ка найдётся существенно ниже...
Если Вы боретесь за каждый процент скорости, то проведите тест какой именно вариант разворачивания цикла будет быстрее именно на вашем компьютере. Я конечно уже просил Вас это сделать и даже были результаты, но их мало, да и не помню, включали ли те тесты проверку по индексам. Вполне вероятно что вариант с 4096 простыми и разворачиванием bb=[5,37] (для примера, точную информацию можно взять в конце .inc файла в строке "Decycle: 2 3 5 37 - repeats=1110") не оптимальный по скорости для вашего компа.
Конкретно, надо менять массив bb[] и параметр pr_max и смотреть какой вариант будет быстрее, либо на одном паттерне, либо, что лучше, на некотором подмножестве всех 46080 паттернов, лучше из всех групп, например по маске M12-??-??-?125??.exe, это 1/120 часть всех паттернов, 384шт, или тупо оставить в M12mods1.patterns по паре любых (лучше даже везде разных) паттернов от каждой группы. Разумеется всё это лучше делать в отдельной папке чтобы не испортить основной процесс.
Hints по заполнению массива bb[]:
1. Желательно заполнять не теми простыми, которые можно проверить по индексу (т.е. те что и так используются), проверка по индексу намного быстрее обычной, а разворачиваемые простые вообще не проверяются, они исключаются на этапе компиляции при разворачивании цикла.
2. Желательно чтобы коэффициент разворачивания (он показывается после запуска Yadryara5.gen.gp в Blocks=1110/104=10.673x) был побольше, чем он больше, тем по идее быстрее счёт. Для каждого простого его показ в файле Yadryara5.gen.gp закомментирован в 16-й строке (начинается с printf("%2d:", m);), но можно вычислить самому: для использованных простых
(кроме
) он равен
, для прочих равен
(11 - количество проверяемых мест). Для всех разворачиваемых простых коэффициенты перемножаются. Простые 2 и 3 разворачиваются всегда (потому что там всего один допустимый вариант в каждом), их в bb[] можно не указывать (но и указание ничему не помешает).
3. Желательно чтобы второе число в нём было больше сотни или двух, тоже чем больше, тем быстрее.
4. При этом надо смотреть за размером используемой памяти, она выводится сразу после Blocks, параметр size=1233.4K, лучше бы он не сильно превышал размер самого большого кэша в процессоре (если не ошибаюсь у Вас он 1М).
5. Либо, пусть превышает, но тогда надо развернуть ещё гораздо сильнее, чтобы выигрыш от разворачивания пересилил тормоза памяти.
Плюс можно играться pr_max для достижения баланса затрат времени между ускорителями и PARI — чем больше pr-max, тем выше коэффициент фильтрации и меньше работы остаётся PARI, но тем дольше работают ускорители и требуют больше памяти и для получения хорошей скорости придётся увеличивать коэффициент разворачивания (что ещё в разы повысит требования к памяти).
Величина pr_max напрямую влияет на время в PARI (через коэффициент фильтрации, сколько кандидатов выдадут ускорители), а массив bb[] на коэффициент фильтрации и время в PARI не влияет, зато влияет на время в ускорителях (и общее конечно).
Напомню, для Yadryara5.asm нельзя ставить pr_max>16384 (это мой давно исправленный глюк в x32 SSE версии), а для Yadryara6.asm нельзя pr_max>32768.
Ещё можно чуть поточнее ограничить диапазон для ускорителей, не +0.1%, а буквально до сотен, заодно и вообще убрать цикл по ii: фактически надо формулу для ii= перенести на место ii в коде дальше, а из формулы для конца из цикла вычесть формулу для ii= и поставить на место 227e6 в вызове ускорителя, примерно так (исходник взял не именно ваш, от своего последнего запуска счёта):
Код:
\\Было:
forstep(ii=floor(h/pp_mod),ceil((h+step-1)/pp_mod),227*10^6, \\ВАЖНО: чтобы не считать лишнего эта величина не должна сильно превышать ceil(step/440538835723387181869888800)!
printf("%s: %0.3fe35\t\t%c", ff[g],(p[g]+pp_mod*ii)/1e35,13);
vi=extern(strexpand("\"",pat[g],".exe\" ",ii," ",227*10^6)); q+=#vi;
\\Надо:
\\Убрать forstep(ii=floor(h/pp_mod),ceil((h+step-1)/pp_mod),227*10^6, \\ВАЖНО: чтобы не считать лишнего эта величина не должна сильно превышать ceil(step/440538835723387181869888800)!
printf("%s: %0.3fe35\t\t%c", ff[g],(p[g]+pp_mod*floor(h/pp_mod))/1e35,13);
vi=extern(strexpand("\"",pat[g],".exe\" ",floor(h/pp_mod)," ",ceil((h+step-1)/pp_mod)-floor(h/pp_mod)+1)); q+=#vi;
Плюс-минус единицы тут важны. Если pp_mod не была определена выше, то это просто pp_mod=pp.mod — мелкая оптимизация чтобы не лазить каждый раз в структуру, польза под вопросом.
Реальное ограничение будет не точно до единиц потому что ускоритель дополнительно сам расширит диапазон до границ разворачивания цикла (1110 для примера выше), правда реально считать будет лишь нижнее дополнение (без выдачи результатов, они выдаются строго лишь в запрошенном диапазоне), верхнее считаться не будет.
PS. В принципе это занятие на денёк, зато есть некоторая надежда что получится ускорить счёт на несколько процентов, может даже на десяток.