Docs/Performance

Measure the boundary you ship.

A million elements can still be a poor offload workload. Submission, synchronization, transfer, memory traffic, and arithmetic intensity determine whether a physical backend pays.

Cost modelSetup · warm run · BatchExact workload evidence

Element count is not work

T_cpu = N C_cpu

T_backend = T_submit + T_sync + T_transfer + N C_backend

Offload wins only when the per-element advantage exceeds fixed and transfer costs. A light 32-bit map may move roughly eight bytes per element for only a few integer operations, so its arithmetic intensity remains low even at a large count.

One checked profile, three cost boundaries

Resident creation + input copy/upload

PathSetup medianInterpretation
CPU86.542 µsResident job creation and input copy.
Metal477.500 µsResident job creation and input upload.
Vulkan/MoltenVK561.000 µsApple translation path, not native Vulkan evidence.

Host: checked M4 Pro profile, N = 1,048,576. The timer encloses Program::resident(input). Compilation, Job::run(), and result read are outside it. These numbers describe setup, not CPU-versus-GPU compute speed.

Compute-heavy warm execution

PathWarm run medianCPU / path
CPU324.959 µs1.000×
Metal123.666 µs2.628×
Vulkan/MoltenVK190.542 µs1.705×

Workload: dense expensive map, N = 262,144. Resident creation and one validated warmup happen before sampling; each sample times only Job::run(). The suite accepts the result only when its graph and output hashes match the CPU reference.

Submission amortization

Path64 serial jobsOne BatchSerial / Batch
Metal7,347.062 µs227.645 µs32.274×
Vulkan/MoltenVK9,136.105 µs583.146 µs15.667×

Workload: 64 independent jobs of 64 elements on the same checked M4 Pro profile. This proves the structural benefit of one submission boundary for this case. The serial wall path also includes per-job stats and host-loop work, so the ratio is not a pure kernel or submission speedup.

Optimize shape without changing meaning

  • Program removes repeated graph construction and compilation.
  • Resident removes warm allocation and host transfer.
  • Pipeline removes intermediate host materialization and extra submissions.
  • Batch amortizes submission and synchronization across independent jobs.
Determinism remains fixed Batching cannot reorder jobs. Fusion cannot reassociate a reduction. A measurement becomes admissible only after graph identity and output identity have been verified.

Measure the boundary on your host

The single-Flow abstraction does not create a portable performance ranking. A new device, runtime, driver, lowering, data shape, or execution surface requires its own admitted evidence.

These commands are repository engineering harnesses, not programs shipped in the binary SDK. Run them from a runD source checkout after building and installing the matching Release SDK.

tools/measure/compute/run --resident cpu
tools/measure/compute/run --resident metal
tools/measure/compute/run --resident vulkan
tools/measure/compute/run --pipeline metal
tools/measure/compute/run --pipeline vulkan

The checked baseline stores observed values and separate regression upper bounds. A row is admitted only after semantic identity and output evidence pass; a passing upper bound is not a speedup claim. For exact methodology and additional routes, inspect the optional engineering measurement reference ↗.

Next referenceSeparate measured paths from supported release tuples