Как писать быстрые программы

[wrest]

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

Если под распилом Вы подразумеваете разбросать код по функциям, то нет, это замедлит.

Смотря как пилить. Ясно, что "основное вычисление" надо оставить в одной функции, которая работает не вызывая другие [пользовательские] функции как минимум несколько секунд.
Ну и логически разделить, просто в коде.

[Dmitriy40]

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

Ясно, что "основное вычисление" надо оставить в одной функции, которая работает не вызывая другие [пользовательские] функции как минимум несколько секунд.

Достаточно и доли секунды.
Я недавно измерил скорость проверки кортежа (не совсем кода из этой темы, но достаточно близкого), вышло 20мкс расчётных - в том смысле что столько в среднем занимает одна итерация перебора кортежей, но с учётом хорошей фильтрации реально код проверки занимает порядка 100мкс, просто он вызывается лишь для примерно 1/6 всех итераций, а в остальных случаях отрабатывает намного быстрее. Вызов функции вовсе не бесплатен и займёт доли мкс если не считанные нс (если не передавать огромные массивы), т.е. вполне можно всю проверку конкретного кортежа убрать в функцию. Только я не очень понимаю зачем, ведь ей понадобятся кучи структур и переменных снаружи (пусть и read only, т.е. без побочных эффектов). А уровни вложенности циклов вполне видны при использовании правильных отступов (за что я всех упорно агитирую).

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

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

[wrest]

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

так это я у вас хотел спросить. Вы же теперь тестировать начали.

Придумал как объективно померить скорости
Запускал ваш код (который вы прислали через личку) и тот который отправил вам я (с объявлениями типов)
поменял строчку там и там
write(log_name1, potok, " ", nomra, ".");
на
write(log_name1, potok, " ", nomra, ". ",strtime(getwalltime()-t0));
подождал когда появится вторая запись в логе. обоим кодам дал 6 поток.
Ваш код (компилированный).
6 1. 1 ms
6 2. 6min, 25,572 ms
Типизированный код-функция (компилированный)
6 1. 0 ms
6 2. 6min, 15,273 ms

Ну такое 5%

Кстати о параллельном счёте.

Поскольку я обернул ваш код в функцию ptk(), которая принимает номер "потока", то теперь вы можете запускать например так, в одной сессии gp:

? parfor(i=7,11,ptk(i))

Я пробовал -- запускается. На экране конечно каша т.к. все пятеро печатают на экран вперемежку.
Но! Монитор загрузки процессора показывает, что на 100% загружены 5 ядер (ессно, это 5 гипертрейдинговых ядер, не настоящих, т.к. настоящих 4). А вот памяти на пятерых ушло где-то 50Мбайт, вместо по 25 на каждого если запускать 5 штук gp в разных сессиях.
https://iimg.su/i/JSBpDC (это для Yadryara т.к. у него проблемы с картинками вставленными в форум).
Это дополнительно иллюстрирует почему независимые от глобальных переменных функции могут пригодиться
Но вот что будет если один из экземпляров ptk() переполнит стек не знаю -- наверное остановятся все пять.

[wrest]

Dmitriy40
Я тут вспомнил вот что. Наблюдая за нагрузкой ноутбучного процессора в вендовом task manager (не применительно к pari/gp а вообще) я заметил, что когда нагрузка увеличивается и начинает растекаться по нескольким ядрам, частота падает.
Я полагаю, что так ограничивается тепловыделение, чтобы не перегревалось и держалось в примерно заявленных 15Вт TDP.
Так что общая (многопоточная) производительность под многопоточной нагрузкой начинает расти, но каждого ядра - падать. Троттлится, в общем.
Кстати при работе от батареи ещё хуже с производительностью (на моём ноуте), душится нещадно чтобы батарея хоть как-то продержалась.

Возможно, в настольных системах с настольными же процессорами это не так, т.к. там TDP 100-ваттные и больше, огромные кулеры и вот это всё.

[Dmitriy40]

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

Монитор загрузки процессора показывает, что на 100% загружены 5 ядер

Это не гарантия, надо проверять именно время завершения всех потоков, будет ли оно в 5 (или хоть в 4.5) раз меньше.

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

Я полагаю, что так ограничивается тепловыделение, чтобы не перегревалось и держалось в примерно заявленных 15Вт TDP.

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

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

Возможно, в настольных системах с настольными же процессорами это не так, т.к. там TDP 100-ваттные и больше, огромные кулеры и вот это всё.

