PrMers

GPU-accelerated PRP, Lucas-Lehmer, P-1 and ECM testing for Mersenne numbers.

https://github.com/cherubrock-seb/PrMers

Distributed Gaussian-Mersenne work, public factors and result tracking are available on GMNet.

Releases for Linux, macOS and Windows are available here:

https://github.com/cherubrock-seb/PrMers/releases

PrMers is an OpenCL GPU program focused on long modular arithmetic runs for numbers of the form 2^p - 1. It supports PRP, Lucas-Lehmer, P-1 and ECM workflows, with checkpointing, result JSON output, Prime95 compatible handoff files, worktodo parsing, and an optional web GUI.

The default backend policy is automatic on Linux and Windows. On macOS, Marin is the safe platform default and Aevum is used only when -aevum (or -aevum-fft) is supplied explicitly. PrMers otherwise selects between the Marin backend by Yves Gallot and the optional Aevum backend from the workload, register count and transform sizes. Marin uses an integer IBDWT-style transform modulo 2^64 - 2^32 + 1. Aevum exposes GPUOwl/PRPLL paired integer NTT arithmetic over GF(M31^2) and GF(M61^2) through a PrMers engine::Reg adapter. The v99.7 policy uses measured transform-size thresholds per workload. The adapter retains GPU-side register equality for Gerbicz checks and bounded Mersenne carry canonicalization for residue export.

Use -engine-marin to force Marin, -aevum to force Aevum, or -aevum-auto to request the default policy explicitly. The historical -marin option keeps its previous meaning and selects the internal PrMers NTT path. The standalone engine is intended for publication at https://github.com/cherubrock-seb/aevum-engine.

Contents

• What PrMers can do
• Quick start
• Build from source
• Command line options
• PRP and proof generation
• Lucas-Lehmer modes
• P-1 factoring
• ECM factoring
• worktodo.txt and AutoPrimeNet
• Prime95 and mprime interop
• Gaussian-Mersenne extension
• Gaussian-Mersenne P-1/ECM
• Gaussian-Mersenne ECM Special32 - mathematical note
• Web GUI
• GPU memory test
• NTT and IBDWT transform sizes
• Native PFA radix-3 and radix-9
• Benchmarks
• Backend and code
• Related inspiration
• Must read papers
• License and upstream attribution

What PrMers can do

Area	Status	Notes
Gaussian-Mersenne Proth/PRP	Experimental v99.88	Opt-in -gm; exact lift into 2^(4p)-1, no Aevum-kernel changes
Gaussian-Mersenne P-1/ECM	Experimental v100.00	Opt-in -gm-pm1 / -gm-ecm; deterministic GM Special32 prepass via -gm-ecm-special32
Mersenne PRP	Supported	Default mode; automatic Marin/Aevum on Linux/Windows, Marin by default on macOS
Mersenne Lucas-Lehmer	Supported	Safe GL mode, classic unsafe mode, doubling safe mode
P-1 factoring	Supported	Stage 1, default V-trace Stage 2, classic Stage 2 fallback, resume export, Prime95 handoff
P-1 ultra-low-memory mode	Supported	1-register Stage 1 and 1-register Stage 2 product-exponent path
ECM factoring	Supported	Edwards and Montgomery variants, optional Prime95 Stage 2 handoff
Wagstaff PRP	Supported	W = (2^p + 1) / 3 with -wagstaff
Mersenne cofactors	Supported	PRP with known factors using -factors
worktodo.txt	Supported	PRP and Pminus1 parsing, including Prime95 compatible Pminus1 metadata
Web GUI	Supported	Local browser interface for monitoring and worktodo editing
GPU memory test	Supported	OpenCL VRAM and stability test

Quick start

Run a PRP test on a Mersenne number:

./prmers 136279841

On Linux and Windows, the command above uses automatic backend selection. On macOS it uses Marin by default. Force a backend only for testing or benchmarking:

./prmers 136279841 -engine-marin
./prmers 136279841 -aevum

Run a safe Lucas-Lehmer test:

./prmers 127 -ll

Run P-1 factoring with Stage 1 and Stage 2. Normal-memory Stage 2 uses the V-trace path by default, with conservative automatic D selection:

./prmers 367 -pm1 -b1 11981 -b2 38971

Force the previous classic Stage 2 path when comparing or debugging:

./prmers 367 -pm1 -b1 11981 -b2 38971 -pm1-vtrace-off

Run the MM31 ultra-low-memory P-1 example that uses a 1-register GPU Stage 2:

./prmers 2147483647 -pm1 -b1 100 -b2 5000 -pm1-ultralowmem -nogcd-stage1

Expected test factor for that example:

295257526626031

Run ECM:

./prmers 701 -ecm -b1 6000 -b2 33333 -K 8

Use a worktodo file:

./prmers -worktodo ./worktodo.txt

Start the web GUI:

./prmers -gui -http 3131

Then open the URL printed by the program.

Build from source

For Linux and Windows (MSYS2), plain make is enough. No special CUDA option and no -j flag are required. PrMers always builds its OpenCL engine first; when the complete NVIDIA CUDA Toolkit is detected, the same command also builds the optional CUDA engine. With no Toolkit installed (including AMD/Intel machines), make completes successfully with OpenCL only and prints a clear installation hint.

The CUDA/OpenCL runtime selection is separate: when PrMers uses Aevum on an NVIDIA GPU, it checks which backend is faster and verifies matching residues. It does not blindly prefer CUDA. The existing automatic Marin/Aevum policy remains in force.

Linux (Ubuntu / Debian)

Install PrMers' mandatory build dependencies:

sudo apt update
sudo apt install -y git g++ make ocl-icd-opencl-dev opencl-headers libgmp-dev
git clone https://github.com/cherubrock-seb/PrMers.git
cd PrMers
make

That is the entire source build, with or without an NVIDIA GPU or CUDA SDK. Verify the executable with ./prmers -v. For normal GPU calculations, either install with sudo make install (which provides system-wide kernels), or build for execution from the source directory using make KERNEL_PATH=./kernels/ from a clean checkout. If you previously compiled with another KERNEL_PATH, first run make clean before changing it. Parallel compilation (make -j4 or make -j"$(nproc)") is optional, not required.

Optional: enable native CUDA builds on NVIDIA systems. A working NVIDIA driver alone is not the CUDA development Toolkit. PrMers detects the Toolkit's cuda.h, nvrtc.h, NVRTC library and CUDA driver link library (SDK stub or system library). Install the SDK once and rerun the same make command.

For Ubuntu 24.04 x86_64, with the official NVIDIA package repository:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit
make

For Ubuntu 22.04, Debian, other architectures or distributions, do not reuse the Ubuntu 24.04 repository URL: select your OS using NVIDIA's official CUDA Linux installation guide and then install its cuda-toolkit package. The SDK can be installed without replacing an existing working NVIDIA driver; verify driver compatibility separately when running CUDA.

The expected build messages are:

