Перешёл было к 8-кам. Но потом всё же решил вернуться к 7-кам, проверить другое количество потоков. Чтобы преодолеть порчу номеров, о которой рассказывал выше стал считал больше юнитов и паттернов. Скорость из-за этого упала. Но сравнительную табличку отчасти удалось состряпать.
Удивительная и хорошая новость: похоже что оптимум не в районе 8-9 потоков, а повыше, может даже больше 12-ти.
Смотрел вариант только для ECM, который по скорости был почти оптимальный, то есть скорость нахождения переваливала через 500 тысяч. Как сказал выше, она снизилась, но из-за удобства сравниваю пока для низкоскоростного варианта:
Код:
8-я фильтрация: ECM 1,1,80 9-я: ECM 1,1,80
Av. Speed
Potoks Pat D(192,7) Sеc S/P Kor/24h
6 1440 5647 1093 758 446792
8 1440 5647 944 655 517161
10 1440 5647 860 597 567379
12 1440 600000 ?
Чем больше потоков, тем сложнее добиться чтобы все те самые 120 юнитов посчитались ровно по одному разу. Та самая порча номеров периодически происходит.
И вот я всё-таки решил попытаться преодолеть это программно. Квен сказал что это из-за гонки. Пока не удаётся полностью решить.
Батник для Винды
(Батник)
Код:
@echo off
title Ubuntu Scripts (Root)
set CHUNK=10
set WIN_COUNT=12
set /a LAST=%WIN_COUNT%-1
for /L %%A in (0,1,%LAST%) do (
start "" wsl.exe -d Ubuntu-24.04 -u root bash -c "cd /home/yadryara/D192-7/1-0-6-0/ECM && ./run_chunk.sh %CHUNK% %%A; exec bash"
powershell -Command "Start-Sleep -Milliseconds 430"
)
Он запускает run_chunk.sh :
(Шелловский батник)
Код:
#!/bin/bash
# 1. Принудительно сохраняем C-код в файл
gp2c -g -o Test_26.gp.c Test_26.gp
# 2. Компилируем в разделяемую библиотеку (1 раз)
gcc -shared -O2 -fPIC -o Test_26.gp.so Test_26.gp.c $(pkg-config --cflags --libs pari 2>/dev/null || echo "-lpari")
# 3. Создаём .run-файл вручную (гарантирует загрузку .so и корректный выход)
cat > Test_26.gp.run << 'EOF'
install("init_Test_26","vp","init_Test_26","./Test_26.gp.so");
default(parisizemax, 8192M);
init_Test_26();
quit
EOF
# 4. Многократный запуск
CHUNK_SIZE=$1 # автоматически подставится из батника
SCRIPT_INDEX=$2 # автоматически подставится 0, 1, 2, 3... из цикла
START=$((SCRIPT_INDEX * CHUNK_SIZE ))
END=$((START + CHUNK_SIZE - 1))
for i in {0..0}; do
for j in $(seq $START $END); do
FILE_NUM=$(( j / 2 + 1 ))
INPUT_FILE="${FILE_NUM}.unit"
( echo "$i"; echo "$j" ) > "$INPUT_FILE" &
CURRENT_INPUT_FILE="$INPUT_FILE" gp -q Test_26.gp.run &
done
done
wait
Здесь запускается рабочая программа Test_26 на PARI/gp. Вот какие в ней релевантные строки:
Код:
install("init_Test_26", "vp", "init_Test_26", "./Test_26.gp.so");
\\ 2. Читаем имя файла из переменной окружения, которую задаст Bash
input_file_name = getenv("CURRENT_INPUT_FILE");
\\ Проверка на всякий случай
if (input_file_name == "", error("КРИТИЧЕСКАЯ ОШИБКА: Переменная CURRENT_INPUT_FILE пуста!"));
\\ 3. Читаем данные из файла (или FIFO-канала)
nomera = readvec(input_file_name);
\\print("Успешно прочитано из [", input_file_name, "]: i = ", nomera[1], ", j = ", nomera[2]);
Наконец-то добился что она вроде работает. Но не совсем так как надо.
Если
set CHUNK=1
set WIN_COUNT=12
То работает нормально, в каждом окне считается свой номер.
А если
set CHUNK=10
set WIN_COUNT=12
То в каждом окне одновременно будет пытаться считать по 10 потоков. А они должны исполняться последовательно, потому что у них один и тот же номер файла.
То есть нужно чтобы в 12-ти одновременно работающих окнах последовательно считались 10 разных номеров:
от 0 до 9 в одном окне,
от 10 до 19 в другом окне,
...
от 110 до 119 в последнем 12-м окне.