Ещё недавно это было тоже так: при повышении нагрузки частота падала. Это особенно заметно на многоядерных серверных процессорах, 10 ядер и более, но было и на обычных core i10/11/12, правда в них это происходило при AVX нагрузке. В core i14 от этого вроде отказались (похоже под давлением конкуренции с амд) и если охлаждение позволяет не перегреваться, то частоты гонятся до упора, потреблять при этом может и 250Вт, и более.

[Yadryara]

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

https://iimg.su/i/JSBpDC (это для Yadryara т.к. у него проблемы с картинками вставленными в форум).

Спасибо, но я не смог прочитать. Вот я писал вчера:

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

Кстати, хорошо помню, что на форуме ругали Радикал, однако ж из 4-х он показывает лучше всех.

[wrest]

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

Спасибо, но я не смог прочитать.

Не страшно, я текстом описал тоже.

[wrest]

Замерил виемя на КТО
Функция chinese() работает 0,01% времени.
К сожалению, из-за досрочного прерывания циклов (иногда через уровень вверх) замерить время на факторизацию трудно.
Но КТО там точно не проблема.

На цикл по индексам d от 1 до #v (отспв кандидктов) 5%
На пррверки, являются ли (n + onlyp[iop] - 1) / v[onlyp[iop]] простыми - 8%

Куда уходит 85% времени покашта неясно

[Yadryara]

wrest
Я очень благодарен вам, что вы не бросили эту программу.

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

Вот опять, теперь уже в зеркальной группе нормально считаются только 7 комплектов из 44. Но с другими симптомами — если раньше возникала ошибка в КТО, то сейчас счёт вроде идёт, но ни одного приближения не находится.

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

[Yadryara]

Интересное кино. Вот сравнение времён работы нынешней проги для D(48, 22):

Cons PARI      Ubuntu

44,776 ms   49,118 ms

На 9% медленнее.

То есть похоже, что факторизация в три этапа для такой реализации не походит. Напомню, что прога для D(24, 20) выполнялась в Ubuntu на 93% быстрее. В ней была факторизация в один этап.

-- 21.11.2025, 07:43 --

Кстати, я разобрался как запускать после компиляции, но не разобрался пока как запускать уже готовую прогу второй-третий раз.

-- 21.11.2025, 08:36 --

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

для повторного запуска без изменений в тексте программы (т.е. когда не нужно компилировать заново) можно запускать так
gp penta.gp.run - файл penta.gp.run будет создан на этапе компиляции, и именно его в итоге и запускает gp2c

Не, не получается так. Ни из PARI не получается так запустить, ни из Ubuntu.

[Yadryara]

wrest, вот сейчас прога простая. Вам не составит труда разобраться в ней. Однако же под Убунту пашет медленнее, местами чуть не в два раза.

PARI из консоли:

10^  From 1e6         2     4     8    16                   Time

   8   131593       413   492    92     0                 843 ms
   9   131596       364   495   133     4               1,011 ms
  10   131591       330   487   169    11               1,262 ms
  11   131587       299   479   198    21               1,677 ms
  12   131575       277   464   222    33               2,415 ms
  13   131586       253   457   242    44               3,770 ms
  14   131610       236   442   257    57               5,831 ms
  15   131577       220   431   273    68               8,206 ms
  16   131611       206   419   283    80              11,229 ms
  17   131604       193   407   293    91              16,410 ms
  18   131579       182   397   301   101              20,336 ms
  19   131593       174   387   304   111              30,576 ms
  20   131590       166   375   310   120              45,190 ms
  21   131597       157   366   315   128              57,913 ms
  22   131580       151   355   318   138        1min, 15,884 ms
  23   131588       144   349   319   143        1min, 34,359 ms
  24   131572       138   341   322   151        1min, 53,365 ms
  25   131573       135   329   323   159        2min, 20,116 ms
  26   131583       127   325   323   165        2min, 48,863 ms
  27   131581       123   319   324   170        3min, 21,185 ms
  28   131573       118   311   324   176        4min,  4,160 ms
  29   131597       115   306   323   180        4min, 59,762 ms
  30   131592       110   299   325   185        5min, 58,662 ms
  31   131587       108   293   322   191        7min, 19,684 ms
  32   131593       104   287   321   196        9min,  8,214 ms
  33   131580       101   282   322   198       11min, 30,009 ms

