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

[Yadryara]

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

Посчитайте дальше 110e9,

Зачем??? Вам напомнить что я говорил?

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

Обычно конечно падает. Но не всегда, особенно в начале натурального ряда.

Это не флуктуации, это так обычно и бывает: сначала находится меньше всего, затем побольше, а затем уже начинается спад.

Кроме того что я уже вам показал, обратите внимание на самое начало, на первые 10 ярдов. Там самое маленькое число — 36. Думаете это случайно?? Тогда попробуйте посчитать другое доступное количество делителей, 12, например, или побольше.

[Yadryara]

Ну я тем временем продолжал счёт.

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

Автоматический перезапуск пока не применял.

Ну вот теперь, начиная с D(96,10) применяю. Кстати, перечитывал 36-37-ю страницы нынешней темы, там были значительные сложности. А сейчас прям почти с первого раза запустил этот, как понимаю, Шелловский батник:

#!/bin/bash

for i in {0..0}; do
for j in {0..8}; do
    echo ${i} >         nom0.input 
    echo ${j} >>        nom0.input 
    chmod 666   Test_1.gp
    gp2c-run -g Test_1.gp
done
done

Специально для wrest-a. Будете спрашивать почему у меня цикл от нуля до нуля? Вы уже как-то раз у меня в программе один такой цикл увидели и спрашивали.

Насколько помню, вы любите универсальность. Так вот это мне нужно для универсальности. Когда мне будет надо, воткну вместо правого нуля другое число и всё.

Серия            2^     Комплектов       Счёт     Найдено      Время       Скорость
                         посчитано    от 0 до    D(96,10)     секунд   D(96,10)/час

0-0-9-1-0-4!     15     3! * 6!  3       1e37          89       3300             97
0-0-9-1-0-4!     16     3! * 6!  3       1e37          89       3002            107
0-0-9-1-0-4!     17     3! * 6!  3       1e37          89       2968            108
0-0-9-1-0-4!     18     3! * 6!  3       1e37          89       3412             94

0-0-A-0-0-4!     15     3! * 7! 18       1e38         147       3202            165
0-0-A-0-0-4!     16     3! * 7! 18       1e38         147       2841            186
0-0-A-0-0-4!     17     3! * 7! 18       1e38         147       2821            188
0-0-A-0-0-4!     18     3! * 7! 18       1e38         147       3063            173

0-1-9-0-0-4!     15    3!*7!*1 120       1e39         116       2245            186
0-1-9-0-0-4!     16    3!*7!*1 120       1e39         116       2009            208
0-1-9-0-0-4!     17    3!*7!*1 120       1e39         116       1960            213
0-1-9-0-0-4!     18    3!*7!*1 120       1e39         116       2083            200

1-0-9-0-0-4!     15  3!*7!*1*1 400       1e41         163       3118            188
1-0-9-0-0-4!     16  3!*7!*1*1 400       1e41         163       2848            206
1-0-9-0-0-4!     17  3!*7!*1*1 400       1e41         163       2722            216
1-0-9-0-0-4!     18  3!*7!*1*1 400       1e41         163       2810            209

Серия с одним простым уже с большущим трудом выигрывает при подъёме на два порядка.

И, вроде бы, пришло время использовать $2^{11}$ в паттерне. Проверил. Но скорость пока получилась похуже.

Считаю D(96,11). Скорость уже довольно сильно упала. И, чтобы значения оставались целыми, теперь указываю её в пересчёте на сутки.

[Dmitriy40]

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

А сейчас прям почти с первого раза запустил этот, как понимаю, Шелловский батник:

А зачем в циклах каждый раз компилить PARI программу? Она же не меняется, достаточно её скомпилить один раз в начале, а потом просто запускать, меняя в циклах только входные параметры.

[Yadryara]

А что-то у меня не получилось пока. Две команды у меня внутри Test_1.gp:

/*
GP;default(parisizemax, 8192M);
GP;init_Test_1();
*/

И в Шелле они не работают вроде. Или я что-то не так сделал. Чайник, чё Запускаю пока по-старому.

Конечно думал что вроде ни к чему тратить время на компиляцию, хотя это и считанные секунды.

Есть, правда, небольшая польза — иногда подправляю программу по мелочи, типа отступы при выводе на экран. Такие правки на время влиять не должны. И при новом запуске уже работает новая версия.

[Dmitriy40]

Я к тому что команды
chmod 666 Test_1.gp
gp2c-run -g Test_1.gp
можно переставить на 4 строки выше, до обоих for (и убрать из gp2c флаг запуска после компиляции), а внутри циклов на их месте просто вызывать/запускать Test_1 (без расширения).
Менять файл Test_1.gp не нужно.

[andsm_2]

