кортежи последовательных простых. ключ к 19-252

[Dmitriy40]

60% идеала тоже неплохо. Значит или под виндой это плохо работает, или лично у меня.

[maxal]

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

60% идеала тоже неплохо. Значит или под виндой это плохо работает, или лично у меня.

Насколько я понял из прочтения этого треда, проблема именно в mingw-версии PARI/GP.

[Dmitriy40]

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

        GP/PARI CALCULATOR Version 2.13.4 (released)
amd64 running mingw (x86-64/GMP-6.1.2 kernel) 64-bit version
 compiled: Mar 25 2022, gcc version 8.3-posix 20190406 (GCC)
                  threading engine: pthread
parisize = 8000000, primelimit = 51000000, nbthreads = 4
? func2(a,b)=  abs(  prodeuler(X=2,10000,1/( 1-1/X^(1+(a+b)*2*Pi*I/log(2))))  );
? export(func2);
? parfor (count=1, , func2(1e35,count)>5 , r, if (r, return (count)))
cpu time = 31,153 ms, real time = 8,052 ms.

-- 25.08.2025, 22:07 --

Хотя однопоточный gp64 всё равно лучше, за 15с.

[wrest]

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

Вы видите ускорение счёта в 4 раза? Я вот вижу замедление раз так в 5-6! При почти полной загрузке всех ядер и не пойми зафига вызываемым арбитраже (через ядро).

У меня в WSL2 (Ubuntu 24.04.2 LTS, pari/gp 2.17.2, threading engine: pthread, nbthreads = 8) ваш код с заменой for на parfor замедляется ещё больше, при этом все 8 потоков загружены.

? stop=precprime(10^7);export(stop);t0=getwalltime();for(a=1,stop-1,my(x);x=lift(chinese(Mod(1,9699690),Mod(1,stop)));if(ispseudoprime(x),print(x)););print("Time: ",strtime(getwalltime()-t0));
Time: 9,384 ms
cpu time = 9,384 ms, real time = 9,384 ms.
? stop=precprime(10^7);export(stop);t0=getwalltime();parfor(a=1,stop-1,my(x);x=lift(chinese(Mod(1,9699690),Mod(1,stop)))
;if(ispseudoprime(x),print(x)););print("Time: ",strtime(getwalltime()-t0));
Time: 5min, 57,571 ms
cpu time = 2min, 47,693 ms, real time = 5min, 57,573 ms.
?

9 секунд for против 360 секунд. Почти в 40 раз

[maxal]

wrest, используйте сбалансированный код.

[Yadryara]

По поводу помощи задал вопрос здесь.

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

[Yadryara]

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

7 разрешённых остатков задал явно:

rost17=12; rost19=4; rost23=4; rost29=18; rost31=3; rost37=1; rost41=1;

Кроме того, слегка изменил вывод и сделал засечку времени. Запустил из консоли:

gp.exe Rab-15-mak.gp
                                          GP/PARI CALCULATOR Version 2.17.0 (released)
                                  amd64 running mingw (x86-64/GMP-6.1.2 kernel) 64-bit version
                                       compiled: Sep 28 2024, gcc version 12-posix (GCC)
                                                    threading engine: single
                                         (readline v8.0 enabled, extended help enabled)

                                             Copyright (C) 2000-2024 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and comes WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?18 for how to get moral (and possibly technical) support.

parisize = 8000000, primelimit = 1048576, factorlimit = 1048576

74153990393699851280099: [0,18,24,48,54,60,84,90,108]

kkan: 68913152
end

13min, 47,374 ms


Goodbye!

Как видим, найдена очаровательная центральная девяточка

Также видим враньё ИИ:

gris в сообщении #1699535 писал(а):

Она довольно тяжёлая: вложенные циклы по ~28×32×38×44×46 ≈ 67 миллионов итераций,

Не 67, а 69 лямов.

Эта прога посчитала юнит за $13\cdot60+47=827$ секунд.

А программа Дмитрия у меня считала один юнит вместе с дополнительной статистикой 41-42 секунды. Традиционно посчитаю не в свою пользу — возьму 43 секунды. Работали 12 потоков. А за какое время справился бы один поток? Не знаю, но опять посчитаю не в свою пользу — просто умножу на 12. $43\cdot12=516$ секунд.

Юниты у нас конечно разные, в нашем юните проверяется в 1760 раз больше кандидатов. Таким образом, соотношение скоростей:

$$\frac{827\cdot1760}{516}\approx2821$$

То бишь программа Дмитрия быстрее представленной по меньшей мере в 2800 раз.

[gris]

Yadryara меня привлекло время 13. секунд, минут. Запустил свою давнишнюю прогу

(09:27) gp > \r C:/GRIS/9-108/search_by_pattern_9.gp
369733791264 number from
369733791264 number to
search in 74153990393530952224320 (7.4 E22) - 74153990393731512714450 (7.4 E22) L=2.01 E11
31539200 formulae to generate
74153990393699851280099: [0, 18, 24, 48, 54, 60, 84, 90, 108]
time = 13min, 55,620 ms.
(09:44) gp >