[Aevum] CUDA SDK found: ... (NVRTC=..., driver link=...)
[Aevum] Compiling optional CUDA plugin in separate directory (OpenCL untouched).
[Aevum] CUDA plugin ready: third_party/aevum/build-engine/libaevum_engine_cuda.so

If no complete Toolkit is found, the message states that CUDA is optional and offers an installation URL. make still succeeds, and the OpenCL engine is usable.

Install to the system (optional):

sudo make install

This installs /usr/local/bin/prmers, the OpenCL engine under /usr/local/lib/prmers/, the CUDA engine there if built, and kernels/tuning data under /usr/local/share/prmers/. The installation does not install CUDA or drivers.

For a self-contained folder (running ./prmers directly from the checkout), build from a fresh checkout with make KERNEL_PATH=./kernels/; otherwise run make clean before changing the existing KERNEL_PATH. A portable-kernel build is not compatible with make install as-is: switch back to the default kernel path and rebuild first.

Windows — MSYS2 UCRT64 Make (recommended for both engines)

Install MSYS2 and open the UCRT64 terminal, not the MSYS or MinGW32 shell:

pacman -Syu
pacman -S --needed --noconfirm git make python \
  mingw-w64-ucrt-x86_64-gcc \
  mingw-w64-ucrt-x86_64-gmp \
  mingw-w64-ucrt-x86_64-opencl-headers \
  mingw-w64-ucrt-x86_64-opencl-icd
git clone https://github.com/cherubrock-seb/PrMers.git
cd PrMers
make

This builds PrMers and OpenCL without requiring CUDA. On NVIDIA Windows systems, install the optional NVIDIA CUDA Toolkit for Windows (include CUDA headers, NVRTC and import libraries). Restart the UCRT64 terminal so CUDA_PATH is visible, and simply run make again. The SDK is detected automatically; prmers.exe and the optional aevum_engine_cuda.dll are built in the source tree. Keep the OpenCL and CUDA plugin libraries together when copying binaries.

Windows GPU use also requires a compatible installed NVIDIA driver. NVIDIA's Windows installation guide describes the driver/toolkit requirements.

macOS (Intel and Apple Silicon)

CUDA is not supported by this build on macOS; make compiles the supported OpenCL engine normally and does not require the NVIDIA Toolkit.

brew install gmp
git clone https://github.com/cherubrock-seb/PrMers.git
cd PrMers
make

On macOS the default GPU computation backend remains Marin, with the existing supported Aevum PRP/LL modes available by explicit selection. P-1 and ECM continue to use Marin under the established macOS safety policy.

Advanced build controls and diagnostics

Command	Behavior
make	OpenCL always; auto-build CUDA if the complete SDK is detected
make -j4	Exactly the same functionality, with parallel compilation
make AEVUM_CUDA_MODE=off	Skip compiling CUDA, never require Toolkit
make aevum-dual	Require the SDK and a successful CUDA build; error otherwise
make AEVUM_CUDA_MODE=required	Require CUDA compilation through the ordinary make target
make AEVUM_CUDA_ROOT=/custom/cuda	Explicit SDK location; advanced overrides AEVUM_CUDA_LIBS and AEVUM_CUDA_FLAGS also supported
make clean-all	Clean compiled host, OpenCL and CUDA build outputs

The CUDA plugin is compiled independently in third_party/aevum/build-engine-cuda/, leaving OpenCL's objects untouched. Re-running make with no source changes is incremental: CUDA will not be rebuilt from scratch unnecessarily. The detector supports NVIDIA SDK driver stubs and Kaggle-style libcuda.so.1 driver libraries.

AEVUM_CUDA_MODE=off changes what is built, not which existing plugin can run. If a CUDA plugin was already built, it may remain in the output folder; to force OpenCL at runtime set AEVUM_BACKEND=opencl. To inspect the Aevum backend explicitly:

AEVUM_BACKEND=auto ./prmers 136279841 -aevum
AEVUM_BACKEND=opencl ./prmers 136279841 -aevum

The logs identify backend=CUDA or backend=OpenCL and the actual FFT plan=. No option is necessary for ordinary automatic use.

Other build system: CMake (Windows / vcpkg)

The alternative CMake route currently builds the PrMers host executable and its regular OpenCL dependencies; it does not yet provide the same automatic Aevum CUDA/OpenCL dual-plugin construction as the Makefile. Use MSYS2 UCRT64 make for the unified source-build behavior.

git clone https://github.com/cherubrock-seb/PrMers.git
cd PrMers
git clone https://github.com/microsoft/vcpkg.git
.\vcpkg\bootstrap-vcpkg.bat
cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=./vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release

Make sure the required vcpkg dependencies are installed, and copy any required runtime DLLs alongside prmers.exe or add their folder to PATH.

Strict backend requests in v99.9

-aevum is now strict: when the requested exponent has no admissible FFT3161 plan, PrMers exits with code 2 instead of silently running Marin. Automatic mode continues to choose Marin normally in that situation. For example, M216091 is below the native FFT3161 range, while M1362763 can be used to exercise the forced Aevum LL paths.

The legacy internal NTT option -marin is rejected for Lucas-Lehmer, whether the LL run comes from -llunsafe or from a worktodo Test= entry, because that historical path is not validated. Use automatic mode, -engine-marin, or -aevum. To run it on purpose anyway (for example for regression testing), add -allow-unvalidated-legacy-ll, on the command line or in settings.cfg; a warning is printed. The one-register -pm1-ultralowmem path remains Marin-only and an explicit -aevum request is rejected before OpenCL and transform allocation.

Backend validation matrix (v99.9)

The automatic policy remains active for PRP, all Lucas-Lehmer engine paths, normal P-1, 3-register P-1 low-memory, and ECM. Aevum is selected when its FFT3161 transform meets the workload ratio threshold. The historical one-register -pm1-ultralowmem algorithm is the only explicit Marin-only compatibility case because it encodes multiply-by-3 through Marin fast3; forced -aevum is rejected cleanly before plugin allocation.

The tiny Marin radix-4 kernel used by transforms of 16 to 80 words is fixed in v99.8. This repairs small P-1 low-memory and ECM examples such as M367 and M701.

Run the exhaustive cross-backend validation and create a single report archive:

PRMERS_TEST_DEVICE=0 PRMERS_MATRIX_PROFILE=standard make test-backend-matrix

Profiles are quick, standard, and full. The script covers Auto, forced Aevum, forced Marin, and the internal NTT path across PRP, LL-safe, LL-unsafe, LL-safe2, normal/low/ultra-low-memory P-1, and Edwards/Montgomery ECM. ECM uses a fixed seed so Aevum and Marin execute the same curve. The full profile adds complete medium-size Aevum/Marin pairs and compares their final JSON status, residues or factors as well as measured throughput.

PRMERS_TEST_DEVICE=0 PRMERS_MATRIX_PROFILE=full \
PRMERS_MATRIX_COMPLETE_SECONDS=1200 make test-backend-matrix

To rerun only selected cases, use a regular-expression filter:

