Что ж Вы раньше-то молчали
Дык сам не знал, вот решил проверить и оказалось что лучше именно так, сразу и сообщил.
Кстати, замер времени через gettime() оказался бракованным, она выдавала 3.3с (видимо столько работал именно PARI), а реально тратилось 12с (а это тратилось где-то вне PARI). Видимо надо переделать на getwalltime().
Dmitriy40, напишите, пожалуйста, инструкцию. Как заархивировать с почти 3-х Гб до одного. Как переслать через ф/о. И что делать получателю.
Взять любой архиватор, поддерживающий solid режим архивации (когда архивируются похожие файлы), например свободный
7-zip. Заархивировать (лучше каждую группу отдельно чтобы архивы получились поменьше, не все ф/о допускают гигабайтные файлы), причём лучше вместе с общей папкой в которой всё и лежит. Выложить в файлообменник. Переслать ссылку получателю. Там скачивают сразу на целевой комп и разархивируют (либо тем же архиватором, либо может даже сама винда сможет .zip открыть), получая сразу отдельную папку с готовыми к запуску программами. Запускают (тут снова много вариантов как это организовать). Сообщают Вам что насчиталось и/или передают любым способом логи.
Разумеется чтобы там было поменьше вопросов надо самому всё сначала проверить, можно на небольшом подмножестве всех паттернов (тупо оставить по паре в каждой группе).
Ф/о можно любой, хоть тот же dropmefiles.com, хоть гуглодиск, хоть яндексдиск, хоть мейлоблако, любой кто даст выложить нужный объём.
Гигабайт вроде даже и почтой можно переслать, не любой, но попробуйте.
О чём и речь. Доступ к Ахиллесу ведь не у меня, а у нашей общей знакомой. Если пойдёт навстречу и научится сама комплить, то дело пойдёт с головокружительной быстротой.
Последнее не обязательно, да и я бы на это не надеялся, а сделал полностью готовый комплект файлов в одном архиве с .cmd, чтобы только распаковать и запустить .cmd для компиляции и потом .gp для счёта и всё. Всю папку FASM вполне можно положить прямо вместе с исходником, возможно надо только переменные среды настроить чтобы он знал где искать свои .inc файлы. Это точно проще чем научить другого(-ю) компиляции.
К сожалению, регулярно происходит именно то, что описано в ссылке. Запустил на ночь несколько потоков. Все вылетели примерно через час.
Ну извините, гарантированного способа это исправить я не знаю, только исправление исходника PARI и перекомпиляция.
Я перед alarm() делаю один-два прохода по цепочке просто factor(n,max_p) с max_p=2^15 и 2^24 (второй так как он заметно медленнее первого и на этом тоже можно экономить), относительно много чисел имеют малые делители и не доходят до alarm(), соответственно и глюки возникают реже (на удивление у меня вот уже месяц их не было вообще). Вот кусок работающего кода (тут второй проход 2^25, я не упираюсь в конкретные значения, главное чтобы не меньше 2^24):
(Оффтоп)
Код:
n=p0+pm*vi[t];
if(n<h || n>=h+step, next); \\Исключение возможного дублирования цепочек на краях интервала step
if(!ispseudoprime((n+d1-1)/vv[g,d1]) || !ispseudoprime((n+d2-1)/vv[g,d2]) || !ispseudoprime((n+d3-1)/vv[g,d3]), next);
s=nd*zz[g,]; removeprimes(addprimes()); rr1=0; rr2=0; rr3=0; rr4=0; rr5=0; rr6=0;
a=nn\2+1; while((a--)>0,
if(s[a]==nd, next, s[a]>0, break); if(ispseudoprime((n+a-1)/vv[g,a]), s[a]=numdiv(n+a-1); break);
f=factor(n+a-1,2^15); fn=matsize(f)[1];
if(ispseudoprime(f[fn,1]), s[a]=numdiv(n+a-1); if(s[a]==nd, next, break));
if(prod(i=1,fn-1,f[i,2]+1)>nd/3, s[a]=1; break);
);
if(a>0, next);
b=nn\2; while((b++)<=nn,
if(s[b]==nd, next, s[b]>0, break); if(ispseudoprime((n+b-1)/vv[g,b]), s[b]=numdiv(n+b-1); break);
f=factor(n+b-1,2^15); fn=matsize(f)[1];
if(ispseudoprime(f[fn,1]), s[b]=numdiv(n+b-1); if(s[b]==nd, next, break));
if(prod(i=1,fn-1,f[i,2]+1)>nd/3, s[b]=1; break);
);
rr1=b-a-1;
if(rr1<nn, next);
if(rr1>=nn,
a=nn\2+1; while((a--)>0,
if(s[a]==nd, next, s[a]>0, break);
f=factor(n+a-1,2^25); fn=matsize(f)[1];
if(ispseudoprime(f[fn,1]), s[a]=numdiv(n+a-1); if(s[a]==nd, next, break));
if(prod(i=1,fn-1,f[i,2]+1)>nd/3, s[a]=1; break);
);
b=nn\2; while((b++)<=nn,
if(s[b]==nd, next, s[b]>0, break);
f=factor(n+b-1,2^25); fn=matsize(f)[1];
if(ispseudoprime(f[fn,1]), s[b]=numdiv(n+b-1); if(s[b]==nd, next, break));
if(prod(i=1,fn-1,f[i,2]+1)>nd/3, s[b]=1; break);
);
rr2=b-a-1;
\\ if(rr2<nn, next);
);
if(rr2>=nn,
a=nn\2+1; while((a--)>0,
if(s[a]==nd, next, s[a]>0, break);
if(type(alarm(1,factor((n+a-1)/vv[g,a])))!="t_ERROR", s[a]=numdiv(n+a-1); if(s[a]!=nd, break);
, f=factor(n+a-1,2^25); fn=matsize(f)[1];
if(ispseudoprime(f[fn,1]), s[d]=numdiv(n+a-1); if(s[a]==nd, next, break));
if(prod(i=1,fn-1,f[i,2]+1)>nd/4, s[a]=1; break);
);
);
b=nn\2; while((b++)<=nn,
if(s[b]==nd, next, s[b]>0, break);
if(type(alarm(1,factor((n+b-1)/vv[g,b])))!="t_ERROR", s[b]=numdiv(n+b-1); if(s[b]!=nd, break);
, f=factor(n+b-1,2^25); fn=matsize(f)[1];
if(ispseudoprime(f[fn,1]), s[b]=numdiv(n+b-1); if(s[b]==nd, next, break));
if(prod(i=1,fn-1,f[i,2]+1)>nd/4, s[b]=1; break);
);
);
rr3=b-a-1;
\\ if(rr3<nn, next);
);
if(rr3>=nn,
a=nn\2+1; while((a--)>0,
if(s[a]==nd, next, s[a]>0, break);
if(type(alarm(7,factor((n+a-1)/vv[g,a])))!="t_ERROR", s[a]=numdiv(n+a-1); if(s[a]!=nd, break);
, f=factor(n+a-1,2^25); fn=matsize(f)[1];
if(ispseudoprime(f[fn,1]), s[d]=numdiv(n+a-1); if(s[a]==nd, next, break));
if(prod(i=1,fn-1,f[i,2]+1)>nd/4, s[a]=1; break);
);
);
b=nn\2; while((b++)<=nn,
if(s[b]==nd, next, s[b]>0, break);
if(type(alarm(7,factor((n+b-1)/vv[g,b])))!="t_ERROR", s[b]=numdiv(n+b-1); if(s[b]!=nd, break);
, f=factor(n+b-1,2^25); fn=matsize(f)[1];
if(ispseudoprime(f[fn,1]), s[b]=numdiv(n+b-1); if(s[b]==nd, next, break));
if(prod(i=1,fn-1,f[i,2]+1)>nd/4, s[b]=1; break);
);
);
rr4=b-a-1;
\\ if(rr4<nn, next);
);
Где-то это в виде функций оформлял, где-то копипаста, не суть, главное идея что сначала прохожу factor (тут от центра к краям), потом, если цепочка не отброшена, уже alarm.
PPS: Я правильно полагаю, что последний factor можно опустить?
Да, он ничего полезного не делает (если вам нужно только количество делителей, а не полное разложение), numdiv и сама справится с разложением, раз уж оно завершилось успешно.
Кстати рекомендую alarm запускать минимум дважды (а лучше трижды): очень часто factor хватает и секунды найти один-два больших делителя и установить что делителей больше (или меньше) нужного. Потому я обычно делаю проверки по 1-7-60 секунд.
Кстати, удалось обойтись без ispseudoprime.
Я бы не убирал: возможна ситуация, когда первая factor вылетела по окончанию времени, но при этом нашла большой делитель
и не успела проверить остаток на простоту, а вторая factor использовала найденный делитель и быстро установила простоту остатка, т.е. разложение фактически завершилось, но выполнение пошло по ветке окончания времени. Маловероятно, но вдруг.
Плюс проверка matsize<4 конечно правильная, но она пропустит решение например с кубом большого простого вместо произведение двух. Это вообще нереально, но всё же. Я для себя отказался от таких простых проверок в пользу более универсальной, пусть и медленнее, она не столь часто выполняется и уж точно на порядки быстрее factor.
-- 28.07.2022, 15:04 --Кстати, я имел в виду более удобную засечку времени. Например, сколько времени тратится на группу(720 паттернов). Потому что время компиляции для отдельных паттернов сильно скачет: я видел значения от 62 до 140 миллисекунд(ms).
Проблема (моих исходников) в том что для них нигде нет разницы к какой группе принадлежит паттерн, они вообще не делятся по группам (в PARI программах), деление на группы есть только в .cmd, а там замерить время нереально. Хотел я сделать деление паттернов по группам в PARI (зачатки этого уже есть, для вывода инфы в заголовок окна), но потом плюнул, не так уж это надо.
Ну и скачки времени 60-140 мс вообще говоря ни о чём, там же минимум 20мс погрешность, плюс на таких масштабах это сильно зависит от внешних факторов (ОС, как быстро файл прочитается и запишется, не вмешаются ли другие процессы на пару квантов 20мс переключения задач, да ещё и частота процессора может скакать, и т.д.). Вообще любые измерения менее нескольких секунд следует считать не слишком адекватными, погрешность может достигать нескольких десятых секунды. Чтобы мерить время точнее надо существенно усложнять метод измерения, никакой реальной потребности в этом не вижу (когда важно сравнить именно чистые скорости выполнения, тогда и тесты пишутся специальные, с замером количества тактов процессора).
А, да, время компиляции легко определить по дате/времени готовых .exe, не между соседними, а между сотнями или группами.