heuropt/docs/book/src/comparison.md

Comparison with other libraries

heuropt is one of many heuristic-optimization libraries. This chapter is an honest, opinionated comparison to help you choose.

The columns:

• Lang — primary implementation language.
• Algorithms — rough catalog count.
• Multi-obj — built-in support for Pareto-based multi-objective optimization.
• Surrogates — built-in Bayesian / TPE / multi-fidelity.
• Determinism — seeded reproducibility as a first-class property.
• Async / async-eval — first-class async runtime support.

Library	Lang	Algorithms	Multi-obj	Surrogates	Determinism	Async
heuropt 0.5	Rust	35	✅ NSGA-II/III, SPEA2, IBEA, MOEA/D, MOPSO, SMS-EMOA, HypE, AGE-MOEA, GrEA, KnEA, RVEA, PESA-II, ε-MOEA, PAES	✅ BO, TPE, Hyperband	✅ bit-identical seeded	⏳ planned
pymoo	Python	~25	✅ extensive	partial (BO via plug-ins)	✅	❌
DEAP	Python	flexible toolbox	✅	❌	✅	❌
hyperopt	Python	TPE-focused	❌	✅ TPE	partial	partial
optuna	Python	TPE / CMA-ES / NSGA-II	✅	✅ TPE, BoTorch via plug-in	✅	✅
MOEA Framework	Java	~40	✅ very extensive	❌	✅	❌
metaheuristics-rs	Rust	~10	partial	❌	✅	❌
argmin	Rust	line-search / quasi-Newton	❌	❌	✅	❌

When to pick heuropt

• You're working in Rust and want a single, dependency-light crate for evolutionary / metaheuristic optimization.
• You need multi-objective or many-objective algorithms (12+ Pareto-aware methods in the catalog) AND you don't want to glue Python into your Rust pipeline.
• You want bit-identical determinism: same seed produces same output, on every machine, across releases unless explicitly noted otherwise.
• You want a small, readable codebase — every algorithm is written for clarity, no trait-object plumbing, no GATs in user- facing APIs. Reading RandomSearch should be enough to write a new optimizer.

When not to pick heuropt

• You need first-class async / await for evaluations that talk to HTTP services or spawn subprocesses. heuropt is sync; that's on the roadmap but not shipping yet.
• You need gradient-based optimization. Use argmin (Rust) or scipy.optimize (Python) — heuropt is gradient-free by design.
• You need GPU-accelerated evaluations. heuropt's evaluate function runs on CPU; use Python (jax/torch) or roll your own GPU pipeline.
• You need distributed multi-machine evaluation. heuropt parallelizes within one process via rayon. Distribution is up to you (split the seeds across machines, aggregate).
• You're comfortable in Python and pymoo / optuna already cover your problem. heuropt's value-add over pymoo is mostly that it's Rust — if that doesn't matter to you, the Python ecosystem has more battle-tested integrations.

Algorithm coverage at a glance

heuropt covers the same major Pareto MOEAs as pymoo and MOEA Framework: NSGA-II/III, SPEA2, IBEA, MOEA/D, MOPSO, SMS-EMOA, HypE, AGE-MOEA, GrEA, KnEA, RVEA, PESA-II, ε-MOEA, PAES.

The expensive-evaluation regime: BayesianOpt + TPE + Hyperband. This is comparable to optuna's coverage but in pure Rust.

The single-objective continuous catalog (CMA-ES, IPOP-CMA-ES, sNES, DE, PSO, GA, TLBO, (1+1)-ES, NelderMead, RandomSearch, HillClimber, SimulatedAnnealing) covers the canonical baselines and several modern variants.

What heuropt does not ship that some libraries do:

• Re-themed metaphor metaheuristics (Whale Optimization, Grey Wolf, Bat, Firefly, Harris Hawks, etc.). These are cut from the catalog deliberately — they are mostly DE/PSO with new names. If you specifically need one, please open an issue with citations.
• Non-evolutionary global optimizers like dual annealing or basin-hopping (use scipy.optimize for those).
• A web UI / dashboard like optuna's. heuropt is library-only.

Speed

heuropt's hot paths (Pareto utilities, hypervolume, key inner loops) are heavily optimized — see the perf entry in the v0.4.0 CHANGELOG. On the comparison harness in examples/compare.rs (10-seed mean, 30 000 evaluations on DTLZ2), the total wall-clock time across 12 algorithms is ~5 seconds. Per-algorithm timings are in examples/compare-results.md.

For comparison-shopping speed against Python libraries, the gap is typically 10×–100× in heuropt's favor for compute-bound evaluate functions, because Rust skips the Python-loop overhead. If your evaluate calls into NumPy/PyTorch and those are the bottleneck, the gap shrinks substantially.

Honest weakness: ecosystem

The biggest thing pymoo / optuna / DEAP have that heuropt doesn't: community + plug-ins + tutorials. They've been around longer and have rich third-party integrations (visualization, MLflow, Hyperband+BO hybrids, distributed runners). heuropt is younger; the core is solid but the ecosystem is small.

If you adopt heuropt and miss a thing, the project is small enough that contributions land fast. See CONTRIBUTING.md.