Authoritative simulation
Keep lockstep, solver, or world-state transitions identical across successful supported targets.
C++20 runtime and compute SDK
One deterministic Flow.
Choose the execution target.
Express a bounded integer or fixed-point state transition once. Every successful supported target returns the same accepted bytes. An unavailable target returns its typed failure—never a hidden fallback.
- One public Flow
- Explicit Target selection
- Exact accepted output
1.0.4 Alpha Darwin ARM64 binary C++20 MIT
using Target = rund::compute::Target;
auto execute = [&](Target target) {
return rund::compute::on(target, input)
.map("step", [](auto x) { return x * 2 + 1; })
.collect();
};
auto cpu = execute(Target::cpu());
auto metal = execute(Target::metal());
auto vulkan = execute(Target::vulkan());
Checked example output
same bytes: cpu = metal = vulkan [3, 5, 7, 9]
The complete example handles each Result before comparing bytes.
01 / Where it earns its place
Built for state that cannot drift.
Use runD when backend differences are correctness defects—not merely performance noise.
Use runD when
Replayable compute
Make numeric law, ordering, graph identity, bounds, and canonical input part of the reproducible contract.
Backend choice without duplicate application kernels
Keep one public Flow and select the physical target explicitly when the workload or host changes.
02 / The SDK path
Start with collect(). Add machinery only when work repeats.
One package covers the first result, reusable device work, and the runtime services around it.
Choose the smallest compute shape
Flow + collect()- Run one bounded computation and return a host result.
Program- Compile the graph once and bind new input without rebuilding it.
resident()- Keep repeating state on the selected device across warm runs.
Pipeline- Connect dependent Programs without forcing intermediate host copies.
Batch- Put independent prepared jobs behind one submission boundary.
Runtime beside compute
Session and Tasks
Own lifecycle, scheduler resources, bounded work, and Compute submission together.
Host, Network, and Storage
Admit external input through explicit ownership and bounded byte-level operations.
Replay and Telemetry
Capture canonical evidence and inspect bounded findings without changing the result.
03 / Measured on an M4 Pro
The execution shape matters as much as the backend.
These checked observations answer two integration questions. They are not a portable CPU-versus-GPU ranking.
When resident work is compute-heavy
Compute-heavy warm map
M4 Pro · N = 262,144 · median warm Job::run()
- CPU
- 324.959 µs
- Metal
- 123.666 µs
- Vulkan / MoltenVK
- 190.542 µs
Use this to decide whether repeated resident execution deserves an accelerator measurement for your graph.
When submissions dominate
64 small GPU jobs
M4 Pro · 64 jobs × 64 elements · serial API wall path → one Batch
- Metal
- 7,347.062 → 227.645 µs
- Vulkan / MoltenVK
- 9,136.105 → 583.146 µs
Use this to decide whether independent prepared jobs should share one submission boundary. The ratio is not a pure kernel-speed claim.
Warm figures exclude Resident creation and initial upload. Vulkan here runs through MoltenVK on Apple hardware. A different graph, device, driver, or data shape requires a new measurement.
04 / 1.0.4 Alpha
Try the verified SDK on Apple silicon.
The current consumer release is intentionally narrow. Check the host boundary before integration.
Darwin ARM64
CPU · native Metal · Vulkan through MoltenVK
Linux x64
Validated source candidate; no consumer release backend matrix is claimed.
Windows x64
No binary or execution path is claimed for 1.0.4.
Vulkan dependency
The archive does not bundle MoltenVK. The verifier requires the exact admitted dependency tuple, so check the platform contract before installing.