TL;DR — A reviewer asked what my GPU DuckDB extension does to whole queries, not just kernels. I measured it honestly: native DuckDB won every shape, 3×–109×. I published that table in my own release notes. Writing it down forced the structural diagnosis, and the very next release closed every cell to within 0–20% of native — by removing the GPU from the SQL hot path. On unified memory, that was the fix.
I maintain , someone asked the question every GPU project dreads:
Your scorecard measures the operator on resident data. What does a user actually see when they run a whole query through the full pipeline?
The benchmark I didn't want to run
Rewritten TPC-H Q6 and Q1 plus a high-cardinality GROUP BY, through the stock DuckDB CLI v1.5.2, SET threads=16, warm cache, median of 5 runs, correctness gated before timing (the Q6 total matches the published TPC-H reference answer). Both sides cast ::DOUBLE identically.
Native won everything:
| Query shape | native | gpu_sum (v0.2.0) | native advantage |
|---|---|---|---|
| Q6 · SF1 | 0.002 s | 0.006 s | ~3× |
| Q6 · SF10 | 0.017 s | 0.057 s | ~3.4× |
| Q1 · SF1 | 0.011 s | 0.33 s | ~30× |
| Q1 · SF10 | 0.098 s | 3.45 s | ~35× |
| GROUP BY l_orderkey · SF1 | 0.010 s | 0.944 s | ~86× |
| GROUP BY l_orderkey · SF10 | 0.092 s | 11.05 s | ~109× |
I put that table in ) showed up with a real Metal hash join + on-device segment reduce ( · .
SOCIAL SHARE CARD GENERATOR