PRMERS_MATRIX_CASE_FILTER='ll-safe|pm1-lowmem|ecm-medium' \
PRMERS_MATRIX_PROFILE=full ./tests/run_backend_validation_matrix.sh 0 full

The script writes tests/backend-validation-<timestamp>.tar.gz and a matching SHA-256 file. The archive contains every command and log plus summary.tsv, comparisons.tsv, errors.tsv, system.txt, combined.log, and report-manifest.txt.

Command line options

Run the built-in help for the exact option list supported by your binary:

./prmers -h

General options

Option	Meaning
<p>	Exponent for 2^p - 1, unless -worktodo supplies it
-d <id>	OpenCL device id, default 0
-c <depth>	Local carry propagation depth
-t <seconds>	Checkpoint interval
-f <path>	Checkpoint and state directory
-config <path>	Read options from a config file
-worktodo [path]	Read assignment from worktodo.txt
-profile	Enable kernel profiling
-debug	Verbose debug output
-bench	Run benchmark over supported transform sizes
-v, --version	Print version
-h, --help	Print help

Device and stability options

Option	Meaning
-iterforce <n>	Force GPU queue synchronization every n iterations
-iterforce2 <n>	Force queue synchronization in P-1 Stage 2
-memtest	Run GPU memory and stability test
-memlim <percent>	Limit memory used by some precompute paths
-maxe <MiB>	Maximum P-1 exponent chunk size in MiB (at most 8192)
-res64_display_interval <n>	Print Res64 every n iterations in Marin mode

Mode selection

Option	Meaning
-prp	PRP mode, default
-ll	Lucas-Lehmer safe mode with Gerbicz-Li style checks
-llunsafe	Classic Lucas-Lehmer mode without error checking
-llsafe2	Lucas-Lehmer block-doubling safe mode
-wagstaff	Test W = (2^p + 1) / 3
-pm1	P-1 factoring mode
-ecm	ECM factoring mode
-aevum	Force the Aevum engine::Reg backend; PRP/LL use automatic PFA selection
-engine-marin	Force the Marin engine::Reg backend
-aevum-auto	Explicitly request the normal auto policy; macOS still keeps Marin unless -aevum is used
-marin	Legacy option: use the internal PrMers NTT path
-allow-unvalidated-legacy-ll	Let -marin run Lucas-Lehmer (command line or worktodo); that path is not validated for LL, so a warning is printed

Automatic Marin/Aevum selection is the default on Linux and Windows. macOS defaults to Marin; use -aevum for an explicit Aevum opt-in.

Automatic selection compares the native transform sizes for every engine creation. PRP/LL and multi-register P-1 accept Aevum when its transform is no larger than Marin. P-1 Stage 1 and ECM require a clearer advantage (Aevum / Marin <= 0.75 by default). Thus M136279841 P-1 Stage 1 selects Aevum automatically: its FFT3161 transform is 4M words versus 8M for Marin, matching the measured Radeon VII advantage. A forced Aevum Stage 1 uses the generic square plus prepared base-3 multiplication path instead of the Marin-specific fast3 shortcut. -pm1-ultralowmem remains Marin-only because its one-register algorithm depends on fast3. Stage 1 checkpoints are tagged with their arithmetic backend; incompatible checkpoints are ignored safely.

PRP and proof options

Option	Meaning
-proof <level>	Proof power, 1 to 12, or 0 to disable proof generation
-noverify	Skip verification of generated PRP proof
-factors <f1,f2,...>	Test the remaining cofactor after known Mersenne factors
-gerbiczli	Disable Gerbicz-Li checks, mainly for benchmarking
-checklevel <k>	Tune Gerbicz-Li check frequency
-erroriter <i>	Inject an error at iteration i to test recovery

Lucas-Lehmer options

Option	Meaning
-ll	Safe LL mode
-llunsafe	Fast classic LL mode, no error checking
-llsafe2	Block-doubling safe LL mode
-llsafeb <B>	Override block size for -llsafe2

P-1 options

Option	Meaning
-pm1	Enable P-1 factoring
-b1 <B1>	Stage 1 bound
-b2 <B2>	Stage 2 bound
-pm1-progress-seconds <0..86400>	Periodic Stage 1/2 progress logging interval, default 300 s; 0 suppresses progress lines only (not checkpoints or integrity checks)
-pm1-no-progress-seconds <0..86400>	Opt-in V-trace Stage-2 no-progress watchdog, default 0 (disabled). On timeout it reports the active phase and exits with code 124 without attempting to overwrite the last verified checkpoint; choose a value comfortably above the longest expected GPU/setup operation.
-pm1-vtrace	Use scalar-trace P-1 Stage 2. This is the default for normal-memory Stage 2, with conservative auto-D
-pm1-vtrace-off	Disable scalar-trace V-trace; use the older modular-power baby-step/giant-step algorithm inside PrMers (not a Prime95 delegation)
-pm1-vtrace-pair95	Enable the Pair95 prime-pairing planner for V-trace Stage 2 when supported by the build
-pm1-vtrace-pair95-off	Disable Pair95 and use the ordinary V-trace prime-pairing planner
-pm1-vtrace-pair95-l <L>	Set the Pair95 irregular-unit count, for example 2 or 3
-pm1-vtrace-d <D>	Force the V-trace giant-step parameter D, for example 4620, 13860, or 30030
-pm1-vtrace-auto-d	Explicitly auto-select D for V-trace under a conservative register cap
-pm1-vtrace-auto-d-aggressive	Auto-select D with a larger register cap for normal-size Mersennes
-pm1-vtrace-max-regs <N>	Register cap used by V-trace auto-D
-pm1-vtrace-auto-batch	Explicitly enable integrated V-trace D plus baby-batch selection. This is the default in current normal-memory V-trace builds
-pm1-vtrace-no-auto-batch	Disable automatic V-trace baby batching and keep the full baby table for the selected D, using segmented GPU memory if needed
-pm1-vtrace-baby-batch <N>	Force the number of active baby traces kept per Stage 2 pass. If N covers all baby residues, no batching is used
-pm1-vtrace-max-batches <N>	Maximum number of baby-window passes considered by V-trace auto-batching
-pm1-vtrace-negadd-off	Disable the negative-baby trace optimization and use the older copy/subtract path for comparison
-b1old <B1old>	Extend Stage 1 from an existing .save or .p95 file
-resume	Write GMP-ECM .save and Prime95 .p95 resume files
-p95	Write Prime95 .p95 resume file
-p95path <path>	Delegate P-1 Stage 2 to Prime95 or mprime
-nop95stage2	Disable Prime95 Stage 2 handoff even if -p95path is set
-filemers <path>	Convert a .mers state to GMP-ECM .save
-K <K>	Enable the n^K Stage 2 variant
-nmax <n>	Upper bound for the n^K variant
-pm1-lowmem	P-1 low-memory mode, fewer GPU registers
-pm1-ultralowmem	P-1 ultra-low-memory mode, 1-register Stage 1 and 1-register product-exponent Stage 2
-nogcd-stage1	Skip ordinary Stage 1 GCD after writing resume data, useful before Stage 2

