quantum_cutrank_metal (feature quantum_cutrank_metal, macOS) runs the cut-rank walk's
passes on the platform's GPU:
- each shot's table is 2^cut single-precision entries in one shared buffer, at most
2^31 a table, so every index fits in 32 bits;
- each pass is one dispatch over (entry, shot), in the walk's order and with its
arithmetic, done in f32; the passes are the same for every shot, and only each
shot's weights (set by the outcomes it drew) differ, read from a small per-shot
array; an amplitude is every pass encoded into one command buffer;
- a sample's sums are reduced per threadgroup on the device (a SIMD-group sum, then the
groups in order) and added on the host in f64, in order, for each shot; the outcome
is drawn as the host's walk draws it (outcome_norm and draw, now shared by both);
- a batch of shots is sampled side by side, so a qubit is one command buffer for the
batch: the previous qubit's passes for each shot's outcome, then this qubit's sums;
- each shot draws from a stream of its own, so a seed's samples are the same at any
batch size.
The kernels are compiled in the platform's safe math mode, so a run is the same bits
on one device. Tests hold it to the double-precision walk on states of 10 to 34
qubits: amplitudes within 1e-5 of each amplitude's size and the same bits run to run;
samples whose probabilities are their own and whose counts follow them; and the same
samples one at a time and seven side by side. Without a device the tests skip;
WAI_QUANTUM_CUTRANK_METAL_EXPECT makes that a failure, and the service workflow's
macOS job sets it and checks both GPU tests by name.
The engine's cutrank_single method runs a cutrank job on that table where the build
has the feature and the host a GPU; auto never picks it. It samples up to 32 shots a
batch, as many as 2 GiB beside its first table holds within the job's memory, and the
plan counts them. Its amplitudes carry the circuit's global phase, found on the same
table (catalog::cutrank_phase_with takes the amplitude function). The job service, the
command line's metal feature and the desktop app's metal feature build it in. The
service's schemas list it, and it marks the method's energy figure partial, since the
counter does not read the GPU.
examples/cutrank_gpu times one state's amplitudes and samples on the host's tables and
on the GPU, and each kernel's pass alone. On a shared desktop machine, each device at
its quietest (either side ran up to five times slower under other work), seconds for
one amplitude of a random graph state:
widest cut host, double host, single GPU
23 bits 0.027 0.024 0.005
25 bits 0.057 0.045 0.019
27 bits 0.18 0.17 0.046
29 bits 1.03 0.54 0.34
and for 64 samples, 16 a batch, the host at about half its quietest speed:
widest cut host, single GPU, one at a time GPU, 16 a batch
16 bits 0.52 0.62 0.036
20 bits 1.97 0.73 0.067
23 bits 3.87 0.91 0.34
25 bits 7.48 1.82 1.20
A pass runs at about 550 GB/s on an idle device.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit f7c7160a9ab5a6255c28d34af57ee2fbc017b055)