Data Parallelism with Rayon

Rayon turns sequential iterators into parallel ones with a work-stealing thread pool. It shines on CPU-bound data processing without manually managing threads.

Recipe

Quick-reference recipe card - copy-paste ready.

use rayon::prelude::*;
 
fn main() {
    let sum: i32 = (1..=1_000_000).into_par_iter().sum();
    println!("{sum}");
}

When to reach for this: Parallel maps, filters, reductions, and sorting over in-memory collections.

Working Example

use rayon::prelude::*;
 
#[derive(Debug)]
struct Record {
    id: u64,
    value: f64,
}
 
fn main() {
    let records: Vec<Record> = (0..100_000)
        .map(|i| Record {
            id: i,
            value: (i as f64).sqrt(),
        })
        .collect();
 
    let top: Vec<_> = records
        .par_iter()
        .filter(|r| r.value > 100.0)
        .map(|r| r.id)
        .collect();
 
    let total: f64 = records.par_iter().map(|r| r.value).sum();
    println!("matches = {}, total = {:.2}", top.len(), total);
}

What this demonstrates:

• par_iter splits work across Rayon's pool.
• Combinators mirror sequential iterators.
• Results are deterministic for associative reductions like sum.

Deep Dive

How It Works

• Work stealing: Idle threads steal tasks from busy queues - good load balance on uneven work.
• Global pool: Default pool sized to CPU cores. Initialize once per process.
• Divide and conquer: par_iter splits ranges until chunks are small enough.
• Send bound: Items and closures must be Send - same as thread::spawn.

Common APIs

Rust Notes

// Custom thread pool for isolation
use rayon::ThreadPoolBuilder;
 
let pool = ThreadPoolBuilder::new().num_threads(4).build().unwrap();
pool.install(|| {
    let result = data.par_iter().map(expensive).sum::<i32>();
});

• Use pool.install to scope custom pools.
• Avoid I/O inside par_iter closures - blocks pool threads.
• ParallelIterator requires Send for T and closures.

Gotchas

• Tiny collections - Thread overhead exceeds savings on 10-item vectors. Fix: Use sequential iterators below a threshold (often thousands of items).
• Blocking I/O in parallel closures - Starves the Rayon pool. Fix: Use async I/O or a dedicated blocking pool (spawn_blocking).
• Non-associative reductions - sum on floats or custom ops may vary by order. Fix: Use sequential reduce or compensated summation.
• Mutex inside par_iter - Serializes work, defeats parallelism. Fix: Use map to produce values then reduce, or fold per partition.
• Sharing Rc across par_iter - Rc is not Send. Fix: Use Arc or process owned data per item.

Alternatives

FAQs

Related

• Concurrency Basics - manual threads
• Scoped Threads - borrow-based parallelism
• Blocking in Async - Rayon in async apps
• Send & Sync - Send requirement
• Concurrency Best Practices - profile before parallelizing

Stack versions: This page was written for Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, and Polars 0.46+.