ECM options

Option	Meaning
-ecm	Enable ECM mode
-b1 <B1>	ECM Stage 1 bound
-b2 <B2>	ECM Stage 2 bound
-K <curves>	Number of curves
-montgomery	Use Montgomery curve model
-edwards	Use Edwards curve setup
-ced	Compute directly in Twisted Edwards coordinates
-cmont	Compute in Montgomery coordinates
-torsion8	Use torsion-8 family
-torsion16	Use torsion-16 family
-notorsion	Disable torsion family
-iv163	Use family IV 163 curves
-seed <value>	Force curve seed
-sigma <value>	Force Montgomery sigma
-ecm_check_interval <seconds>	ECM error-check interval
-ecm_progress_ms <ms>	ECM progress update interval
-p95path <path>	Delegate ECM Stage 2 to Prime95 or mprime

Web GUI options

Option	Meaning
-gui	Enable embedded web GUI
-http <port>	HTTP port, default 3131
-host <ip>	HTTP host, default localhost

PRP and proof generation

Default PRP mode tests 2^p - 1 using GPU modular exponentiation and Gerbicz-Li style checking. Results are written to results.txt and to a JSON result file.

Example:

./prmers 136279841

Useful files include:

File	Purpose
results.txt	Human-readable result history
<p>_prp_result.json	JSON result for automation
proof/<p>-<power>.proof	Optional PRP proof output depending on proof settings
<p>/proof/	Proof residues, checkpoint data kept while the test runs and deleted when the result and the proof are done

The result files, the proof and its residues are all kept under the -f <path> directory (the current directory when -f is not given). A run resumed after an upgrade still uses residues an older version left in <p>/proof under the working directory, reads them where they are, and deletes them from there at the end.

Cofactor PRP:

./prmers 10449497 -factors 62696983

Lucas-Lehmer modes

PrMers implements three GPU LL variants.

Mode	Option	Safety	Notes
LL safe	-ll	Gerbicz-Li style checking	Recommended safe LL mode
LL classic	-llunsafe	No checking	Fast, for quick checks and debugging
LL safe2	-llsafe2	Block-doubling checks	Lighter safe mode with block verification

Safe LL uses the split representation s = a + b*sqrt(3) and checks progress periodically. -llunsafe uses the classic recurrence S_{i+1} = S_i^2 - 2 and should not be used for production runs on unstable hardware.

P-1 factoring

For a factor q of M_p = 2^p - 1, factors have the form:

q = 2*k*p + 1

Stage 1

Stage 1 computes:

x = 3^(E(B1)*2*p) mod M_p

where E(B1) is the product of prime powers up to B1. Then it tests:

gcd(x - 1, M_p)

Example:

./prmers 541 -pm1 -b1 8099

Write resume files:

./prmers 541 -pm1 -b1 8099 -resume
./prmers 541 -pm1 -b1 8099 -p95

Extend from an older Stage 1 bound:

./prmers 541 -pm1 -b1 20000 -b1old 8099

Stage 2

Standard Stage 2 extends the search from B1 to B2.

./prmers 367 -pm1 -b1 11981 -b2 38971

For normal-memory P-1, Stage 2 uses the V-trace path by default. Let H be the Stage 1 result. Instead of accumulating one term per prime with powers of H, V-trace works with the scalar trace:

V_n = H^n + H^(-n) mod M_p

For a giant step kD and baby step j, the difference

V_(kD) - V_j

covers both kD - j and kD + j, because it contains the factors (H^(kD-j)-1) and (H^(kD+j)-1) up to multiplication by an invertible term. This gives a compact baby/giant Stage 2 using one scalar residue per baby trace. By default PrMers uses automatic D selection and, when useful, automatic baby batching. D can also be forced explicitly with -pm1-vtrace-d.

Examples:

./prmers 1362763 -pm1 -b1 29 -b2 6910159 -nogcd-stage1 \
  -factors 46333943,282345414919

./prmers 1362763 -pm1 -b1 29 -b2 6910159 -nogcd-stage1 \
  -factors 46333943,282345414919 -pm1-vtrace-d 30030

Expected factor for this regression test:

28401397572100073

Pair95 prime pairing

Some builds include a Pair95 planner for V-trace Stage 2, inspired by the prime-pairing method described by Atnashev and Woltman. It extends the ordinary kD ± j pairing by allowing irregular precomputed units such as unit, unit + D, unit + 3D, unit + 7D, and so on. This is a Stage 2 planning and coverage option; it does not change the underlying Marin modular arithmetic.

Pair95 can be selected explicitly with -pm1-vtrace-pair95, disabled with -pm1-vtrace-pair95-off, and tuned with -pm1-vtrace-pair95-l <L>. When Pair95 is enabled, D and the baby-window size can still be forced with -pm1-vtrace-d <D> and -pm1-vtrace-baby-batch <N>.

V-trace D, baby residues and batching

For a selected giant-step parameter D, the V-trace path stores one baby trace for each odd residue j <= D/2 with gcd(j,D)=1. The number of baby traces is therefore:

m(D) = phi(D) / 2

If all m(D) baby traces fit efficiently, Stage 2 can run in one pass. If only b active baby traces are kept in GPU memory, PrMers splits the baby table into:

P = ceil(m(D) / b)

baby-window passes.

A useful first-order cost model is:

Cost(D,b) ~= A * (P * (B2-B1) / D)
           + C * prime_terms
           + E * baby_precompute
           + batch_overhead

The important term for the giant recurrence is P/D, not just D. This is why two different settings can have similar runtime. For example, if B = B2-B1:

D = 630:   phi(D)/2 = 72,  b = 72, P = 1  -> P/D = 1/630
D = 1260:  phi(D)/2 = 144, b = 72, P = 2  -> P/D = 2/1260 = 1/630
D = 2310:  phi(D)/2 = 240, b = 72, P = 4  -> P/D = 4/2310

D=2310 may show a much higher p/s because each pass covers only a subset of residues and skips many primes quickly. The more useful comparison is usually term/s and the final ETA.

Examples:

# Let PrMers choose D and the baby-window batch size.
./prmers 205271257 -pm1 -b1 1301000 -b2 250000000

# Force D and keep all 72 baby residues for D=630.
./prmers 205271257 -pm1 -b1 1301000 -b2 250000000 \
  -pm1-vtrace-d 630 -pm1-vtrace-baby-batch 72

# Force D=2310 and keep 72 active baby traces per pass.
./prmers 205271257 -pm1 -b1 1301000 -b2 250000000 \
  -pm1-vtrace-d 2310 -pm1-vtrace-baby-batch 72

Use -pm1-vtrace-no-auto-batch when you want to force a full baby table for the selected D and compare it against the automatic batching choice.

Segmented GPU register space