Чуть почитал. Не вполне понял, о чем именно обсуждение, но вроде про написание быстрых программ.
Если в программе есть работа с данными, то зачастую можно многократно ускориться, улучшив работу с памятью. Я как-то поменял менеджер памяти и, за счет уменьшения времени на аллокации, скорость сильно выросла.
Глядя на пример с массивами, и если хочется уйти совсем на низкий уровень, то можно попробовать оптимизировать чтение из памяти. Там, я когда-то тестировал, можно получить примерно 10-кратное ускорение, при помощи оптимального выстраивания чтений. Но, вообще-то, не знаю никого, кто так реально делал в серьезной программе, а не для развлечения.

[Yadryara]

andsm_2 в сообщении #1722576 писал(а):

Не вполне понял, о чем именно обсуждение,

Обобщённое обсуждение обычно малопродуктивно. Так что здесь обсуждаем конкретные задачи. На последних страницах — нахождение цепочек чисел с одинаковым количеством делителей.

andsm_2 в сообщении #1722576 писал(а):

но вроде про написание быстрых программ.

Да, как можно более быстрое их нахождение.

Вот действительно, с переполнением стека проблемы.

andsm_2 в сообщении #1722576 писал(а):

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

Ну здесь вот случай исключительный, вроде Программа вроде довольно сложная, серьёзная, но цепочки ищутся в основном для развлечения, а ещё чтобы скилы повысить. А зачем их повышать? Для удовольствия.

[bob1955]

andsm_2 в сообщении #1722576 писал(а):

Чуть почитал. Не вполне понял, о чем именно обсуждение, но вроде про написание быстрых программ.
Если в программе есть работа с данными, то зачастую можно многократно ускориться, улучшив работу с памятью. Я как-то поменял менеджер памяти и, за счет уменьшения времени на аллокации, скорость сильно выросла.
Глядя на пример с массивами, и если хочется уйти совсем на низкий уровень, то можно попробовать оптимизировать чтение из памяти. Там, я когда-то тестировал, можно получить примерно 10-кратное ускорение, при помощи оптимального выстраивания чтений. Но, вообще-то, не знаю никого, кто так реально делал в серьезной программе, а не для развлечения.

Совершенно верно. Переход на компактный S-box (8 КБ), полностью умещающийся в L1-кэш, и использование Rust без динамических аллокаций внутри горячего цикла уже дали 3-кратный прирост скорости по сравнению с первой версией моего кода.

[Yadryara]

D(96,11) закончил. Ну как закончил — посчитал пока наиболее интересные для меня серии. И опять серия с одним простым лидирует и даже упрочила лидерство. И для этой серии понадобилось посчитать фильтрацию про предпростым до $2^{19}$. Впервые с тех пор как начал подниматься от D(96,6).

Серия            2^      Комплектов       Счёт     Найдено      Время   Сред. скорость
                          посчитано    от 0 до    D(96,11)     секунд   D(96,11)/сутки

0-0-10-1-0-5!    16      3! * 6!  5       1e40         162      15024              932
0-0-10-1-0-5!    17      3! * 6!  5       1e40         162      14494              966
0-0-10-1-0-5!    18      3! * 6!  5       1e40         162      15793              886

0-0-11-0-0-5!    15      3! * 7! 24       1e41         161      11418             1218
0-0-11-0-0-5!    16      3! * 7! 24       1e41         161      10276             1354
0-0-11-0-0-5!    17      3! * 7! 24       1e41         161      10533             1321
0-0-11-0-0-5!    18      3! * 7! 24       1e41         161      10565             1317

0-1-10-0-0-5!    16     3!*7!*1 180       1e42         124       7540             1421
0-1-10-0-0-5!    17     3!*7!*1 180       1e42         124       7101             1509
0-1-10-0-0-5!    18     3!*7!*1 180       1e42         124       7391             1450

1-0-10-0-0-5!    16   3!*7!*1*1 600       1e44         235      10453             1942
1-0-10-0-0-5!    17   3!*7!*1*1 600       1e44         235       9843             2063
1-0-10-0-0-5!    18   3!*7!*1*1 600       1e44         235       9816             2068
1-0-10-0-0-5!    19   3!*7!*1*1 600       1e44         235      10812             1878

[Yadryara]

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

Я к тому что команды
chmod 666 Test_1.gp
gp2c-run -g Test_1.gp
можно переставить на 4 строки выше, до обоих for (и убрать из gp2c флаг запуска после компиляции), а внутри циклов на их месте просто вызывать/запускать Test_1 (без расширения).

Кстати, решил спросить у Квена, как переделать. У него есть особенность как бы выслужиться, сделать ещё и то, о чём не просили, а только лишь, например, упомянули.

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

#!/bin/bash

# 1. Принудительно сохраняем C-код в файл
gp2c -g -o Test_1.gp.c Test_1.gp

# 2. Компилируем в разделяемую библиотеку (1 раз)
gcc -shared -O2 -fPIC -o Test_1.gp.so Test_1.gp.c $(pkg-config --cflags --libs pari 2>/dev/null || echo "-lpari")

