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.
• It pays off on large, repeated maps. On arrays of 10M+ elements, repeated maps measured ~2-5x over the CPU on an Apple M3 Pro, an NVIDIA T4, and an A10G. For small arrays the transfer overhead dominates and the CPU wins.

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