On some OpenCL drivers, especially NVIDIA, a single cl_mem buffer can be limited by CL_DEVICE_MAX_MEM_ALLOC_SIZE, often much smaller than total VRAM. Recent PrMers builds can split the Marin register slab into several GPU-only OpenCL buffers when the logical register space is larger than one OpenCL allocation but still fits in total VRAM.

This segmented register space is used automatically by normal-memory V-trace Stage 2 when needed. It is not host-backed swapping: the hot loop remains GPU-only. With PRMERS_GPU_ALLOC_DIAG=1, the log reports both the logical register slab and the segmented allocation plan, for example:

[MARIN-SEGMENTED] logical regs=86 reg slab=6.72 GiB exceeds OpenCL max single allocation=2.41 GiB.
[MARIN-SEGMENTED] using 4 GPU-only cl_mem segment(s), ... no host backing in hot loop.

Useful environment variables for debugging:

Variable	Meaning
PRMERS_GPU_ALLOC_DIAG=1	Print GPU memory planning and allocation diagnostics
PRMERS_PM1_VTRACE_BABY_BATCH=<N>	Force V-trace active baby traces per pass, same purpose as -pm1-vtrace-baby-batch <N>
PRMERS_PM1_VTRACE_PAIRING95=1	Enable Pair95 prime-pairing in builds where it is available
PRMERS_PM1_VTRACE_PAIRING95_DISABLE=1	Disable Pair95 and use the ordinary V-trace planner
PRMERS_PM1_VTRACE_PAIRING95_L=<L>	Set the Pair95 irregular-unit count
PRMERS_PM1_VTRACE_NO_AUTO_BATCH=1	Disable V-trace auto-batching
PRMERS_MARIN_SEGMENTED_DISABLE=1	Disable segmented register space and require a single flat register buffer
PRMERS_MARIN_SEGMENTED_MAXALLOC_FRAC=<f>	Fraction of CL_DEVICE_MAX_MEM_ALLOC_SIZE used when sizing each segment
PRMERS_MARIN_SEGMENTED_SCRATCH_REGS=<N>	Scratch registers reserved per segment for cross-segment operations

When benchmarking the internal V-trace path, do not set -p95path: that option delegates P-1 Stage 2 to Prime95 or mprime.

V-trace Stage 2 checkpoints are compact: they save the accumulator and the current giant recurrence state, and rebuild deterministic baby tables on resume instead of writing the full baby table to disk.

To force the previous classic Stage 2 path, add:

-pm1-vtrace-off

The classic Stage 2 path uses GPU precomputation and prime sweeps. The n^K variant can be enabled with:

./prmers 367 -pm1 -b1 11981 -b2 38971 -K 8 -nmax 200000

Ultra-low-memory P-1

-pm1-ultralowmem is designed for huge transforms where a normal multi-register Stage 2 does not fit in VRAM.

Current behavior:

Stage	Method
Stage 1	1 GPU register, fast3 path, Gerbicz-Li disabled
Stage 2	1 GPU register, product-exponent path

The Stage 2 ultra-low-memory path computes the product of Stage 2 primes into the exponent and runs one direct GPU exponentiation:

3^(E(B1)*2*p*product_primes(B1,B2]) mod M_p

It then tests gcd(x - 1, M_p). This is slower than a full-memory BSGS-style Stage 2, but it fits on GPUs where a 2-register or table-based Stage 2 does not fit.

MM31 validation example:

./prmers 2147483647 -pm1 -b1 100 -b2 5000 -pm1-ultralowmem -nogcd-stage1

Expected known factor:

295257526626031

ECM factoring

Basic ECM:

./prmers p -ecm -b1 B1 -b2 B2 -K curves

Examples:

./prmers 701 -ecm -b1 6000 -K 8
./prmers 701 -ecm -b1 6000 -b2 33333 -K 8

Curve and arithmetic options include Montgomery, Edwards, torsion variants, seeds and sigma values. Use ./prmers -h for the exact list supported by your build.

Exit codes

Code	Meaning
0	The requested work finished.
1	The run was stopped before it finished (Ctrl-C / SIGINT, or SIGTERM / SIGHUP, which stop a run the same way). If the work was not finished, the checkpoint was saved and the worktodo entry is still queued, so the same command resumes where it stopped. If the stop arrived after the result was already saved, the result is recorded and the bookkeeping is finished as for a normal run (the entry is archived to worktodo_save.txt, the checkpoint and proof residues are deleted), but the next worktodo entry is not started; the exit code is still 1. Every mode (PRP, LL, LL-safe, P-1, ECM, Gaussian-Mersenne, GMCHAIN, GMTF, bench, memtest) uses this code; P-1 stage 2 and memtest already did. In -gui mode Stop is the normal way to quit and the exit code is unchanged.
1 (also)	Gaussian-Mersenne modes also use 1 as a result code (composite or no factor).
2	General errors and the Gaussian-Mersenne error result.

An exit status of 1 therefore means either "stopped" or, in the Gaussian-Mersenne modes, "finished with composite / no factor". The exit status alone cannot tell them apart: a script that needs to know must check the log output or the results file (a run stopped before it finished leaves its worktodo entry queued, a finished one, stopped or not, archives it to worktodo_save.txt).

worktodo.txt and AutoPrimeNet

PrMers can read GIMPS-style worktodo.txt assignments.

./prmers -worktodo
./prmers -worktodo ./worktodo.txt

A finished entry is removed from the worktodo file and appended to worktodo_save.txt in the same directory as that worktodo file (the current directory when -worktodo has no directory part).

PRP format

PRP=AID,k,b,n,c,tf_bits,tests_saved

Example:

PRP=DEADBEEFCAFEBABEDEADBEEFCAFEBABE,1,2,197493337,-1,76,0

Pminus1 format

Prime95-compatible P-1 format:

Pminus1=k,b,n,c,B1,B2[,how_far_factored][,B2_start][,"factors"]
Pminus1=AID,k,b,n,c,B1,B2[,how_far_factored][,B2_start][,"factors"]

Examples:

Pminus1=AID,1,2,160575647,-1,900000,32000000
Pminus1=AID,1,2,160575647,-1,900000,32000000,79
Pminus1=AID,1,2,160575647,-1,900000,32000000,79,5000000
Pminus1=AID,1,2,11,-1,100,200,79,"23"

The parser keeps these fields separate:

Field	Meaning
how_far_factored	Trial factoring depth, for example 79 means TF completed to 2^79
B2_start	Optional Stage 2 start bound
"factors"	Quoted known-factor list

So the trailing 79 in this line is not a known factor:

Pminus1=AID,1,2,160575647,-1,900000,32000000,79

It is interpreted as trial factoring completed to 2^79.

AutoPrimeNet

AutoPrimeNet can fetch assignments, monitor progress and submit results.

Project:

https://github.com/tdulcet/AutoPrimeNet

Windows:

autoprimenet.exe --setup
autoprimenet.exe
prmers.exe -worktodo worktodo.txt

Linux or macOS:

python3 autoprimenet.py --setup
python3 -OO autoprimenet.py
./prmers -worktodo worktodo.txt

For multiple GPUs or workers, use one working directory per worker.

