russell@unturf.com
424051b7a4
Form A Day-3 shipped at lumbda ecfe27a. Windowed-G ladder (w=4,
16-entry G-table built once via batch-inverse on the 15 Z-coords)
landed clean.
Bench on 3090, n=1M (best-of-3, --no-batch-inv):
v1 (Day-1) 127.04 ms → 7.87 Mkeys/s
v3 (Day-3 w=4) 73.54 ms → 13.60 Mkeys/s (1.73x v1, ~309x coincurve)
Byte-identity PASS at n in {32, 1000, 10000, 100000, 1000000} plus
known-small edge cases (k in {1, 2, 3, 7, 0xdeadbeef, n-1, n, 2^128-1}).
Daemon default still serves v1; --window-w 4 flag selects v3
explicitly. Fox's call on flipping the daemon default.
Day-4 plan: stack v3 + Day-2 batch-inv. v3 cut scalar_mul; the
residual inversion cost now actually matters, which is what Day-2
needed to win.
Three agents still in flight: walker promotion (#39), lever
generator (#40), ai.foxhop.net second worker (#30).
320 lines
33 KiB
HTML
320 lines
33 KiB
HTML
<!doctype html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||
<title>bend — Lumbda's GPU dispatch primitive</title>
|
||
<meta name="description" content="bend is Lumbda's GPU dispatch primitive: cost-routed local-vs-remote execution over a wire protocol, with a catalog of CUDA forms each backed by published speedup benchmarks.">
|
||
<link rel="stylesheet" href="style.css">
|
||
<script src="https://uncloseai.com/uncloseai.js" type="module"></script>
|
||
</head>
|
||
<body>
|
||
|
||
<header>
|
||
<h1 aria-label="lumbda."><a href="index.html" style="color:inherit;text-decoration:none">lumbda<span class="period" aria-hidden="true">.</span></a></h1>
|
||
<img class="lambda-mark" src="lumbda-logo-green.png?v=2" alt="" aria-hidden="true">
|
||
<p class="tagline">bend — dispatch to a GPU without rewriting your code</p>
|
||
</header>
|
||
|
||
<main>
|
||
|
||
<section id="what">
|
||
<p class="lead">
|
||
<code>bend</code> is a Lumbda primitive that decides per call whether to evaluate locally or ship to a CUDA worker over our wire protocol. Tiny inputs stay local; heavy inputs bend to a worker that holds a warm CUDA context across requests. The decision uses a cost estimator on the argument shape, not the operation name.
|
||
</p>
|
||
<p>
|
||
This page documents the protocol, the wire numbers we measured, and a catalog of forms — standalone CUDA binaries with published speedups that bend can dispatch to.
|
||
</p>
|
||
</section>
|
||
|
||
<section id="start">
|
||
<h2>Start a GPU worker</h2>
|
||
<pre><code># On any host with nvcc + a CUDA-capable GPU:
|
||
make gpu-worker
|
||
# → builds examples/cuda-fanout/shake256-fanout
|
||
# → builds the C tier (~10× faster wire orchestration than Python)
|
||
# → launches gpu-worker.lsp on port 9091
|
||
|
||
# Override tier or port:
|
||
make gpu-worker LUMBDA=python PORT=9001 # easier debugging
|
||
make gpu-worker LUMBDA=asm # smallest footprint</code></pre>
|
||
</section>
|
||
|
||
<section id="call">
|
||
<h2>Call it from any tier</h2>
|
||
<pre><code>;; bend works on every tier — Python, C, asm — through the same
|
||
;; tcp-* + portal primitives lumbda already ships.
|
||
(load "examples/cuda-fanout/wire.lsp")
|
||
(load "examples/cuda-fanout/bend.lsp")
|
||
(load "examples/cuda-fanout/bend-macros.lsp") ; Python/C only — asm uses bend-call
|
||
|
||
;; Tiny — cost below threshold, evaluates locally
|
||
(bend (cuda-shake-fanout '("00" "01" "deadbeef") 32))
|
||
|
||
;; Heavy — cost above threshold, ships to the GPU worker
|
||
(bend (cuda-shake-fanout one-million-inputs 32))</code></pre>
|
||
<p>On a single RTX 3090 with a warm daemon, SHAKE256 fan-out matched <code>hashlib.shake_256</code> byte-for-byte and won by 1.5–10× across the workloads we measured. Below the break-even (~100 MB of bulk hash work) host CPU stays faster — the cost estimator picks correctly.</p>
|
||
</section>
|
||
|
||
<section id="protocol">
|
||
<h2>Wire protocol — two modes</h2>
|
||
<p>The CUDA kernel runs inside the leaf binary; what the tier choice affects is wire orchestration. The wire has two modes: <strong>S-expression text</strong> (the default — hex strings inside a Scheme list) and <strong>binary</strong> (magic <code>BSHK</code> header + raw bytes, identical layout to the daemon's binary portal). Binary mode bypasses S-expression parsing entirely:</p>
|
||
<table>
|
||
<thead><tr><th>workload</th><th>Py S-exp</th><th>Py binary</th><th>C S-exp</th><th>C binary</th></tr></thead>
|
||
<tbody>
|
||
<tr><td>100 × 16 B</td><td>3.43 ms</td><td>0.74 ms</td><td>0.40 ms</td><td><strong>0.15 ms</strong></td></tr>
|
||
<tr><td>1k × 16 B</td><td>23.24 ms</td><td>0.76 ms</td><td>2.77 ms</td><td><strong>0.22 ms</strong></td></tr>
|
||
<tr><td>10k × 16 B</td><td>218.82 ms</td><td>1.27 ms</td><td>CLIFF</td><td><strong>0.88 ms</strong></td></tr>
|
||
<tr><td>100k × 16 B</td><td>2,219 ms</td><td>10.18 ms</td><td>CLIFF</td><td><strong>10.35 ms</strong></td></tr>
|
||
<tr><td>1M × 16 B</td><td>23,811 ms</td><td>159 ms</td><td>CLIFF</td><td><strong>157 ms</strong></td></tr>
|
||
</tbody>
|
||
</table>
|
||
<p><strong>Binary mode wins by 30–200× over S-expression mode at scale.</strong> At 1 M × 16 B inputs, C tier binary is <strong>157 ms</strong> end-to-end versus 23,811 ms for the S-exp path — a 150× speedup. The CUDA kernel itself on this 3090 runs in ~47 ms; binary wire adds ~110 ms of file I/O + framing on top, a 2.5× multiplier instead of the 500× multiplier the S-exp path imposed.</p>
|
||
<p>Critically, at huge workloads <strong>bend now beats host hashlib</strong>: host SHAKE256 over 1 M tiny inputs is ~2 s on a single Python core; bend via binary worker is 157 ms — a 12× speedup of host. The cost estimator in <code>bend.lsp</code> should be updated to know about the binary path so the routing decision picks GPU at this scale instead of staying local.</p>
|
||
<p>Binary mode lives behind the <code>BSHK</code> magic byte in the wire payload. S-expression callers see no change; binary callers prepend the magic and send raw bytes. See <code>examples/cuda-fanout/bench_tiers.py --binary</code> for the protocol implementation.</p>
|
||
<p>Three tiers, three operating points (S-expression mode): C tier wins at small & medium scales (8× faster than Python); asm tier hits 0.21 ms at very small inputs (~30% behind C, 6× faster than Python, 70 KB statically linked, zero libc); Python tier scales linearly (~22 µs per input) all the way through 1 M inputs but runs slowly on a single core. The S-exp CLIFFs at 10k (C) and 1k (asm) are tier-internal reader limits — binary mode bypasses them entirely.</p>
|
||
<p>The CUDA toolchain stays isolated to the leaf binary the worker spawns. No tier links libcudart; no tier requires nvcc at build time. Asm tier hosts workers through hand-written <code>pipe2 + fork + execve</code> syscalls — no libc anywhere on the chain.</p>
|
||
</section>
|
||
|
||
<section id="ecdsa">
|
||
<h2>Real workload — ecdsafail search</h2>
|
||
<p>Beyond hash fan-out, bend now dispatches quantum-reversible circuit scoring for our secp256k1 point-addition challenge work at <a href="https://www.foxhop.net/ecdsa.html">foxhop.net/ecdsa</a>. Lumbda emits an upstream-format <code>ops.bin</code> from a Phase B Roetteler 12-step circuit, calls <code>(bend!-call '(cuda-sim-ops-bin path 141))</code>, & receives Σ Clifford / Σ Toffoli totals back from a GPU worker over our binary wire — same cross-tier validation, same byte-identical portal contract the hash demo proves. Search loops on any host tier ship candidate scoring to whichever fleet node holds a warm CUDA context.</p>
|
||
<p>Measured on a 3090 against HEAD's 12.8 M-op kickmix <code>ops.bin</code> (716 MB):</p>
|
||
<table>
|
||
<thead><tr><th>n_batches</th><th>shots</th><th>wire-s</th><th>cpu-ms</th><th>gpu-ms</th><th>gpu/cpu</th></tr></thead>
|
||
<tbody>
|
||
<tr><td>1</td><td>64</td><td>5.5</td><td>42</td><td>5,107</td><td>0.008</td></tr>
|
||
<tr><td>16</td><td>1,024</td><td>7.3</td><td>850</td><td>5,800</td><td>0.146</td></tr>
|
||
<tr><td>64</td><td>4,096</td><td>11.4</td><td>3,444</td><td>6,216</td><td>0.553</td></tr>
|
||
<tr><td>128</td><td>8,192</td><td>17.1</td><td>7,060</td><td>6,604</td><td><strong>1.07</strong></td></tr>
|
||
</tbody>
|
||
</table>
|
||
<p>Crossover at ~115 batches. GPU kernel carries ~5,070 ms of fixed overhead (init + alloc + upload) plus ~12 ms per batch; CPU runs ~55 ms per batch. The kickmix circuit's conditional ops cause branch divergence — this is one form where GPU does not dominate. Honest numbers go in the catalog below.</p>
|
||
</section>
|
||
|
||
<section id="catalog">
|
||
<h2>Form catalog</h2>
|
||
<p>A form earns a slot here only after we have published a benchmark or measured one on our hardware. "I think this would be fast" does not earn a slot — the form-status column says <code>planned</code> until numbers exist.</p>
|
||
|
||
<h3>Form D structural finding — 2026-06-05</h3>
|
||
<p><code>cuda-clifford-stabilizer</code> as originally scoped does not apply to our point-add circuit. Build agent measured Toffoli fraction 13.87% (well under the 40% threshold), then noticed the circuit contains no Hadamard or S gates — only X / CX / CCX / CZ / CCZ / SWAP / R / HMR / Z / NEG. State never leaves the computational basis. Aaronson-Gottesman tableau compression buys nothing when superposition does not exist; it reduces to exactly what <code>sim_gpu.cu</code> already does, at one bit per qubit per shot.</p>
|
||
<p>The <code>cuda-sim-ops-bin</code> 1.07× ceiling traces to memory-bandwidth on per-shot striped state, not algorithm choice. STABSim-class wins remain valid for QEC / surface-code workloads where H + S exist; that's a future workload, not point-add today.</p>
|
||
<p>Both replacement directions landed 2026-06-05; the bandwidth-bound diagnosis they were chasing turned out FALSE for our circuit.</p>
|
||
<ul>
|
||
<li><strong>Axis-flip refactor of <code>sim_gpu.cu</code></strong> — DONE (foxhop commit <code>1f7ac9d</code>). 217 Mops/s @ K=32 M=4 on a 3090; 23.7× over per-shot N=4 at same M. Both kernels saturate at ~220–250 Mops/s. Axis flip's win is occupancy-amortization, not bandwidth redistribution. Right tool for lumbda's many-candidates × few-shots search-loop early-screen pattern.</li>
|
||
<li><strong><code>ops.bin</code> packing (QECCOPS2)</strong> — DONE (foxhop commit <code>90484ca</code>). 1.07× kernel speedup, 2.33× on-disk shrink (716 MB → 307 MB). The 3.5× projection assumed 56 B/op was VRAM-resident; <code>ops_loader.c</code> already narrowed to 28 B on load, so the realistic ceiling was 1.17×. Per-shot state traffic (qubits + bits per thread) dominates kernel bandwidth ~85× over the op stream.</li>
|
||
</ul>
|
||
<p>Both pivots converged on the same diagnosis: <strong>the 3090 is compute-saturated at ~250 Mops/s on the kickmix circuit, not bandwidth-saturated.</strong> Real next macro-lever: multi-GPU fan-out across our fleet.</p>
|
||
|
||
<h3>Status legend</h3>
|
||
<ul>
|
||
<li><code>live</code> — binary built, worker dispatches it, numbers recorded on our hardware</li>
|
||
<li><code>surveyed</code> — published benchmark cited, prototype binary not yet wrapped; speedup claims need verification on our fleet before promotion to <code>live</code></li>
|
||
<li><code>planned</code> — design slot reserved, no binary</li>
|
||
</ul>
|
||
<p>The catalog grows continuously. Each form below carries enough metadata for anyone to start a port: canonical reference, reported speedup, target hardware, sketch wire shape. Forms with HIGH relevance to our active missions (foxhop ECDSA work, undefect defect-scanning, unsandbox / unturf permacomputer infrastructure) move up the build queue.</p>
|
||
|
||
<h3>Live forms</h3>
|
||
<table>
|
||
<thead><tr><th>form</th><th>status</th><th>hardware</th><th>speedup vs CPU</th><th>wire shape</th></tr></thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>cuda-shake-fanout</code></td>
|
||
<td>live</td>
|
||
<td>RTX 3090</td>
|
||
<td>12× over host hashlib at 1 M × 16 B inputs</td>
|
||
<td><code>(cuda-shake-fanout '(hex ...) out-bytes)</code> + BSHK binary</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>cuda-sim-ops-bin</code></td>
|
||
<td>live</td>
|
||
<td>RTX 3090</td>
|
||
<td>1.07× at 128 batches (8192 shots); crossover ~115 batches</td>
|
||
<td><code>(cuda-sim-ops-bin "path/to/ops.bin" n-batches)</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>cuda-bignum-cgbn</code></td>
|
||
<td>live</td>
|
||
<td>RTX 3090</td>
|
||
<td><strong>1.28 Gops/s kernel</strong> mod-mul at n=1M (256-bit, ~256× GMP single-thread CPU); all 9 ops live (mod-add/sub/mul/sqr/inv/exp/reduce, add-no-mod, mul-no-mod-2x-width)</td>
|
||
<td><code>BCGB</code> binary: op_id + bitwidth + n + modulus + a + b</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>cuda-secp256k1-batched-mul</code></td>
|
||
<td>live</td>
|
||
<td>RTX 3090</td>
|
||
<td>v1 7.87 Mkeys/s @ n=1M; <strong>v3 (windowed-G w=4) 13.60 Mkeys/s @ n=1M</strong> — 1.73× v1, ~309× coincurve CPU. Day-4 v3 + Montgomery batch inv stacking is the next step toward FixedPaul's 6.5 Gkeys/s on 4090</td>
|
||
<td><code>BSCP</code> binary: scalars + base-point → <code>BSCR</code> points</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>cuda-sim-axis-flip</code></td>
|
||
<td>live</td>
|
||
<td>RTX 3090</td>
|
||
<td><strong>217 Mops/s @ K=32 M=4</strong> per-candidate-parallel kickmix sim; 23.7× over per-shot N=4 at same M; loses to per-shot by 14% at full N=128 saturation. Right tool for lumbda search-loop early-screen many-candidates × few-shots pattern</td>
|
||
<td><code>(cuda-sim-axis (variant-paths ...) n-shots)</code></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>Surveyed forms (published precedent, build queued)</h3>
|
||
|
||
<h4>A. <code>cuda-secp256k1-batched-mul</code> — batched secp256k1 scalar / point ops</h4>
|
||
<p><strong>Speedup:</strong> gECC 4.94× on unknown-point mul, 5.56× on ECDSA verify vs CPU. VanitySearch forks hit <strong>6.5 Gkeys/s on RTX 4090, 8.6 Gkeys/s on RTX 5090, 2.65 Gkeys/s on RTX 3080</strong>. Endomorphism + Montgomery batch-inversion (one mod-inv per N points instead of N) carries the kernel.</p>
|
||
<p><strong>Wire:</strong> <code>(secp-mul-batch (scalars . blob<N×32B>) (base-point . blob<64B>))</code> → <code>(points . blob<N×64B>)</code></p>
|
||
<p><strong>References:</strong> <a href="https://arxiv.org/pdf/2501.03245">gECC paper</a> · <a href="https://github.com/JeanLucPons/VanitySearch">VanitySearch</a> · <a href="https://github.com/FixedPaul/VanitySearch-Bitcrack">VanitySearch-Bitcrack fork</a></p>
|
||
|
||
<h4>B. <code>cuda-bignum-cgbn</code> — 256-bit modular arithmetic primitives</h4>
|
||
<p><strong>Speedup:</strong> <strong>100×+ on dense mul</strong> vs Xeon-20c + GMP + OpenMP on V100 (midsize-int study).</p>
|
||
<p><strong>Wire:</strong> <code>(cgbn-batch (op . mod-mul|mod-inv|mod-add) (modulus . blob<32B>) (a . blob<N×32B>) (b . blob<N×32B>))</code> → <code>blob<N×32B></code></p>
|
||
<p><strong>References:</strong> <a href="https://github.com/NVlabs/CGBN">NVlabs CGBN</a> · <a href="https://arxiv.org/pdf/2405.14642">midsize-int benchmarks</a></p>
|
||
|
||
<h4>C. <code>cuda-rho-pollard-walk</code> — Pollard rho / kangaroo walks</h4>
|
||
<p><strong>Speedup:</strong> <strong>87.7 M ops/sec on RTX 2070 Super</strong> for ECCp79 (Certicom challenge solved in ~3 hours). Original CUDA Pollard paper reports > 7.2 M points/sec at 256 threads on older HW.</p>
|
||
<p><strong>Wire:</strong> <code>(rho-walk-batch (start-points . blob<W×64B>) (steps . N) (distinguished-mask . blob<32B>))</code> → <code>(distinguished . blob<K×96B>)</code></p>
|
||
<p><strong>References:</strong> <a href="https://github.com/atlomak/CUDA-rho-pollard">atlomak/CUDA-rho-pollard</a> · <a href="https://github.com/oritwoen/kangaroo">oritwoen/kangaroo</a></p>
|
||
|
||
<h4>D. <code>cuda-clifford-stabilizer</code> — tableau stabilizer simulator (Stim-on-GPU)</h4>
|
||
<p><strong>Speedup:</strong> <strong>186× over Stim</strong> (CPU SOTA) on equivalence-checking. STABSim a first GPU stabilizer sim to scale better than CPU on QEC workloads.</p>
|
||
<p><strong>Wire:</strong> <code>(stab-sim-batch (n-qubits . k) (circuit . blob) (n-shots . S))</code> → <code>(samples . blob<S×ceil(k/8)>)</code></p>
|
||
<p><strong>References:</strong> <a href="https://arxiv.org/abs/2507.03092">STABSim</a> · <a href="https://arxiv.org/abs/2505.03307">Qimax</a> · <a href="https://arxiv.org/pdf/2603.14641">equivalence-checking</a></p>
|
||
|
||
<h4>E. <code>cuda-bernstein-yang-inv</code> — batched modular inverse (safegcd)</h4>
|
||
<p><strong>Speedup:</strong> 3–10× per inversion over Fermat on CPU. No published dedicated CUDA implementation found — gECC uses Montgomery's batched-inversion trick instead. Standalone Bernstein-Yang-on-CUDA holds novel territory.</p>
|
||
<p><strong>Wire:</strong> <code>(modinv-batch (modulus . blob<32B>) (xs . blob<N×32B>))</code> → <code>blob<N×32B></code></p>
|
||
<p><strong>References:</strong> <a href="https://eprint.iacr.org/2019/266">safegcd</a> · <a href="https://eprint.iacr.org/2024/644">Jumping for Bernstein-Yang</a></p>
|
||
|
||
<h4>F. <code>cuda-ntt-poly</code> — Number Theoretic Transform</h4>
|
||
<p><strong>Speedup:</strong> Up to <strong>123× over CPU</strong>; 21× on RTX 3070; cuFFT-comparable kernel structure.</p>
|
||
<p><strong>Wire:</strong> <code>(ntt (mod . p) (omega . root) (xs . blob<N×8B>))</code> → <code>blob<N×8B></code></p>
|
||
<p><strong>References:</strong> <a href="https://arxiv.org/pdf/2405.11353">NTTSuite</a> · <a href="https://eprint.iacr.org/2021/124.pdf">FHE NTT</a></p>
|
||
|
||
<h4>G. <code>cuda-radix-sort</code> / <code>cuda-prefix-scan</code> — reduction primitives</h4>
|
||
<p><strong>Speedup:</strong> <strong>1.4 G keys/sec on Titan</strong>; 20–50× over CPU merge sort; 257× over Intel Xeon Phi for scan.</p>
|
||
<p><strong>Wire:</strong> <code>(sort-u64 (xs . blob<N×8B>))</code> → <code>blob<N×8B></code></p>
|
||
<p><strong>References:</strong> <a href="https://github.com/NVIDIA/cub">NVIDIA CUB</a> · <a href="https://gpuopen.com/learn/boosting_gpu_radix_sort/">Onesweep</a></p>
|
||
|
||
<h3>Wave 2 — broader surveyed forms (2026-06-05)</h3>
|
||
<p>Sorted by reported speedup vs CPU descending. Speedups quoted from published benchmarks on the cited hardware; numbers labelled <code>surveyed</code> have not yet run on our fleet, so this table calls a paper a paper and a measurement a measurement.</p>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>form</th>
|
||
<th>speedup</th>
|
||
<th>hardware</th>
|
||
<th>relevance</th>
|
||
<th>ref</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr><td><code>cuda-minhash-weighted</code></td><td><strong>600–1000×</strong> vs numpy+MKL</td><td>Titan X vs 12-core Xeon E5-1650</td><td>HIGH — undefect corpus dedup, CVE shard clustering</td><td><a href="https://github.com/src-d/minhashcuda">src-d/minhashcuda</a></td></tr>
|
||
<tr><td><code>cuda-cuckoo-filter</code></td><td><strong>378× insert, 258× delete</strong></td><td>A100 (TCF on Perlmutter)</td><td>HIGH — foxhop ECDSA candidate-pruning, undefect URL-seen filter</td><td><a href="https://arxiv.org/pdf/2603.15486">arXiv:2603.15486</a></td></tr>
|
||
<tr><td><code>cuda-aes-ctr-chacha20</code></td><td><strong>211–400 GB/s</strong> (ChaCha8 / ChaCha20)</td><td>single GPU (RTX 3070 sustaining 672 Gbps Poly1305)</td><td>HIGH — AEAD on lumbda portal envelopes between tiers</td><td><a href="https://dl.acm.org/doi/fullHtml/10.1145/3605573.3605620">AsyncGBP</a></td></tr>
|
||
<tr><td><code>cuda-suffix-array-skew</code></td><td>30–242× vs CPU SA-IS</td><td>Tesla K20</td><td>MEDIUM — substring search for undefect source-corpus scans</td><td><a href="https://escholarship.org/content/qt83r7w305/qt83r7w305_noSplash_842edf05a7f4e9ecfb1a477bdf9318d3.pdf">Liu/Luo</a></td></tr>
|
||
<tr><td><code>cuda-kdtree-build</code></td><td>30–242× build, 1.6–200× kNN</td><td>RTX (RT cores)</td><td>MEDIUM — spatial index for unsandbox fleet locality</td><td><a href="http://www.kunzhou.net/2008/kdtree.pdf">Zhou et al.</a></td></tr>
|
||
<tr><td><code>cuda-sat-paraFROST-elim</code></td><td><strong>93× peak, 48× avg</strong> on variable elim</td><td>NVIDIA + CADICAL/Kissat baseline</td><td>HIGH — ECDSA / reversible-circuit equivalence checking via CNF</td><td><a href="https://github.com/muhos/ParaFROST">ParaFROST</a></td></tr>
|
||
<tr><td><code>cuda-aho-corasick-pfac</code></td><td>~50–100× (IDS pkt-inspect)</td><td>GTX-class</td><td>HIGH — secret/CVE-string scan across OSS source mirrors</td><td><a href="https://www.cise.ufl.edu/~sahni/papers/multipatternGPU.pdf">PFAC</a></td></tr>
|
||
<tr><td><code>cuda-dilithium-pqsig</code></td><td>57.7× keygen+sign+verify vs single CPU thread</td><td>RTX 3090 Ti</td><td>HIGH — PQ migration for unsandbox TLS, foxhop disclosure signing</td><td><a href="https://eprint.iacr.org/2024/1365.pdf">IACR 2024/1365</a></td></tr>
|
||
<tr><td><code>cuda-mc-options-pricing</code></td><td>25–152× (barrier-call kernel 152×)</td><td>Tesla C1060 / modern</td><td>LOW — calibration form, well-understood arithmetic</td><td><a href="https://developer.nvidia.com/gpugems/gpugems2/part-vi-simulation-and-numerical-algorithms/chapter-45-options-pricing-gpu">GPU Gems Ch.45</a></td></tr>
|
||
<tr><td><code>cuda-cuFFT-batched-1D</code></td><td>8–32× vs MKL; tcFFT 1.1–3.2× vs cuFFT</td><td>V100 / A100</td><td>MEDIUM — spectrogram dispatch for punters-cc audio correlation</td><td><a href="https://arxiv.org/pdf/2104.11471">tcFFT</a></td></tr>
|
||
<tr><td><code>cuda-blake3-tree</code></td><td>~5–20× (tree mode)</td><td>Blaze-3 CUDA</td><td>HIGH — content-addressed lumbda portal frames, foxhop attachments</td><td><a href="https://github.com/Blaze-3/BLAKE3-gpu">Blaze-3</a></td></tr>
|
||
<tr><td><code>cuda-bloom-filter-modern</code></td><td>~6× CPU; 3.4 B inserts/s</td><td>B200 / Perlmutter</td><td>HIGH — foxhop candidate-pruning, undefect scan-target known-set</td><td><a href="https://arxiv.org/pdf/2512.15595">arXiv:2512.15595</a></td></tr>
|
||
<tr><td><code>cuda-gemm-batched-FP8</code></td><td>4.8× FP8 vs A100; 716 TFLOPS H100</td><td>H100 SXM</td><td>LOW — calibration form, lattice-PQC matrix substrate</td><td><a href="https://developer.nvidia.com/blog/new-cublas-12-0-features-and-matrix-multiplication-performance-on-nvidia-hopper-gpus/">cuBLAS 12.0</a></td></tr>
|
||
<tr><td><code>cuda-batched-matrix-inverse</code></td><td>4.3–16.8× vs MAGMA</td><td>P100 (650–800 GF SP)</td><td>LOW — linear-algebra verifiers on reversible-circuit checking</td><td><a href="https://www.superfri.org/index.php/superfri/article/download/178/598">Superfri 2018</a></td></tr>
|
||
<tr><td><code>cuda-hash-join-radix</code></td><td>4 B tuples/s single; <strong>1.8 T tuples/s on 1024 A100</strong></td><td>A100 cluster</td><td>MEDIUM — undefect CVE↔commit↔package joins</td><td><a href="https://adms-conf.org/2021-camera-ready/gao_adms21.pdf">ADMS-21</a></td></tr>
|
||
<tr><td><code>cuda-kmer-count</code></td><td>4–6× vs KMC2; ~2× Jellyfish/KMC1</td><td>RapidGKC, Gerbil</td><td>LOW — bioinformatics adjacency; identical bend-portal shape</td><td><a href="https://www.researchgate.net/publication/382499333_RapidGKC_GPU-Accelerated_K-Mer_Counting">RapidGKC</a></td></tr>
|
||
<tr><td><code>cuda-cgraph-traversal</code></td><td><strong>38 B TEPS</strong>; PageRank half-billion nodes in seconds</td><td>DGX2</td><td>MEDIUM — undefect dependency-DAG analytics, upstream call-graphs</td><td><a href="https://medium.com/rapids-ai/rapids-cugraph-multi-gpu-pagerank-363aed1a2503">cuGraph</a></td></tr>
|
||
<tr><td><code>cuda-triangle-count-TRUST</code></td><td><strong>~1 T TEPS</strong> (first trillion-TEPS triangle counter)</td><td>multi-A100</td><td>MEDIUM — community-structure detection for twitter-x-punters</td><td><a href="https://arxiv.org/pdf/2103.08053">TRUST</a></td></tr>
|
||
<tr><td><code>cuda-ldpc-bp-decoder</code></td><td>10 Gbps with early-termination</td><td>GPGPU</td><td>LOW — PQ-KEM noise modelling, SDR experiments on radio nodes</td><td><a href="https://www.mdpi.com/2079-9292/11/21/3447">MDPI Electronics 2022</a></td></tr>
|
||
<tr><td><code>cuda-nvcomp-zstd</code></td><td>2.2× decompress (zstd); 1.4× LZ4; 1.9× snappy</td><td>H100 / A100</td><td>HIGH — undefect corpus shards, lumbda portal envelopes, permacomputer ingest</td><td><a href="https://docs.nvidia.com/cuda/nvcomp/">nvCOMP</a></td></tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>Wave 3 — surveyed 2026-06-05</h3>
|
||
<p>15 additional forms spanning ZK / SNARK provers, pairing crypto, tensor network contraction, sparse linear algebra, CV primitives, numerical solvers, generic belief propagation, MD/CFD kernels, convex optimization, DSP beyond cuFFT, DB aggregations, graph theory beyond triangle/PageRank. Sorted by reported speedup or absolute throughput descending.</p>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>form</th>
|
||
<th>speedup / throughput</th>
|
||
<th>hardware</th>
|
||
<th>relevance</th>
|
||
<th>ref</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr><td><code>cuda-fluidx3d-lbm</code></td><td><strong>100–200×</strong> vs ANSYS Fluent / OpenFOAM; 8,799 MLUPS single A100</td><td>A100</td><td>unsandbox MEDIUM (HPC reproducibility, OpenCL backend matches our fleet)</td><td><a href="https://github.com/ProjectPhysX/FluidX3D">FluidX3D</a></td></tr>
|
||
<tr><td><code>cuda-mfcc-spectral</code></td><td><strong>~97×</strong> CPU MFCC; STFT ~75× via cuSignal vs SciPy</td><td>GTX 580 / RTX 30-series</td><td><strong>unsandbox HIGH</strong> — punters-cc, BT-DISC forensics, real-time CC pipeline</td><td><a href="https://developer.nvidia.com/blog/accelerated-signal-processing-with-cusignal/">cuSignal</a></td></tr>
|
||
<tr><td><code>cuda-batched-lp-simplex</code></td><td><strong>95×</strong> over CPLEX; 5× over GLPK on a batch of 100K LPs</td><td>GTX 980-class</td><td><strong>unsandbox HIGH</strong> — resource scheduling, Prime Mission workstation balancing</td><td><a href="https://arxiv.org/pdf/1802.08557">arXiv 1802.08557</a></td></tr>
|
||
<tr><td><code>cuda-betweenness-centrality-weighted</code></td><td><strong>30–150×</strong> warp-centric weighted BC</td><td>GTX onwards</td><td><strong>undefect HIGH</strong> — workaholic-node detection on dependency DAG, directly matches MOAD-0001 model</td><td><a href="https://arxiv.org/pdf/1701.05975">arXiv 1701.05975</a></td></tr>
|
||
<tr><td><code>cuda-cudasift-orb-ransac</code></td><td>~60× SIFT CPU→GPU (11 fps 1920×1440); 1.2 ms on GTX 1060; ORB 11.3×</td><td>GTX 1060+</td><td>unsandbox MEDIUM (visual evidence pipeline for incident reports)</td><td><a href="https://github.com/Celebrandil/CudaSift">CudaSift</a></td></tr>
|
||
<tr><td><code>cuda-cudasw-gasal2</code></td><td>CUDASW++4.0 <strong>16.2×</strong> over v3.0; 134× over ADEPT; <strong>5.71 TCUPS on H100</strong>; GASAL2 packing 750× vs NVBio</td><td>H100 (TCUPS)</td><td>undefect MEDIUM (binary-diff & patch-similarity at scale: SW reduces to opcode-sequence diff)</td><td><a href="https://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-024-05965-6">CUDASW++4.0</a></td></tr>
|
||
<tr><td><code>cuda-loopy-bp-mrf</code></td><td><strong>45×</strong> over CPU LBP for stereo MRF inference</td><td>GTX 280-class+</td><td><strong>undefect HIGH</strong> — LBP substrate for FuzzingBrain-style probabilistic program analysis</td><td><a href="https://arxiv.org/pdf/2509.22337">arXiv 2509.22337</a></td></tr>
|
||
<tr><td><code>cuda-sgm-stereo</code></td><td><strong>42 fps</strong> at 640×480 with 128 disparities on Tegra X1; 46 fps on discrete GPUs</td><td>Tegra X1 / discrete</td><td>unsandbox MEDIUM (embedded ARM+CUDA matches our edge node profile)</td><td><a href="https://arxiv.org/abs/1610.04121">arXiv 1610.04121</a></td></tr>
|
||
<tr><td><code>cuda-hungarian-lap</code></td><td>10–50× class; 400 M-variable LAP in <strong>~13 s</strong></td><td>NVIDIA GPU</td><td><strong>unsandbox HIGH</strong> — workstation-to-queue balancing per Prime Mission; defect-cluster ↔ patch-bundle assignment for undefect</td><td><a href="https://www.sciencedirect.com/science/article/abs/pii/S016781911630045X">ScienceDirect</a></td></tr>
|
||
<tr><td><code>cuda-msm-bls12-381</code></td><td><strong>27.86×</strong> over Pippenger (RELIC) AVX baseline; 60% of Groth16 prover time on single GPU</td><td>A100 / RTX 4090</td><td><strong>ECDSA HIGH</strong> — Pippenger bucket sort + multi-G1 arithmetic shares branchless modmul shape with our reversible secp256k1 inner loop</td><td><a href="https://tches.iacr.org/index.php/TCHES/article/download/12061/11906/13930">SimdMSM TCHES</a></td></tr>
|
||
<tr><td><code>cuda-pdwt-lifting</code></td><td><strong>15.9×</strong> over best optimized CPU DWT (lifting scheme)</td><td>GTX / Tesla</td><td>unsandbox MEDIUM (audio-IPC payload analysis, BT signal denoising)</td><td><a href="https://github.com/pierrepaleo/PDWT">PDWT</a></td></tr>
|
||
<tr><td><code>cuda-tensornet-contract</code></td><td>8–20× vs CuPy on contraction; tensor QR <strong>~100×</strong> vs Xeon 8480+; tensor SVD ~10×</td><td>A100</td><td><strong>ECDSA HIGH</strong> — alternative to stabilizer/kickmix sim path; MPS/PEPS evaluates reversible secp256k1 circuits beyond Clifford</td><td><a href="https://docs.nvidia.com/cuda/cuquantum/latest/cutensornet/index.html">cuTensorNet</a></td></tr>
|
||
<tr><td><code>cuda-ega-gpu-aggregation</code></td><td><strong>6.45–29.12×</strong> over CPU multi-pass EGA; group-by hash 19.4×</td><td>NVIDIA GPU</td><td><strong>undefect HIGH</strong> — defect-corpus aggregation at planetary scale; unsandbox HIGH — telemetry queue aggregation</td><td><a href="https://www.vldb.org/pvldb/vol17/p644-siddiqui.pdf">VLDB Top-k EGA</a></td></tr>
|
||
<tr><td><code>cuda-bicgstab-ilu-spmv</code></td><td>SpTRSV 10.7×; ILU0 BiCGSTAB 3.2× vs cuSPARSE on MI210; GMRES(30) block-ISAI 1.4–6.9×</td><td>V100 / MI210</td><td>ECDSA MEDIUM (sparse LA over GF(p) underpins lattice / index-calc); undefect MEDIUM (spectral analysis on DAG)</td><td><a href="https://arxiv.org/pdf/2508.04917">arXiv 2508.04917</a></td></tr>
|
||
<tr><td><code>cuda-icicle-snark-groth16</code></td><td>ICICLE-Snark fastest Groth16 today; Mina GPU 3× over libsnark; NTT 91% of prover at large sizes</td><td>RTX 4090 / A100</td><td>ECDSA MEDIUM (zk + MSM stack shares finite-field discipline); undefect MEDIUM (zk-prover defect scanning)</td><td><a href="https://www.ingonyama.com/post/icicle-snark-the-fastest-groth16-implementation-in-the-world">ICICLE-Snark</a></td></tr>
|
||
</tbody>
|
||
</table>
|
||
<p><strong>Wave 3 filter-outs:</strong> AMGX algebraic multigrid (2–5×), GROMACS GPU (2–3×), NVOFA optical flow (7–10× borderline, dedicated hardware unit), Junction-tree BP per-message (0.68–9.18×), batched L-BFGS (134× single-case, not generalized). All below 10× or insufficiently general; revisit when shape changes.</p>
|
||
|
||
<h3>Skipped — revisit when shape changes</h3>
|
||
<ul>
|
||
<li><strong>Argon2 / scrypt</strong>: ~1000 H/s on Tesla K20X is the <em>whole point</em> of memory-hard KDFs. Not a speedup story; only worth listing in an attack-surface doc.</li>
|
||
<li><strong>cuRAND alone</strong>: already bundled inside Monte Carlo + ChaCha20 forms; not a wire-protocol form by itself.</li>
|
||
<li><strong>GP regression / variational inference</strong>: current GPU wins are 2–4×, below Pareto-frontier threshold for public catalog.</li>
|
||
<li><strong>Generic ML inference</strong>: out of scope for this catalog — covered better by upstream frameworks.</li>
|
||
<li><strong>cuda-batched-mcts</strong>: 25–40× on Go-style rollouts; wrong shape for our current candidate search.</li>
|
||
<li><strong>cuda-faiss-ann</strong>: 5–12× over CPU FAISS; no embedding workload today.</li>
|
||
</ul>
|
||
|
||
<h3>Why a form earns its slot</h3>
|
||
<p>A form is GPU-worth-it when at least one of:</p>
|
||
<ol>
|
||
<li><strong>Embarrassingly parallel.</strong> N independent items, no cross-item dependency. SHAKE fan-out, batched mod-mul, bulk point-add — each thread owns one item.</li>
|
||
<li><strong>Dense, branch-free inner loop.</strong> Same operation on every element. Matrix-vector, convolution, bit-twiddling sweeps.</li>
|
||
<li><strong>Reduction-friendly.</strong> Tree-reduce / prefix-sum / parallel-scan patterns GPU hardware accelerates natively.</li>
|
||
<li><strong>Big batch amortizes fixed kernel overhead.</strong> Our <code>cuda-sim-ops-bin</code> shows ~5 s kernel overhead; only worth it past ~115 batches.</li>
|
||
</ol>
|
||
<p>When none of these hold, do not force the problem onto GPU. Find a different decomposition: parallelize on a different axis (per-candidate instead of per-shot), or stay on CPU & fan out across fleet hosts.</p>
|
||
</section>
|
||
|
||
<section id="next">
|
||
<h2>Recommended build order</h2>
|
||
<ol>
|
||
<li><strong>A — <code>cuda-secp256k1-batched-mul</code></strong>: biggest immediate win. VanitySearch's CUDA secp256k1 kernel hits 6.5 Gkeys/s on a 4090; bend gets a GPU-rate point-mul oracle for candidate validation.</li>
|
||
<li><strong>D — <code>cuda-clifford-stabilizer</code></strong>: the right axis fix for our 1.07× <code>cuda-sim-ops-bin</code> ceiling. Reshape circuit-sim per-candidate-parallel; targets a Clifford fragment via STABSim-style tableau.</li>
|
||
<li><strong>B — <code>cuda-bignum-cgbn</code></strong>: foundational layer. Generic 256-bit vocabulary lumbda calls without committing to a curve.</li>
|
||
</ol>
|
||
<p>Forms E, C, G follow once A–D give us measured numbers on our hardware. F & below revisit when our shape changes.</p>
|
||
</section>
|
||
|
||
<section id="source">
|
||
<h2>Source & specs</h2>
|
||
<p>
|
||
<a href="https://git.unturf.com/engineering/unturf/lumbda/-/blob/master/examples/cuda-fanout/">examples/cuda-fanout/</a> — wire contract, daemon protocol, bench data, per-tier integration sketch.<br>
|
||
<a href="https://git.unturf.com/engineering/unturf/lumbda/-/blob/master/examples/cuda-fanout/CATALOG.md">CATALOG.md</a> — canonical source for form metadata; this page renders from the same data.
|
||
</p>
|
||
</section>
|
||
|
||
</main>
|
||
|
||
<footer>
|
||
<p>
|
||
<a href="index.html">lumbda.com</a>
|
||
·
|
||
<a href="https://git.unturf.com/engineering/unturf/lumbda">source</a>
|
||
·
|
||
<a href="lumbda-whitepaper.html">whitepaper (HTML)</a>
|
||
·
|
||
<a href="lumbda-whitepaper.pdf">whitepaper (PDF)</a>
|
||
·
|
||
<a href="https://unturf.com">unturf.com</a>
|
||
</p>
|
||
</footer>
|
||
|
||
</body>
|
||
</html>
|