# 3. Создаём .run-файл вручную (гарантирует загрузку .so и корректный выход)
cat > Test_1.gp.run << 'EOF'
install("init_Test_1","vp","init_Test_1","./Test_1.gp.so");
default(parisizemax, 8192M);
init_Test_1();
quit
EOF

# 4. Многократный запуск
for i in {0..0}; do
  for j in {0..14}; do
    echo "$i" > nom0.input
    echo "$j" >> nom0.input
    
    # gp автоматически подгрузит скомпилированную .so
    gp -q < Test_1.gp.run
  done
done

Вроде далеко не так как вы предлагали.

Сделал 10 запусков с компиляцией (заняло 275 секунд) со старым батником и 10 запусков с новым — 229 секунд.

То есть на каждом перезапуске экономилось пример $46 / 9 \approx 5$ секунд.

Время пока засекал по win-часам.

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

[Dmitriy40]

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

Вроде далеко не так как вы предлагали.

Это проблемы ИИ. Он мог и ещё в 100500 раз больше текста нагенерить.
Для меня очевидно что если gp2c-run умеет сразу запускать скомпилённый исходник, то он же умеет и не запускать его после компиляции (файл же остаётся на диске). А уж ОС точно умеет запускать любые скомпилённые файлы (это и есть цель компиляции ваще-то).
Так что на мой взгляд достаточно перенести команды chmod и gp2c (без -run) выше циклов, а в цикле лишь запускать (средствами ОС) готовый исполняемый файл.
Но я не знаю как это всё работает в убунте.

[wrest]

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

Для меня очевидно что если gp2c-run умеет сразу запускать скомпилённый исходник, то он же умеет и не запускать его после компиляции (файл же остаётся на диске).

ненене. gp2c-run это текстовый файл, скрипт командной строки (bash, типа "батник" по-вендовому). он запускает транслятор gp2c ("бинарник"), компилятор clang ("бинарник") или какой есть в системе компилятор-линкер Си (для этого есть переменная окружения), создаёт текстовый gp-скрипт myscript.gp.run и в конце, после этого всего запускает интерпретатор командой gp myscript.gp.run и уже в интепретаторе грузится (через install()) скомпилённая функция(-ии) и запускается там, в интепретаторе через init_myscript().

-- 20.04.2026, 20:46 --

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

Так что на мой взгляд достаточно перенести команды chmod и gp2c (без -run) выше циклов, а в цикле лишь запускать (средствами ОС) готовый исполняемый файл.

Готовые исполняемые файлы не создаются. Создаются разделяемые библиотеки (аналог вендовых .dll ).

Сам файл текстовый gp2c-run создаётся при инсталляции gp2c, туда прописываются пути где что находится, команды компиляции и т.п. То есть это системо-зависимый скрипт, а даже более того, можно иметь две инсталляции gp, и gp2c как и сделано кстати у Yadryara - чтобы можно было портить одну инсталляцию gp внедряя в ядро свои функции, но при этом иметь "эталонную" pari/gp от разработчика, которая будет обновляться механизацией менеджера пакетов операционной системы.

[Dmitriy40]

Тогда очевидно можно ентот скрипт разделить на два: компиляция gp2c-compile (почти весь gp2c-run без последней строки запуска готовой программы) и запуск командой gp myscript.gp.run. Первый вызывать перед циклами, вторую в циклах.
Обязана быть точка в которой всё уже скомпилено, но программа ещё не запущена - по ней и поделить. Возможно ИИ так и сделал ...
В любом случае претензии что получилось сложнее чем я советовал - отвергаю.

[wrest]

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

Тогда очевидно можно ентот скрипт разделить на два: компиляция gp2c-compile (почти весь gp2c-run без последней строки запуска готовой программы) и запуск командой gp myscript.gp.run. Первый вызывать перед циклами, вторую в циклах.

Конечно можно.

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

Возможно ИИ так и сделал ...

Ну почти. ИИ решил "руками" делать файл myscript.gp.run, но это не вполне феншуйно, т.к. я научил Yadryara как вставлять в этот файл команды, которые мы хотим чтобы выполнял интерпретатор ДО запуска функций, типа выделения памяти. Скрипт, написанный ИИ это делает, но он не смотрит на .gp исходник котоый написал Yadryara (т.е. это хардкод). Но работать будет.

-- 20.04.2026, 21:08 --

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

В любом случае претензии что получилось сложнее чем я советовал - отвергаю.

Ну понятно -- у вас же нет линуксов

[Yadryara]

wrest
Я мало что понимаю в ваших объяснениях. Можно ли то, что сделал ИИ сделать покороче и понятнее? Или он хорошо сделал и лучше не трогать? Не надо чинить то, что не сломано.

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

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

В любом случае претензии что получилось сложнее чем я советовал - отвергаю.

Ну понятно -- у вас же нет линуксов

А мне непонятно. О каких претензиях речь идёт?