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

[Yadryara]

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

for(j = 1, #prter, if( bo[j] == i % prter[j], next(2)));
for(j = 1, #T, if( T[j] == i % dopp[j] , next(2)));

prter — простые для терапевтики;
bo — badost, плохие остатки по ним;
dopp — дополнительные простые;
T — оставил обозначение Владимира, тоже плохие остатки, но уже по допам.

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

pro — произведение;
ip — оставил обозначение Дмитрия, интерпретировал как индекс простого (перебираемого места).

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

И "d" у меня от слова displacement=смещение (в том числе в смысле индекса).

Ну а я вот привык, что d это диаметр и меня это путало.

[Dmitriy40]

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

Вроде не все нужны, а начиная с 67:

Теми же операциями осуществляется фильтрация и по простым 3-53 - потому что процессору без разницы какое число лежит в регистре в качестве модуля (пока влезает в формат), хоть простое, хоть куб простого, хоть 3^6, вопрос лишь правильной инициализации и обработки факта "попадания".
И да, я для теста использую известное решение M48n21 с паттерном 0-3-16-2-8!. Просто оно под рукой и в тестовом коде.

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

Мне ничего тестировать пока не нужно?

Мне предложить пока нечего.

-- 17.01.2026, 12:03 --

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

терапевтики

Прямо глаз режет ... Мы вроде не медициной занимаемся.

[Yadryara]

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

И да, я для теста использую известное решение M48n21 с паттерном 0-3-16-2-8!.

Ну оно маловато вроде. 47-знаков при нынешней работе с 55-57-значными.

Может лучше взять какую-нибудь из 5 известных 22-к:

3763919492009990910466562016703823421391962461493338 9204926595955930659029610200709650474407650679458585 12928151557178753218526554700017805780952517953844761 91961526307286709380597649336434597932204049205291537
53266808345089279788448860804694037142466315516054607641

Здесь на разный вкус: 52-56 знаков и простых, то одно, то ноль.

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

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

терапевтики

Прямо глаз режет ... Мы вроде не медициной занимаемся.

Так это не я придумал. Уже цитировал:

VAL в сообщении #1549231 писал(а):

список "терапевтических" исключений (по одному на каждое p от 5 до 37).

Можно конечно заменить это слово, но я уже привык.

[Yadryara]

Я пока так и не смог заставить себя изучать С-код. Может позже попробую, на простых примерах.

А пока ошибки исправляю в PARI. И вот такие моменты возникли. Когда большое количество комплектов считаешь (до 400), то памяти не хватает.

  ***   at top-level: init_RabUb_240_68_1()
  ***                 ^---------------------
  *** init_RabUb_240_68_1: the PARI stack overflows !
  current stack size: 4000002048 (3814.699 Mbytes)
  [hint] you can increase 'parisizemax' using default()

  ***   Break loop: type 'break' to go back to GP prompt

И так и сяк пробовал: и переносил нижнюю команду из этой связки, и отменял обе...

default(factor_add_primes,1);
removeprimes(addprimes());

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

И не сразу заметил, что иногда ошибка другая:

  *** init_RabUb_240_68_1: Warning: increasing stack size to 3400003584.
  ***   at top-level: init_RabUb_240_68_1()
  ***                 ^---------------------
  *** init_RabUb_240_68_1: bug in PARI/GP (Segmentation Fault), please report.
  ***   Break loop: type 'break' to go back to GP prompt
break>

И, поскольку я не заметил что она друга, вылечил её так же как и при нехватке памяти: перезапуском с того самого комплекта. Причём уде два раза вылечил.

То есть эта сегментация тоже, видать, с памятью как-то связана....

[Yadryara]

С памятью вообще ситуация очень интересная. Её то много тратится, то мало. Вот, например, перезапуск с 314-го юнита до конца:

(Инфа с экрана)

Potok 8

314.   1 2   1 5   1 2     13 12   17 16   19 3
389082314252108286946881865466328676782941140         111111   1 1111 111    1        15
     1min, 7,723 ms
315.   1 2   1 5   1 3     13 12   17 16   19 4     1min, 8,729 ms
316.   1 2   1 5   1 4     13 12   17 16   19 5
  *** init_RabUb_240_68_1: Warning: increasing stack size to 16000000.
     1min, 8,552 ms
317.   1 2   1 5   1 5     13 12   17 16   19 8     1min, 6,423 ms
318.   1 2   1 5   1 6     13 12   17 16   19 14    1min, 6,896 ms
319.   1 2   1 5   1 7     13 12   17 16   19 18    1min, 7,803 ms
320.   1 2   1 5   1 8     13 12   17 16   19 19    1min, 10,298 ms
321.   1 1   1 1   1 1     13 9   17 5   19 2       1min, 10,360 ms
322.   1 1   1 1   1 2     13 9   17 5   19 3       1min, 5,812 ms
323.   1 1   1 1   1 3     13 9   17 5   19 7
  *** init_RabUb_240_68_1: Warning: increasing stack size to 32000000.
     1min, 6,086 ms
324.   1 1   1 1   1 4     13 9   17 5   19 13     1min, 6,318 ms
325.   1 1   1 1   1 5     13 9   17 5   19 16     1min, 6,553 ms
326.   1 1   1 1   1 6     13 9   17 5   19 17     1min, 6,327 ms
327.   1 1   1 1   1 7     13 9   17 5   19 18     1min, 6,102 ms
328.   1 1   1 1   1 8     13 9   17 5   19 19     1min, 6,835 ms
329.   1 1   1 2   1 1     13 9   17 7   19 2      1min, 11,536 ms
330.   1 1   1 2   1 2     13 9   17 7   19 3      1min, 7,989 ms
331.   1 1   1 2   1 3     13 9   17 7   19 5
  *** init_RabUb_240_68_1: Warning: increasing stack size to 64000000.
     1min, 11,511 ms
332.   1 1   1 2   1 4     13 9   17 7   19 13     1min, 7,414 ms
333.   1 1   1 2   1 5     13 9   17 7   19 16     1min, 6,498 ms
334.   1 1   1 2   1 6     13 9   17 7   19 17     1min, 7,410 ms
335.   1 1   1 2   1 7     13 9   17 7   19 18
  *** init_RabUb_240_68_1: Warning: increasing stack size to 128000000.
     1min, 7,419 ms
336.   1 1   1 2   1 8     13 9   17 7   19 19     1min, 6,888 ms
337.   1 1   1 3   1 1     13 9   17 13   19 2     1min, 7,254 ms
338.   1 1   1 3   1 2     13 9   17 13   19 3     1min, 4,319 ms
339.   1 1   1 3   1 3     13 9   17 13   19 5
  *** init_RabUb_240_68_1: Warning: increasing stack size to 256000000.
     1min, 4,288 ms
340.   1 1   1 3   1 4     13 9   17 13   19 7     1min, 4,163 ms
341.   1 1   1 3   1 5     13 9   17 13   19 16
  *** init_RabUb_240_68_1: Warning: increasing stack size to 512000000.
     1min, 4,238 ms
342.   1 1   1 3   1 6     13 9   17 13   19 17
  *** init_RabUb_240_68_1: Warning: increasing stack size to 1024000000.
     1min, 4,744 ms
343.   1 1   1 3   1 7     13 9   17 13   19 18     1min, 3,834 ms
344.   1 1   1 3   1 8     13 9   17 13   19 19     1min, 3,872 ms
345.   1 1   1 4   1 1     13 9   17 16   19 2      1min, 4,486 ms
346.   1 1   1 4   1 2     13 9   17 16   19 3      1min, 4,403 ms
347.   1 1   1 4   1 3     13 9   17 16   19 5      1min, 3,796 ms
348.   1 1   1 4   1 4     13 9   17 16   19 7      1min, 3,779 ms
349.   1 1   1 4   1 5     13 9   17 16   19 13     1min, 3,155 ms
350.   1 1   1 4   1 6     13 9   17 16   19 17     1min, 2,245 ms
351.   1 1   1 4   1 7     13 9   17 16   19 18
370397859757700244320322754360227080886302041             11111 111111 1 11111        17
     1min, 2,687 ms
352.   1 1   1 4   1 8     13 9   17 16   19 19     1min, 2,144 ms
353.   1 1   1 5   1 1     13 9   17 17   19 2      1min, 1,523 ms
354.   1 1   1 5   1 2     13 9   17 17   19 3      1min, 1,615 ms
355.   1 1   1 5   1 3     13 9   17 17   19 5      1min, 1,593 ms
356.   1 1   1 5   1 4     13 9   17 17   19 7      1min, 1,374 ms
357.   1 1   1 5   1 5     13 9   17 17   19 13     1min, 1,465 ms
358.   1 1   1 5   1 6     13 9   17 17   19 16     1min, 1,677 ms
359.   1 1   1 5   1 7     13 9   17 17   19 18     1min, 1,499 ms
360.   1 1   1 5   1 8     13 9   17 17   19 19     1min, 1,442 ms
361.   1 2   1 1   1 1     13 13   17 5   19 2      1min, 1,700 ms
362.   1 2   1 1   1 2     13 13   17 5   19 3      1min, 1,549 ms
363.   1 2   1 1   1 3     13 13   17 5   19 7      1min, 1,448 ms
364.   1 2   1 1   1 4     13 13   17 5   19 9      1min, 1,579 ms
365.   1 2   1 1   1 5     13 13   17 5   19 16     1min, 1,987 ms
366.   1 2   1 1   1 6     13 13   17 5   19 17     1min, 1,578 ms
367.   1 2   1 1   1 7     13 13   17 5   19 18     1min, 1,013 ms
368.   1 2   1 1   1 8     13 13   17 5   19 19     1min, 869 ms
369.   1 2   1 2   1 1     13 13   17 7   19 2
  *** init_RabUb_240_68_1: Warning: increasing stack size to 2048000000.
     1min, 6,611 ms
370.   1 2   1 2   1 2     13 13   17 7   19 3     1min, 976 ms
371.   1 2   1 2   1 3     13 13   17 7   19 5     1min, 916 ms
372.   1 2   1 2   1 4     13 13   17 7   19 9
  *** init_RabUb_240_68_1: Warning: increasing stack size to 4096000000.
     1min, 1,891 ms
373.   1 2   1 2   1 5     13 13   17 7   19 16
  *** init_RabUb_240_68_1: Warning: increasing stack size to 7000002560.
     1min, 6,206 ms
374.   1 2   1 2   1 6     13 13   17 7   19 17     1min, 1,808 ms
375.   1 2   1 2   1 7     13 13   17 7   19 18     1min, 1,308 ms
376.   1 2   1 2   1 8     13 13   17 7   19 19     1min, 940 ms
377.   1 2   1 3   1 1     13 13   17 9   19 2      1min, 946 ms
378.   1 2   1 3   1 2     13 13   17 9   19 3      1min, 790 ms
379.   1 2   1 3   1 3     13 13   17 9   19 5      1min, 850 ms
380.   1 2   1 3   1 4     13 13   17 9   19 7      1min, 887 ms
381.   1 2   1 3   1 5     13 13   17 9   19 16     1min, 1,122 ms
382.   1 2   1 3   1 6     13 13   17 9   19 17     1min, 885 ms
383.   1 2   1 3   1 7     13 13   17 9   19 18     1min, 909 ms
384.   1 2   1 3   1 8     13 13   17 9   19 19     1min, 965 ms
385.   1 2   1 4   1 1     13 13   17 16   19 2     1min, 1,768 ms
386.   1 2   1 4   1 2     13 13   17 16   19 3     1min, 1,925 ms
387.   1 2   1 4   1 3     13 13   17 16   19 5     1min, 2,403 ms
388.   1 2   1 4   1 4     13 13   17 16   19 7     1min, 2,394 ms
389.   1 2   1 4   1 5     13 13   17 16   19 9     1min, 2,193 ms
390.   1 2   1 4   1 6     13 13   17 16   19 17    1min, 2,592 ms
391.   1 2   1 4   1 7     13 13   17 16   19 18    1min, 2,830 ms
392.   1 2   1 4   1 8     13 13   17 16   19 19    1min, 3,036 ms
393.   1 2   1 5   1 1     13 13   17 17   19 2     1min, 2,185 ms
394.   1 2   1 5   1 2     13 13   17 17   19 3     1min, 2,105 ms
395.   1 2   1 5   1 3     13 13   17 17   19 5     1min, 1,825 ms
396.   1 2   1 5   1 4     13 13   17 17   19 7     1min, 1,663 ms
397.   1 2   1 5   1 5     13 13   17 17   19 9     1min, 2,018 ms
398.   1 2   1 5   1 6     13 13   17 17   19 16    1min, 2,094 ms
399.   1 2   1 5   1 7     13 13   17 17   19 18    1min, 1,874 ms
400.   1 2   1 5   1 8     13 13   17 17   19 19    1min, 1,868 ms

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

В данном случае добавка была побольше, потому что для других потоков памяти обычно всё равно не хватает, даже 7Гб на поток. Кстати, сомневаюсь, что у меня на самом деле в компе так много памяти.

[wrest]

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

Когда большое количество комплектов считаешь (до 400), то памяти не хватает.

На мой взгляд, это признак или утечки (если компилировали без -g) или слишком глубокой рекурсии где-то.
В режиме интерпретации можно устанавливать различные уровни логирования расхода памяти (см. debugmem здесь https://pari.math.u-bordeaux.fr/dochtml ... aults.html ) , и плюс обычно сообщается какая функция переполнила стек (например КТО может потреблять немало).

[Yadryara]

Благодарю.

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

(если компилировали без -g)

-g у меня указано, обычная команда: gp2c-run -g RabUb_400_79_1.gp

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

В режиме интерпретации

Вот, кстати Демис, насколько понимаю, считает в режиме интерпретации и никаких проблем не было: зарезервировано всего лишь 128M на поток.

У меня тоже при тестировании в интерпретаторе (вообще без Убунты) вполне хватало столько же памяти.

Может мне стоит к обычным строкам в программе

/*
GP;default(parisizemax, 8000M);
GP;init_RabUb_400_79_1();
*/

добавить, например,

GP;debugmem = 2;

? И посмотреть что покажет.

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

плюс обычно сообщается какая функция переполнила стек (например КТО может потреблять немало).

Ну вот для того чтобы оставаться внизу, среди сравнительно маленьких чисел, приходится вычислять нужные числа все 16 миллионов раз ($400\cdot8!$). Но интерпретатор справляется на ура. И я пока грешу на С-код.

[Dmitriy40]

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

например КТО может потреблять немало

С чего бы? Это же не факторизация, там всего пара-тройка констант на каждый аргумент, не более, очень вряд ли КТО запускается от вектора в десятки миллионов элементов.

[wrest]

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

Но интерпретатор справляется на ура. И я пока грешу на С-код.

Я вам много раз говорил, что на мой взгляд лучше если вы сделаете функцию/функции которые будете компилировать. Что переменные в функции надо все объявлять через my(). Тогда у вас почти нет глобальных переменных, а локальные изолируются и мусор собирается. Но у вас -- свой взгляд :) Не исключено, конечно, что недорабатывает компилятор gp2c и не вставляет достаточно процедур по сборке мусора со стека.

[Yadryara]

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

Но у вас -- свой взгляд :)

Не то чтобы свой взгляд, просто другие привычки. Я как привык с 80-х годов писать код на Бейсике, где поначалу не только отступов не было, но и все строки нумеровались, так и пишу без отступов. И не путаюсь вроде.

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

У меня нет принципиальных возражений против тех или иных приёмов программирования или оформления кода, а есть привычки, возможно, не самые полезные.

По поводу функции:

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

При этом, для эффективной параллельной работы надо, чтобы функция работала заметное время (единицы-десятки секунд), а не вызывалась десятки-тысячи или более раз в секунду.

С одной стороны это так. Но вы видели где 23-ка нашлась? Опять внизу: 2e53. То есть условия задачи требуют искать внизу, а это значит, что нужно вызывать функцию эти самые миллионы раз, для каждого паттерна.

То есть нужен какой-то разумный компромисс между этими взаимопротиворечивыми факторами.

Пока у меня не все переменные my(). Я не уверен, что это правильно: каждый раз вызывать функцию, которая и так выполняется все 16 млн раз для каждого паттерна. Для 48 делителей вызывал, считали каждый паттерн подольше и из-за этого повыше. Для 24-х всё-таки решил попробовать без вызова.

А может мне батник написать, чтобы перезапускать программу через каждые 40 юнитов? Или файл .RUN поправить. Сейчас там такие строки:

install("init_RabUb_400_79_1","vp","init_RabUb_400_79_1","./RabUb_400_79_1.gp.so");
default(parisizemax, 9000M);
init_RabUb_400_79_1();

То есть нужно как-то запустить не одну программу, а 10 штук последовательно.

[Dmitriy40]

Запускайте для каждого юнита, вряд ли накладные расходы на запуск превышают доли секунд, что на минутном интервале несущественно.
Вместо батника вполне можно использовать сам PARI с командой system (у меня как-то было что три gp файла вызывали друг друга).

[wrest]

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

С одной стороны это так. Но вы видели где 23-ка нашлась? Опять внизу: 2e53. То есть условия задачи требуют искать внизу, а это значит, что нужно вызывать функцию эти самые миллионы раз, для каждого паттерна.

Тут я ничего не понял, пропускаю мимо ушей.

-- 06.02.2026, 13:47 --

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

Пока у меня не все переменные my(). Я не уверен, что это правильно: каждый раз вызывать функцию, которая и так выполняется все 16 млн раз для каждого паттерна.

Тут тоже непонятно. Что за функция, что делает, как долго работает.

-- 06.02.2026, 13:49 --

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

А может мне батник написать, чтобы перезапускать программу через каждые 40 юнитов?

Какой батник? В моём понимании, мы говорим про линукс. Если всё вышесказанное вами про gp.exe в обёртке mingw в виндовс, я пас, тогда вообще не понимаю о чём речь.

-- 06.02.2026, 13:56 --

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

Не то чтобы свой взгляд, просто другие привычки. Я как привык с 80-х годов писать код на Бейсике, где поначалу не только отступов не было, но и все строки нумеровались, так и пишу без отступов. И не путаюсь вроде.

Это уже обсуждалось. Ваше дело как писать, ессно. Но вероятность оказания вам консультаций/помощи снижается если вы на pari/gp пишете как на бейсике, т.к. помощь вам - уже не ваше дело, а помогающего. Тут ваше решение и полная свобода выбора: продолжать писать как на бейсике и разбираться потом самому, или применить более структурированный подход, понятный тому, кто будет пробовать консультировать.

[Yadryara]

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

Тут я ничего не понял, пропускаю мимо ушей.

По поводу счёта внизу напишу в теме.

Функция вот эта, только для 24-х делителей она попроще, обе доппроверки по numdiv выкинуты. И предпростые не до $2^{20}$, а до $2^{17}$.

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

Сейчас функция проверки конкретного паттерна у меня выглядит вот так:

В последнее время она работает где-то 0.016 секунды. Как видно из поста выше, она отрабатывает юнит примерно за 66-70 секунд и за это время успевает проверить 4480 паттернов.

-- 06.02.2026, 14:15 --

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

В моём понимании, мы говорим про линукс.

Даже точнее: про Убунту. И я хочу попробовать последовательно запустить 10 программ, которые будут отличаться одним числом.

[wrest]

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

Функция вот эта

Там есть строка

for(i:small = starti, starti + koli - 1,

но переменная koli нигде не определена. Значит, переменная определена глобально. Это плохо, и полагаю, неоправдано. Если ещё испольвование глобальных больших векторов куда ни шло, то целое... Ну и если это koli у вас глобально длинное, то при компиляции и переменная цикла i не сможет остаться короткой, скорее всего.
И что, вы хотите сказать что пр вызове функция fun() при её вызове работает всего 16мс? Если да, то не очень хорошо.

[Yadryara]

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

Вместо батника вполне можно использовать сам PARI с командой system (у меня как-то было что три gp файла вызывали друг друга).

Спасибо. Вопрос в том сработает ли это в Убунте.

wrest, определил переменные как small. Существенной разницы пока нет. Все команды, которые были в функции, сохранены, но от самой функции я отказался. То есть убрал вызов, шапку и возврат.

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