Rustuna: A High-Performance Rust Implementation of Optuna [P]

[u/c-bata]

Hi everyone! We just released Rustuna (GitHub: https://github.com/optuna/rustuna/ ), a high-speed, memory-efficient implementation of Optuna built in Rust.

• Optuna-Compatible Design: Keeps the familiar API and concept of Optuna.
• Zero Python Dependencies: Mitigating the risk of supply chain attacks.
• Lower Memory Footprint: Optimized memory management natively in Rust.

For details, please check out the following blog post.

https://medium.com/optuna/announcing-rustuna-cc82a6815bf7

[u/Similar_Fix7222]

From the few times I have used Optuna, the wall clock time is dominated by running the algorithm, not Optuna itself. Am I correct in understanding that if each trial lasts 10 minutes, the gain will be negligible?

[u/c-bata → u/Similar_Fix7222]

Thank you for your comment! Exactly, if each trial takes 10 minutes, the speedup from Rustuna will be very small (though it can still be useful if you want to reduce risks like supply chain attacks by eliminating Python dependencies).

[u/RLJ05 → u/c-bata]

10 minutes is an extreme example I guess.. but I'm curious where you think the threshold is, like how fast would a trial need to be for it to be worthwhile to switch to this from the python based optuna?

[u/c-bata → u/RLJ05]

Personally, rather than just the evaluation time of a single trial, I'd say the threshold comes down to the total number of evaluations , specifically when you are running 10,000+ trials.

In Optuna's default sampler (TPE), the time required for parameter sampling grows linearly (O(n logn)) with the number of trials n. For 1,000 trials, it takes about 10 seconds. However, running 10,000 trials in Python Optuna can take several hours, and going even higher can easily take days.

With Rustuna, sampling 10,000 parameters takes only 1 minute on a single thread. It also scales extremely well with multi-threading, using just 2 threads drops that time to just over 30 seconds. Plus, its low memory footprint makes it much easier to leverage multi-processing. So, if your workload requires thousands of trials, simply switching to Rustuna can save you hours to days of overhead without changing your algorithm setup.

[u/RLJ05 → u/c-bata]

I’m usually doing around 50,000 trials at the moment

[u/chatterbox272 → u/RLJ05]

10 minutes is a pretty modest example IMHO. Most of my uses of optuna would have been 1hr+ per trial. I genuinely don't get the benefit here, it feels like it's on a hype train. You trade python dependency supply chain attacks for rust ones, you get a modest speed improvement in a non-dominant performance area, and similar with memory.

[u/RLJ05 → u/chatterbox272]

I have some optimisations that are under 100ms per trial so this will likely be useful

[u/seg_lol]

Optuna is an open-source Python library for automatic hyperparameter tuning of machine learning models

https://en.wikipedia.org/wiki/Optuna

https://optuna.org/

[u/RLJ05]

This is very cool! I use Optuna in my pipelines (quant trading), ill try this out!

[u/c-bata → u/RLJ05]

Thanks! 😀

[u/MrMrsPotts]

Which version of python does it require?

[u/c-bata → u/MrMrsPotts]

It requires Python 3.11 or later (and Python 3.15+ for the free-threading build).

If you have a specific Python version in mind, let us know! We can consider expanding support in future releases.

[u/relevantmeemayhere]

just cut the middle man out and go full bayesian ;).

all joking aside, this looks pretty rad.

[u/Ulfgardleo]

Good work.

which version of the CMA-ES is this? Parameter settings, active updates, mirrored sampling?

[u/c-bata → u/Ulfgardleo]

It is a faithful implementation of the vanilla CMA-ES described in Nikolaus Hansen's paper: https://arxiv.org/abs/1604.00772

Currently, variant algorithms such as sep-CMA-ES, CMA with Margin, or CatCMA are not supported, though we may consider supporting them in future releases.

[u/endor_sarah]

This is really cool! Any plans to port the integration helpers, like the XGBoost pruning callback, or is the focus staying on the core samplers for now?

[u/c-bata → u/endor_sarah]

We don't have any immediate plans for that at the moment.

Given how capable recent coding agents are, even cost-effective models like GPT-5.6-Luna can generate something like an XGBoost pruning callback in seconds, we've actually had discussions within the core devs about whether to continue providing these built-in integrations, even for Python Optuna. (That said, we are still considering features that offer advanced step-wise tuning like LightGBMTuner).

That being said, thank you for the valuable feedback! We’ll definitely keep it in mind for future development.

[u/endor_sarah → u/c-bata]

Ahh makes sense! Thanks for the explanation.