Prime95 and mprime interop

P-1 result records and progress logs

For a Pminus1 worktodo entry with B2 > B1, PrMers treats Stage 1 as intermediate work: successful Stage 1 by itself does not submit an NF result. A completed Stage 2 publishes the single two-stage result with both bounds. If Stage 2 is interrupted or fails, its checkpoint and the worktodo entry remain for a retry, with no new partial NF submission. If a new factor is found in Stage 1, Stage 2 is intentionally skipped by default and a Stage-1 factor result is submitted; -pm1-continue-stage2-after-factor overrides that policy. A job with B2 <= B1 is Stage-1-only.

Progress lines for P-1 Stage 1 and Stage 2 include local date/time, stage, and exponent. To emit diagnostics every 10 minutes, or suppress only periodic progress while retaining checkpoints and integrity checks:

prmers.exe -worktodo worktodo.txt -pm1-progress-seconds 600
prmers.exe -worktodo worktodo.txt -pm1-progress-seconds 0

The default is 300 seconds (formerly 3 seconds for some Stage-2 loops and 10 seconds for Stage 1). The log is much smaller; an enabled progress message is a newline-terminated record rather than a carriage-return screen update.

For comparison, -pm1-vtrace-off selects the classic internal BSGS Stage-2 implementation, not Prime95. To delegate P-1 Stage 2 to Prime95 or mprime instead, use -p95path <path> (example below). The correct choice depends on hardware and bounds; no automatic performance equivalence with Prime95 is implied.

Operational caution: This change prevents routine duplicate intermediate Stage-1 reports, but does not retroactively fix historical result files or guarantee transactional exactly-once reporting if power is lost precisely between writing results.txt and retiring a worktodo line. Such a failure must still be reconciled against the assignment and submission server.

P-1 Stage 2 handoff

PrMers can run P-1 Stage 1 and let Prime95 or mprime run Stage 2.

./prmers 75931 -pm1 -b1 100 -b2 200000000 -p95path /home/sebastien/gimps/v31_31.04_b05c

Windows:

prmers.exe 75931 -pm1 -b1 100 -b2 200000000 -p95path C:\gimps\v31_31.04_b05c

What happens:

1. PrMers runs P-1 Stage 1.
2. PrMers writes a Prime95 Stage 1 state file.
3. PrMers copies it as mXXXXXXX in the Prime95 directory.
4. PrMers writes a Pminus1 line to Prime95 worktodo.txt.
5. Prime95 or mprime runs Stage 2.
6. PrMers reads results.json.txt and reports NF or F.

Example Prime95 line:

Pminus1=1,2,75931,-1,100,200000000,68

With known factors:

Pminus1=1,2,10449497,-1,1440000,1440000,68,"62696983"

ECM Stage 2 handoff

PrMers can run ECM Stage 1 and let Prime95 or mprime run ECM Stage 2.

./prmers 757 -ecm -b1 97 -b2 9500 -K 15 -p95path /home/sebastien/gimps/v31_31.04_b05c

Example Prime95 line:

ECMSTAGE2=N/A,1,2,757,-1,"resume_p757_ECM_TE_B1_97_c000006.p95",9500

Web GUI

Start the GUI:

./prmers -gui -http 3131

Common options:

./prmers -gui -host 127.0.0.1 -http 3131
./prmers -gui -host 0.0.0.0 -http 3131

The GUI can monitor progress, show logs, inspect results and help edit worktodo.txt. It now also displays the configured backend mode, the active backend, workload, Marin/Aevum transform sizes, the FFT3161 plan and the reason for the automatic decision. ECM initialization, Stage 1 and Stage 2 update the main progress bar. The settings editor can select Auto, forced Aevum, forced Marin or the internal PrMers NTT path, and can generate ECM work entries.

Example with backend telemetry:

./prmers 136279841 -pm1 -b1 1000000 -gui -http 3131 -d 0 --noask

Open the printed URL and look at the Computation engine card. For this case the expected decision is Auto -> Aevum, with Aevum 4M words versus Marin 8M words.

GPU memory test

./prmers -memtest
./prmers -memtest -d 1

The memory test scans GPU VRAM with several patterns and reports bandwidth, coverage and errors.

NTT and IBDWT transform sizes

For a given exponent p, PrMers chooses an NTT/IBDWT size N:

Exponent p range	N	Structure
3-113	4	2^2
127-239	8	2^3
241-463	16	2^4
467-919	32	2^5
929-1153	40	5*2^3
1163-1789	64	2^6
1801-2239	80	5*2^4
2243-3583	128	2^7
3593-4463	160	5*2^5
4481-6911	256	2^8
6917-8629	320	5*2^6
8641-13807	512	2^9
13829-17257	640	5*2^7
17291-26597	1024	2^10
26627-33247	1280	5*2^8
33287-53239	2048	2^11
53267-66553	2560	5*2^9
66569-102397	4096	2^12
102407-127997	5120	5*2^10
128021-204797	8192	2^13
204803-255989	10240	5*2^11
256019-393209	16384	2^14
393241-491503	20480	5*2^12
491527-786431	32768	2^15
786433-982981	40960	5*2^13
983063-1507321	65536	2^16
1507369-1884133	81920	5*2^14
1884193-3014653	131072	2^17
3014659-3768311	163840	5*2^15
3768341-5767129	262144	2^18
5767169-7208951	327680	5*2^16
7208977-11534329	524288	2^19
11534351-14417881	655360	5*2^17
14417927-22020091	1048576	2^20
22020127-27525109	1310720	5*2^18
27525131-44040187	2097152	2^21
44040253-55050217	2621440	5*2^19
55050253-83886053	4194304	2^22
83886091-104857589	5242880	5*2^20
104857601-167772107	8388608	2^23
167772161-209715199	10485760	5*2^21
209715263-318767093	16777216	2^24
318767107-398458859	20971520	5*2^22
398458889-637534199	33554432	2^25
637534277-796917757	41943040	5*2^23
796917763-1207959503	67108864	2^26
1207959559-1509949421	83886080	5*2^24
1509949440 and above, including MM31	167772160	5*2^25

Note: for MM31 (p = 2147483647), the valid Marin transform size is 167772160 = 5*2^25. Pure 2^27 is not valid for the Goldilocks root layout used here.

Native PFA radix-3 and radix-9

Aevum can use a Good-Thomas prime-factor layout with a transform length N = r * 2^m, where r is 3 or 9. The power-of-two rows keep the existing half-real GF(M31^2) x GF(M61^2) path, while a small odd-axis transform is applied before and after the row transforms. The inverse stage writes directly to the canonical Aevum carry layout, so there is no separate unpack pass.

For PRP and Lucas-Lehmer work, Aevum now evaluates this path automatically. Radix 3 or radix 9 is selected when the actual Aevum stock/PFA size ratio reaches its validated threshold; otherwise the normal power-of-two plan is retained. On macOS, Marin remains the platform default, but an explicit -aevum request uses the same PFA selector.

