GPU Dispatch (Experimental)

Experimental

GPU dispatch is experimental, opt-in, and a single operation. It is off by default, it computes in float32, and it is not general GPU compute. Treat it as a preview.

Wyn can run [float].map on the GPU. The code you write is exactly the CPU code you'd write anyway - there is no separate kernel language and no device/host bookkeeping:

fn main() {
    xs = [1.0, 2.0, 3.0, 4.0]
    doubled = xs.map((x) => x * 2.0)
    print(doubled)
}

Opting in

The GPU path is off unless you turn it on in wyn.toml:

[gpu]
enabled = true
float32 = true

With those keys set, [float].map is eligible to run on the GPU. Without them, the same .map runs on the CPU exactly as before.

How it works

• Metal backs it on macOS; OpenCL on Linux and Windows.
• Both backends are loaded at runtime, so a binary built with GPU enabled still runs on a machine with no GPU - it falls back to the CPU automatically.
• No speedup has been demonstrated yet. On an Apple M3 Pro, the GPU path was slower than the CPU on every size measured (10M elements: 197ms GPU vs 134ms CPU; 50M: 679ms vs 584ms). Transfer overhead and the single-op scope dominate. Treat this as an experimental spike, not a performance feature.

The float32 caveat

The GPU path computes in float32, while Wyn's default float is float64. Results can therefore differ in the low bits from the CPU path. That is a real numerical tradeoff, which is why the GPU path is opt-in and off by default rather than something that silently changes your numerics.

What it is not

• Not general GPU compute - only [float].map, a single operation.
• Not automatic - you opt in per project via wyn.toml.
• Not a stable API yet - it may change as the feature matures.

See Also

• Spawn & Await - CPU concurrency on the coroutine scheduler
• Benchmarks - performance numbers
• Known Limitations - what Wyn can't do yet