geatpy-rsHigh-Performance Evolutionary Algorithm Toolbox

geatpy-rs is a Rust rewrite of the core of Geatpy, the classic Python toolbox for evolutionary computation. The original Geatpy ships its C/C++ core only as a binary, its prebuilt wheels stop at Python 3.10, and there is no Linux ARM64 build. geatpy-rs rewrites all 74 core operators in Rust (PyO3 + abi3), provides prebuilt wheels for Python 3.8 – 3.15, and keeps the original Python interface and algorithm templates, so existing code runs without changes.

geatpy-rs is the Rust version of Geatpy: all 74 operators of the original core are rewritten in Rust (source in crates/geatpy_core, built on PyO3 and rust-numpy) and published as a Python extension for Python users; after pip install geatpy-rs you import geatpy as ea as usual. The Rust core is not published on crates.io, and its operators take and return Python / numpy objects, so a Rust program cannot depend on it as an ordinary Rust library; to implement the same algorithms in Rust, use the source in the repository as a reference.

The original Geatpy only publishes prebuilt wheels for Python 3.5 – 3.10 on PyPI. On Python 3.11, 3.12, 3.13, 3.14 or 3.15, pip finds no matching wheel and tries to build from source, which fails because the original core is not released as source. Install geatpy-rs instead (pip install geatpy-rs): it ships prebuilt abi3 wheels, so no compiler is needed.

Yes. macOS gets Universal2 wheels containing both Apple Silicon and Intel builds, so no Rosetta 2 is needed; Linux gets x86_64 and ARM64 (aarch64) manylinux2014 wheels that work on ARM cloud servers such as AWS Graviton and in Docker containers; Windows gets x64 wheels.

No. geatpy-rs keeps the Python interface of the original: ea.Problem, ea.Population, ea.optimize, the 42 algorithm templates (moea_NSGA3_templet, moea_NSGA2_templet, soea_SEGA_templet and others) and core operators such as ndsortESS, crowdis, mutbga and xovdp keep their names and signatures. After installing geatpy-rs you still import geatpy as ea. Where the original binary contradicts its own documentation, geatpy-rs follows the documentation (see the parity section above).

This is verified systematically. Deterministic operators are compared value by value against the actual output of the official 2.7.0 binaries, random operators by their statistical distributions, and 39 algorithm templates by final solution quality; about 1500 randomised differential cases run on both sides, comparing values, dtypes, return structures and errors; and 36 classic benchmark cases run 30 times on each side show no significant difference in solution quality. The official binary has several defects where it contradicts its own documentation (such as wrong fronts in ndsortDED, cross-row accumulation in mergecv, multi-population migration discarding the best individuals, and segfaults on edge-case input); geatpy-rs follows the documentation and the tests note each case, which is also why multi-population templates find clearly better solutions.

42 single- and multi-objective algorithm templates: multi-objective algorithms such as NSGA-III, NSGA-II, RVEA, MOEA/D and awGA, and single-objective algorithms such as SEGA, SGA, EGA, differential evolution (DE) and evolution strategies (ES). The Rust core contains 74 operators: population initialisation and encoding conversion; tournament, roulette-wheel and other selection; single-point, two-point, uniform, PMX, SBX and other crossover; polynomial, Gaussian, differential-evolution and other mutation; ndsortESS non-dominated sorting, crowdis crowding distance, refselect reference-point selection; and the GD, IGD, Spacing and HV indicators.

The Rust core of the stable 2.7.6 release is single-threaded; the Parallel argument of the original operators is accepted for compatibility but has no effect. Even so, the 36 classic cases run in 0.05 – 0.73 times the original runtime. On free-threaded (no-GIL) Python 3.14t the core does not need the GIL, so threads can run several templates at once (8 threads running 8 DE runs are 4.4 times faster). The multithreading preview 2.8.0b2 is installed with pip install --pre geatpy-rs: non-dominated sorting, reference-point selection, distances and the GD / IGD / Spacing indicators run on several threads for large inputs, bit-identical to one thread; set the thread count with ea.set_num_threads() or the GEATPY_NUM_THREADS environment variable. The gain is small for typical populations under a thousand, and when running several processes, use one thread per process. Objective functions still need to be vectorised or parallelised in your problem class.

The template passes F=[0.5, None]. The documentation says None means F2 is generated randomly during mutation, but the original binary actually fixes F2 at 0.5; geatpy-rs follows the documentation and draws it randomly, so on problems like Rastrigin it converges more slowly than 2.7.0 (30 dimensions, 50 individuals × 1000 generations: median best value about 93 → 156). For the original behaviour, set algorithm.mutOper.F = [0.5, 0.5] before running.

Constraints go into the CV matrix returned by evalVars, one column per constraint, and a constraint is satisfied when CV <= 0. Common mistakes are a flipped sign (x1 + x2 >= 1 should be written as 1 - x1 - x2) and equality constraints without a tolerance (write |h(x)| - 1e-6); for an “or” of two constraints, take the smaller of the two. When solving fails, geatpy-rs prints how many individuals of the last generation violate each constraint and the smallest violation, to help locate the problem. See the FAQ in the README for more.

In the original, infeasible individuals are ranked into one long chain by their degree of violation, so non-dominated sorting degrades to quadratic time and sorting 50,000 individuals once takes tens of minutes (upstream issue #319). From 2.7.5 on, geatpy-rs compares each individual only with the nearest front members: 10,000 individuals with 3 objectives and 1 constraint drop from 6.4 s in the original to 0.05 s, with fronts bit-identical to the original. Pass progress=True to show a progress bar on long runs.

Yes. From 2.7.6 on there are cp314t wheels for Python 3.14t (Linux x86_64 / ARM64, macOS Universal2, Windows x64); run pip install geatpy-rs on 3.14t as usual, and the GIL stays disabled after import. Several threads can run their own algorithm templates, or compute the objective function in chunks with a thread pool inside evalVars: 8 threads running 8 DE runs are 4.4 times faster, and 3.8 times faster when the objective is written in pure Python; chunking a pure-Python objective within a single run (400 individuals × 1000 variables) is 1.9 times faster overall. Threads share numpy’s global random state, so seeded runs are not reproducible when several run at the same time; calling numpy functions such as np.cos on single numbers makes threads contend and slows them down, so use the math module or call numpy on whole arrays.

Yes; speed and memory are not the bottleneck. With 100,000 variables and 50 individuals, DE, SEGA and EGA take 23 – 30 ms per generation, 0.33 – 0.39 times the official 2.7.0; a binary-encoded 0-1 knapsack takes 25 ms per generation (original 95 ms) and 125 ms at 500,000 variables (original 442 ms), with 10 % – 40 % less peak memory than the original. Evolutionary algorithms themselves hardly converge at this scale (upstream issues #281 and #295), so exploit the structure of the problem (variable grouping, dimension reduction, problem-specific operators) or use a classical optimisation method. The benchmark script is scripts/parity/large_scale.py in the repository.

Yes. As in the original, the core draws random numbers from numpy’s global random state: call np.random.seed, or pass seed to ea.optimize, and the same code gives exactly the same result.