./prmers 175000001 -aevum          # automatic PFA/stock choice
./prmers 175000001 -aevum -pfa 9   # force radix 9
./prmers 175000001 -aevum -pfa-off # force the stock Aevum plan

Native PFA automatic selection ranges

The table below is the current default pfa:auto policy with the normal fftOverdrive = 1.0. The limits are exponent values p for M_p = 2^p - 1. They are checked by the plan-policy test at the exact boundaries.

Automatic plan	Exponent range p	Selected Aevum plan	Transform words	Stock/PFA ratio
Radix 3	10,627,319–15,724,707	pfa3:1:256:3:256:101	393,216	1.333x
Radix 3	21,071,135–31,284,264	pfa3:1:256:3:512:101	786,432	1.333x
Radix 9	41,922,069–46,560,704	pfa9:1:256:9:256:202	1,179,648	1.778x
Radix 3	46,560,705–62,080,936	pfa3:1:512:3:512:101	1,572,864	1.333x
Radix 9	83,194,017–92,625,960	pfa9:1:256:9:512:202	2,359,296	1.778x
Radix 3	92,625,961–123,343,992	pfa3:1:512:3:1K:101	3,145,728	1.333x
Radix 9	165,507,233–183,789,168	pfa9:1:512:9:512:202	4,718,592	1.778x
Radix 3	183,789,169–244,737,648	pfa3:1:1K:3:1K:101	6,291,456	1.333x
Radix 9	328,414,017–365,879,616	pfa9:1:512:9:1K:202	9,437,184	1.778x
Radix 3	365,879,617–487,210,368	pfa3:1:4K:3:512:101	12,582,912	1.333x
Radix 9	653,808,129–725,153,152	pfa9:1:1K:9:1K:202	18,874,368	1.778x
Radix 3	725,153,153–965,612,672	pfa3:1:4K:3:1K:101	25,165,824	1.333x
Radix 9	1,295,872,129–1,440,869,120	pfa9:1:4K:9:512:202	37,748,736	1.778x
Radix 9	2,574,967,041–2,862,863,872	pfa9:1:4K:9:1K:202	75,497,472	1.778x

All other admissible exponent ranges use the normal power-of-two Aevum plan. The automatic gates are 1.30x for radix 3 and 1.60x for radix 9. The explicit radix options remain available for validation and benchmarking.

Force-adaptive FFT type 4 + PFA9 in v99.73

At p=175000039, both type 1 and type 4 use the same 4.50M-word PFA9 transform. A full type 4 therefore adds an FP32 transform without reducing the transform length. The measured result was about 612 IPS, versus about 770 IPS for the exact paired-NTT plan.

Every ordinary type-4 request is now capacity-aware, including an explicit -aevum-fft pfa9:4:... plan:

./prmers 175000039 -d 1 -pfa9-type4 -proof 0
# Equivalent explicit request:
./prmers 175000039 -d 1 -aevum-fft pfa9:4:512:9:512:202 -proof 0

It requests the type-4 shape, checks the exact FFT3161 limit, and elides the FP32 plane only when GF31+GF61 is still safe. At 175M, 37.09 bpw is below the 38.95-bpw paired-NTT limit, so this executes the fast exact plan:

pfa9:1:512:9:512:202

The real three-plane diagnostic path remains available and enables concurrent OpenCL queues by default:

./prmers 175000039 -d 1 -pfa9-type4-full -proof 0

The true three-plane plan is spelled pfa9full:4:512:9:512:202; it is validated word-for-word against GMP on dense random residues at 42.4 bits/word (third_party/aevum/scripts/test_type4_pfa9_ubuntu.sh). Use AEVUM_TYPE4_MULTI_Q=0 to reproduce the old single-queue baseline. Run all four comparisons with:

./scripts/test_type4_optimized_ubuntu.sh 1 180 175000039

The full path remains useful above the paired-NTT BPW limit; the adaptive path never elides FP32 unless the exact two-prime capacity test passes.

Benchmarks

• -bench runs the original benchmark across supported NTT transform sizes; its behavior is unchanged.
• -bench2 benchmarks the production PRP path with automatic backend and FFT-plan selection. It supports quick (default), standard, dense, and full modes, resumes completed points, and writes text, JSON, JSONL, and CSV results.

./prmers -bench2 -bench2-mode quick -d 0

Use -bench2-out <path> to choose the output directory. See GPU benchmarks for details.

Performance depends on GPU, clocks, power limits, OpenCL driver, thermal behavior and PrMers version. Treat the following values as rough guidance.

Mersenne Forum discussion:

https://www.mersenneforum.org/node/1086124/page3

Backend and code

• PrMers and its integrated algorithms
  • https://github.com/cherubrock-seb/PrMers
  • developed by cherubrock-seb
• Marin register engine and integer IBDWT backend
  • https://github.com/galloty/marin
  • written by Yves Gallot
  • MIT licensed
• Aevum register engine
  • intended repository: https://github.com/cherubrock-seb/aevum-engine
  • modified derivative of GPUOwl/PRPLL
  • exposes GF(M31^2) x GF(M61^2) arithmetic through a shared C API and a PrMers engine::Reg adapter
• GPUOwl/PRPLL lineage
  • original GPUOwl: https://github.com/preda/gpuowl by Mihai Preda
  • imported fork: https://github.com/gwoltman/gpuowl by George Woltman
  • imported commit: 294cc485ac8cf53c8b69144a3039832eda573849
• Gerbicz-Li proof scheme
  • used for PRP error checking and safe long exponentiation workflows

Related inspiration

• GPUOwl by Mihai Preda
  • https://github.com/preda/gpuowl
• GPUOwl/PRPLL fork and NTT work by George Woltman
  • https://github.com/gwoltman/gpuowl
• Genefer22 by Yves Gallot
  • https://github.com/galloty/genefer22
• Marin by Yves Gallot
  • https://github.com/galloty/marin
• GIMPS and the Mersenne Forum community
  • https://www.mersenne.org/
  • https://www.mersenneforum.org/
• GMP-ECM
  • https://gitlab.inria.fr/zimmerma/ecm
• Yves Gallot repositories
  • https://github.com/galloty
  • https://github.com/galloty/f12ecm
  • https://github.com/galloty/FastMultiplication
• Nick Craig-Wood work
  • IOCCC 2012 entry: https://github.com/ncw/ioccc2012
  • GitHub: https://github.com/ncw/
  • ARM Prime Math: https://www.craig-wood.com/nick/armprime/math/

Must read papers

Multiplication by FFT and weighted transforms

Discrete Weighted Transforms and Large Integer Arithmetic
Richard Crandall and Barry Fagin, 1994
https://www.ams.org/journals/mcom/1994-62-205/S0025-5718-1994-1185244-1/S0025-5718-1994-1185244-1.pdf

Rapid Multiplication Modulo the Sum And Difference of Highly Composite Numbers
Colin Percival, 2002
https://www.daemonology.net/papers/fft.pdf

P-1 factoring