Ubuntu:

   8   131593       413   492   92      0        525 ms
   9   131596       364   495   133     4        941 ms
  10   131591       330   487   169    11        1,798 ms
  11   131587       299   479   198    21        3,117 ms
  12   131575       277   464   222    33        5,173 ms
  13   131586       253   457   242    44        8,290 ms
  14   131610       236   442   257    57        12,967 ms
  15   131577       220   431   273    68        19,901 ms
  16   131611       206   419   283    80        30,819 ms
  17   131604       193   407   293    91        47,365 ms
  18   131579       182   397   301   101        58,414 ms
  19   131593       174   387   304   111        1min,  9,453 ms
  20   131590       166   375   310   120        1min, 29,548 ms
  21   131597       157   366   315   128        1min, 47,881 ms
  22   131580       151   355   318   138        2min,  6,728 ms
  23   131588       144   349   319   143        2min, 32,251 ms
  24   131572       138   341   322   151        2min, 56,582 ms
  25   131573       135   329   323   159        3min, 25,919 ms
  26   131583       127   325   323   165        3min, 55,179 ms
  27   131581       123   319   324   170        4min, 30,877 ms
  28   131573       118   311   324   176        5min,  7,182 ms
  29   131597       115   306   323   180        5min, 53,442 ms
  30   131592       110   299   325   185        6min, 49,764 ms
  31   131587       108   293   322   191        8min,  7,227 ms
  32   131593       104   287   321   196        9min, 59,754 ms
  33   131580       101   282   322   198       11min, 46,644 ms

Для всё больших чисел скорость выравнивается. Может ещё обгонит.

Программа:

(PARI)

{t0=getwalltime();print;

ogrp = 67;

for (ste = 8, 38,

t1=getwalltime(); kol = vector(4); kpod = 0;

forstep( n = 10^ste - 1 * 10^6 - 1, 10^ste - 1, 2,

fac = factor(n); kunp = matsize(fac)[1];

if(fac[1,1] >= ogrp,

kpod++; kdel = 1;

for(i = 1, kunp, kdel *= fac[i,2] + 1);

if(kdel ==  8, kol[3]++;next);
if(kdel ==  4, kol[2]++;next);
if(kdel == 16, kol[4]++;next);
if(kdel ==  2, kol[1]++);

));

print1("  ", ste,"   ", kpod,"       ");
for(i=1,4,print1(round(kol[i]/kpod*1000),"   "));
print(,"     ", strtime(getwalltime()-t1));

);

print;print(strtime(getwalltime()-t0));print;
}quit

[Dmitriy40]

Добавление нулевого (перед первым) factor() позволяет ускорить более чем вдвое.

[wrest]

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

Вам не составит труда разобраться в ней. Однако же под Убунту пашет медленнее, местами чуть не в два раза.

У меня 8 по 16 степени включительно, на андроид- планшете (один поток, архитектура aarch64), интерпретатор работает 35 секунд (в сумме), скомпилированное -- 32 секунды.

Интерпретатор
8   131593       413   492   92   0        1,014 ms
9   131596       364   495   133   4        1,148 ms
10   131591       330   487   169   11        1,357 ms
11   131587       299   479   198   21        1,714 ms
12   131575       277   464   222   33        2,306 ms
13   131586       253   457   242   44        3,397 ms
14   131610       236   442   257   57        5,255 ms
15   131577       220   431   273   68        8,197 ms
16   131611       206   419   283   80        11,355 ms
35,743 ms

Компиляция
8   131593       413   492   92   0        589 ms
9   131596       364   495   133   4        667 ms
10   131591       330   487   169   11        848 ms
11   131587       299   479   198   21        1,182 ms
12   131575       277   464   222   33        1,775 ms
13   131586       253   457   242   44        2,846 ms
14   131610       236   442   257   57        4,746 ms
15   131577       220   431   273   68        8,062 ms
16   131611       206   419   283   80        11,648 ms
32,364 ms

[Dmitriy40]

wrest
Это не мои слова, а Yadryara.

[wrest]

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

Это не мои слова, а Yadryara.

Да, прошу прощения, не успел скорректировать.

-- 24.11.2025, 17:58 --

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

У меня 8 по 16 степени включительно, на андроид- планшете (один поток, архитектура aarch64), интерпретатор работает 35 секунд (в сумме), скомпилированное -- 32 секунды.

Ну и судя по коду, вполне логично, с ростом чисел тяжесть падает на факторизацию а не организацию циклов. И там компиляция не сильно помогает ибо сама функция factor() библиотечная и исполняется максимально быстро.
Тут помог бы науерное parfor(), с выносом циклов факторизации в функцию.