7. Advanced Topics

By this point, you can train every estimator and network in the crate. You can split and scale data, and read off metrics. This chapter covers the cross-cutting concerns that surface once a model leaves your editor: a test suite, a benchmark, or someone else’s binary. It covers making a run repeat exactly, and moving a trained model between processes. It also covers matching the parallel kernels to your hardware, and stripping the dependency tree down to what you actually compile. None of this changes what a model computes. All of it changes whether you can trust the result, ship it, and afford it.

These sections assume you have worked through Getting Started, and have trained at least one model from Classical Machine Learning or Neural Networks. The sections are largely independent, so read them in any order. Start with 7.1, though. Reproducibility is what makes the persistence round-trips and performance comparisons in later sections verifiable at all.

7.1. Reproducibility and Random Seeds

Every randomized component draws its RNG through one resolver. The list includes weight initialization, dropout and noise masks, the Sequential minibatch shuffle, k-means centroids, SVC/LinearSVC, MeanShift, Isolation Forest, train_test_split, and t-SNE. A single set_global_seed(seed) call, on the current thread, fixes them all together. Reproducibility and Random Seeds covers 3 things. First, the three-way resolution between a per-model random_state: Option<u64>, the thread-local global seed, and OS entropy. Second, why an explicit local seed never perturbs the seeds handed to unseeded components. Third, the thread-locality trap under --test-threads=1. This section underpins the deterministic splits in Train-Test Split.

use rustyml::set_global_seed;

fn main() {
    // Fix every unseeded draw on this thread before constructing any model.
    set_global_seed(42);
}

7.2. Model Persistence in Depth

save_to_path and load_from_path serialize a trained model to a compact postcard binary. Model Persistence in Depth goes past the happy path. It explains what actually lands in the bytes: the fitted parameters and hyperparameters, not your dataset. It explains why loading a neural network reconstructs weights into an architecture you rebuild by hand, rather than restoring the graph itself. It explains how a layer-count or weight-shape disagreement surfaces as IoError::ModelStructureMismatch, instead of silently loading garbage. This section pairs with Saving and Loading Weights, which covers the network-specific save/load mechanics in full.

7.3. Performance Tuning and Parallelism

Every parallel kernel chooses serial-versus-rayon, and for GEMM, which parallel strategy, by comparing a work estimate against a calibrated threshold. Those thresholds are tuned on the maintainer’s machine, not yours. Performance Tuning and Parallelism shows how the rustyml::tuning facade overrides each gate at runtime, through a single relaxed atomic store. The gates include the GEMM/GEMV FLOP crossovers, the elementwise and reduction element counts, the conv/pool/norm gates, and the tree gates. You can retune any of them for your core count and cache size, without a recompile. A gate only selects an execution strategy. It never changes what is computed. See Matrix Multiplication and Parallel Reductions for the kernels these gates govern.

7.4. Minimal Builds and Modular Integration

The crate splits into feature-gated modules: machine_learning, neural_network, utils, metrics, and the shared math core. A project that only needs k-means never compiles the neural-network stack, or its indicatif progress-bar dependency. Minimal Builds and Modular Integration maps which feature pulls in which dependencies. It also covers what the default, full, and show_progress flags turn on. It shows how to drop RustyML into an existing pipeline as one module among many. Installation and Feature Flags covers a first pass over this same material.