An FFT Extension to the P-1 Factoring Algorithm
Peter L. Montgomery and Robert D. Silverman, 1990
https://www.ams.org/journals/mcom/1990-54-190/S0025-5718-1990-1011444-3/S0025-5718-1990-1011444-3.pdf

Improved Stage 2 to P+/-1 Factoring Algorithms
Peter L. Montgomery and Alexander Kruppa, 2008
https://inria.hal.science/inria-00188192v3/document

Prime pairing in algorithms searching for smooth group order
Pavel Atnashev and George Woltman, 2021
https://eprint.iacr.org/2021/1462.pdf

Proof schemes

An Efficient Modular Exponentiation Proof Scheme
Darren Li and Yves Gallot, 2022-2023
https://arxiv.org/abs/2209.15623

The paper describes a proof scheme for left-to-right modular exponentiation, generalizing the Gerbicz-Pietrzak approach to arbitrary exponents. It is relevant to long PRP runs and validation of large modular exponentiations.

Aevum arithmetic backend

PrMers can load Aevum as an in-process arithmetic plugin for PRP, LL, P-1 and ECM:

make
./prmers 136279841 -prp -proof 0 -d 0 --noask

The command above uses automatic backend selection. Explicit choices are available with -aevum, -engine-marin and -aevum-auto.

Default workload thresholds:

Workload	Default maximum Aevum / Marin transform ratio
PRP / LL	1.00
P-1 Stage 1 (up to 16 registers)	0.75
P-1 Stage 2 / multi-register	1.00
ECM (51 registers)	0.75

The global threshold can be changed with AEVUM_AUTO_MAX_RATIO. Workload-specific variables are AEVUM_AUTO_PRP_MAX_RATIO, AEVUM_AUTO_LL_MAX_RATIO, AEVUM_AUTO_PM1_STAGE1_MAX_RATIO, AEVUM_AUTO_PM1_STAGE2_MAX_RATIO, AEVUM_AUTO_ECM_MAX_RATIO and AEVUM_AUTO_GENERIC_MAX_RATIO.

Run the host and routing checks with:

make test-aevum-host test-aevum-reg test-aevum-auto test-aevum-default test-gui-state test-aevum-source

Run the GPU backend matrix with:

AEVUM_TEST_DEVICE=0 make test-aevum-auto-gpu

Aevum is a customized GPLv3 derivative of GPUOwl/PRPLL, adapted by cherubrock-seb into a reusable register engine. Its external interface is modeled after the kind of opaque register operations used by Marin, while the Aevum arithmetic implementation remains derived from GPUOwl/PRPLL. Aevum is not an official upstream release.

The standalone source includes:

• a main Aevum README
• the original upstream README renamed to README_GPUOWL.md
• UPSTREAM.md with the exact imported commit
• MODIFICATIONS.md
• GPU register examples and CPU-verified arithmetic chains

See third_party/aevum/README.md, README_AEVUM_REG.md, README_V99_7_AEVUM_AUTO_GUI.md and NOTICE.md.

License and upstream attribution

The root LICENSE is the MIT License and applies to PrMers-authored files unless a file or subdirectory states another license.

The optional engine in third_party/aevum/ is licensed under GNU GPL version 3 because it is a modified derivative of GPUOwl/PRPLL. Its own LICENSE, copyright headers, upstream README and attribution files are preserved in that directory.

Recommended public distribution:

1. publish cherubrock-seb/aevum-engine as a fork of gwoltman/gpuowl, preserving history and GPLv3
2. keep the main PrMers repository under MIT for PrMers-authored files
3. reference Aevum as an optional submodule or external plugin
4. when distributing a bundle or binary containing Aevum, provide the corresponding Aevum source and satisfy GPLv3 requirements

Whether a particular binary/plugin arrangement is treated as one combined work can depend on facts and jurisdiction. The conservative release approach is to publish complete source for both projects and avoid imposing terms incompatible with GPLv3. This is not legal advice.

Cleaning and uninstall

make clean
sudo make uninstall

Contributing and issues

Bug reports, feature requests and pull requests are welcome:

https://github.com/cherubrock-seb/PrMers/issues

When reporting a problem, include:

• OS and GPU
• OpenCL driver version
• Full command line
• Relevant worktodo.txt line, if any
• Last lines of terminal output and prmers.log

Author

PrMers is developed by cherubrock-seb, with feedback and contributions from users on GitHub and mersenneforum.org.

Backend compatibility details

• PRP, LL-safe, LL-unsafe, LL-safe2, normal P-1, three-register P-1 low-memory and ECM all use the same Auto/Aevum/Marin selection policy.
• A forced Aevum request falls back to Marin only when no admissible FFT3161 plan exists, and the log states the reason explicitly.
• The one-register P-1 ultra-low-memory algorithm is the sole Marin-only path because it depends on Marin fast3; Auto selects Marin and forced Aevum exits cleanly before GPU allocation.
• PRP/LL checkpoints now include backend and mode metadata. Legacy untagged checkpoints are not loaded into Aevum, and LL-safe, LL-safe2 and LL-unsafe use distinct filenames.

Power-of-two FFT323161 lead cache in v99.74

The exact plan 4:512:8:512:202 is now accepted by Aevum. Consecutive engine::square_mul(reg, 1) calls use a one-square pending scheduler so the GPU retains LEAD_WIDTH and upstream carryFused between iterations. See README_POW2_TYPE4_LEAD_CACHE.md for validation and A/B commands.

Stable correctness release v99.85

The v99.85 release excludes the experimental M19 path. It contains the classic P-1 Stage 2 BSGS correctness fix, deterministic ECM/P-1 stop/continue policies, and the conservative Apple Aevum safety policy described in RELEASE_V99.85.md.

To compare Aevum Type1, Type4 and PFA plans by workload on Linux, run:

PRMERS_DEVICE=1 PRMERS_PLAN_AUDIT_PROFILE=standard \
  ./scripts/audit_aevum_plans_ubuntu.sh

The audit requires word-exact results before a faster plan can be recommended. throughput:auto remains the PRP/LL policy; ECM and P-1 Stage 1 remain on the validated Type1 policy until the workload audit proves a faster exact plan. P-1 Stage 2 V-trace and classic BSGS use Marin.

Workload-aware Aevum plans (v99.86)

Automatic Aevum plans are selected separately for PRP, LL, P-1 Stage 1 and ECM. Run scripts/audit_aevum_plans_ubuntu.sh to compare exact candidates and produce a local override profile. See RELEASE_V99.86.md.

GMNet distributed Gaussian Mersenne search

PrMers is the GPU calculation engine used by GMNet:

https://gmnet.gaussianmersenne.workers.dev/

GMRelay obtains assignments, updates worktodo.txt, renews leases, and submits the JSON result files written by PrMers:

https://github.com/cherubrock-seb/gmrelay

A deep P-1 Stage 1 job uses B2 = B1, which disables Stage 2. A mixed factorization campaign uses GMCHAIN=...,factor, which runs P-1 and optional ECM and then stops without starting a Proth test.