Тоже с предустановлением. Не знаю, откуда взялся номер периода, но на нём было найдено именно ваше девяточко и именно за 13 мин. Совпадение! Но тут проверился весь 31 млн формул. Я рад, что немножко оживил тему и авторитетные гуру даже немного обсудили сопутствующие вопросы.
Но товарищ Yadryara, произошла ужасная ошибка! Я нашёл другой ключ и запер для себя дверь в запретную комнату. Иногда залезаю туда через форточку. Пролезаю пока:)
Оказалось, что для кортежей я не гожусь

[Yadryara]

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

А теперича попробуйте ускорить вашу прогу, проанализировав советы.

Я вот добавил в программу две строчки и ускорил работу более чем вдвое:

kkan: 68913152
end

5min, 45,377 ms

Правда, хотя кандидатов проверено столько же, та 9-ка уже не нашлась. Но ведь главная цель-то найти 15-ку, а не 9-ку, не правда ли?

[wrest]

maxal в сообщении #1699663 писал(а):

используйте сбалансированный код.

(Оффтоп)

Я просто запустил код Dmitriy40 под WSL2 (не WSL) чтобы посмотреть есть ли разница с его mingw.
"Эталонный код" который у Dmitriy40 даёт ускорение почти в 4 раза, у меня в WSL2 тоже ускоряется по количеству потоков ( почти в 8 раз).

Мне обёртка в mingw не нравится концептуально, поэтому я использую WSL2, если на компе. Хотя в файле по ссылке что вы дали советуют первую версию WSL, но мне кажется что это совет устарел. Но настаивать не буду - не тестировал сам.
Но т.к. я использую pari/gp для дилетанстких целей, то пишу скрипты и запускаю в основном на планшете, arm64 и в один поток. В принципе, меня однопоточная производительность современных snapdragon вполне устраивает. Код исполняется ядром линукс нативно, без java-машины андроида. Но вот можно ли собрать многопоток не знаю (не уверен что можно). Я изначально собирал pari/gp на планшете сам, но потом добрые люди взялись выкладывать в репозиторий, так что я беру что дают.

[DemISdx]

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

maxal в сообщении #1699663 писал(а):

используйте сбалансированный код.

(Оффтоп)

...
Но т.к. я использую pari/gp для дилетанстких целей, то пишу скрипты и запускаю в основном на планшете, arm64 и в один поток.
...
Но вот можно ли собрать многопоток не знаю (не уверен что можно). Я изначально собирал pari/gp на планшете сам, но потом добрые люди взялись выкладывать в репозиторий, так что я беру что дают.

Из моих наблюдений под катом:

(Оффтоп)

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

/usr/local/bin/gp-2.9
                                                       GP/PARI CALCULATOR Version 2.9.3 (released)
                                             amd64 running freebsd (x86-64/GMP-6.1.2 kernel) 64-bit version
                        compiled: Jul 31 2022, FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 5.0.1)
                                                                threading engine: pthread
                                                     (readline v7.0 enabled, extended help enabled)

                                                         Copyright (C) 2000-2017 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and comes WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?15 for how to get moral (and possibly technical) support.

parisize = 8000000, primelimit = 500000, nbthreads = 16

uname -a
FreeBSD teo 11.1-STABLE FreeBSD 11.1-STABLE #0: Mon Feb 19 17:02:43 MSK 2018     demis@teo:/usr/obj/usr/src/sys/GENERIC  amd64

На линуксе, под убунтой, что 20.04, что 22.04, что 24.04 - вроде аналогично было.
Убунту на arm процессоре, кажется (подзабыл), также собиралась.
Если не компилировать (не собирать), а именно установить пакетом, вроде тоже так было.
На андроиде не пробовал.

[Dmitriy40]

wrest

(Оффтоп)

А запустите пожалуйста код

\\default(nbthreads,1);
nth=default(nbthreads); stop=precprime(10^8); export(stop,nth); t0=getwalltime(); n=0;
parfor(th=1,nth, my(x,y=0,a); forstep(a=th,stop-1,nth, if(ispseudoprime(lift(chinese(Mod(1,9699690),Mod(a,stop)))), y++); ); y, r,n+=r);
print("n=",n,"/",stop-1,", nth=",nth,", time: ",strtime(getwalltime()-t0));

в двух вариантах, сначала в показанном, потом с раскомментированной первой строкой (чтобы в один поток). У меня вывод такой:
n=17468130/99999988, nth=4, time: 2min, 52,561 ms
n=17468130/99999988, nth=1, time: 5min, 7,304 ms
Здесь ручное деление на подзадачи, выполняемые параллельно, и они сделаны максимально большими. По другому этот цикл уже похоже не улучшить если только совсем не менять алгоритм.