Skip to content

Parallelize space views #1325

@emilk

Description

@emilk

The Rerun viewer needs to run in Wasm on the browser. This limits our threading ability. std::thread is, for instance, not available. At the same time we want to make sure our viewer achieves good frame rate when compiled natively.

Parallelism on native, with single-threaded fallback on web

rayon is the go-to Rust crate for fine-grained parallelism. It is commonly used by library crates (behind a feature flag).
Currently rayon does not run in wasm in the browser, but this might change soon:

In the mean-time we can also define our own helpers for parallelism, e.g.:

/// Run two things in parallel
#[cfg(not(target_arch = "wasm32"))]
fn parallel<A: Send, B: Send>(
    a: impl Send + FnOnce() -> A,
    b: impl Send + FnOnce() -> B,
) -> (A, B) {
    rayon::join(a, b)
}

// Serial-fallback for wasm32
#[cfg(target_arch = "wasm32")]
fn parallel2<A: Send, B: Send>(
    a: impl Send + FnOnce() -> A,
    b: impl Send + FnOnce() -> B,
) -> (A, B) {
    ((a)(), (b)()) 
}

See #1041 for an experiment along these lines

Parallelism on wasm32

With a bit of work, one can spawn wasm32 threads in the browser with shared memory. Unfortunately, this requires a nightly compiler (for -Z build-std=std,panic_abort).

I think it could be fine for use to rely on the nightly compiler for just wasm32.

I suggest we keep this use-case in mind, but focus on the native performance for now.

Se also:

Metadata

Metadata

Assignees

Labels

🎄 tracking issueissue that tracks a bunch of subissues📉 performanceOptimization, memory use, etc📺 re_vieweraffects re_viewer itself🔺 re_rendererrendering, graphics, GPU🕸️ webregarding running the viewer in a browser

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions