CS3 claims a huge matrix multiply takes ~20 µs on a card like yours. Claims get tested. This page runs the SAME multiply two ways — plain JavaScript on one CPU core, then a WebGPU compute shader on your 5090 — and puts the real numbers on your screen.
Predict → Measure → Explain the gap. The run buttons stay locked until your predictions are written. Being wrong by 10× is a finding, not a failure — explaining WHY is the artifact.
| Question | Your prediction (before running!) |
|---|---|
| 1024×1024 matrix multiply, plain JS, one core — how long? | |
| Same multiply on your GPU — how long? | |
| Array ADD (low math per byte) — will the GPU speedup be bigger or smaller than for matmul? Why, in one CS3 word? |
write all three predictions to unlock the lab ↓
| Run | Median time | Ops | GFLOP/s | Note |
|---|
One page, four headings: Question → Method → Data (your table above, copied) → Verdict. Include: did the CS3 20 µs claim survive contact with your hardware — and what exactly does "it depends on the baseline" mean now that you've been the one choosing baselines? Bring it Sep 26. That's artifact v1 of your engineering line.
Boss extension: run 512 then 1024 on CPU. CS3 Q7 says work grows as n³ — so 1024 should take ~8× longer than 512. Does it? If reality disagrees, you've just met cache effects. Welcome to real hardware.
One machine, one afternoon, one matrix size. This measures your 5090 against your CPU on this kernel — it is not a verdict on GPUs, on NVIDIA, or on anyone else's hardware. It cannot separate the chip from the driver, the driver from the browser, or any of them from whatever else your machine was doing at the time. And a speedup quoted without naming what it is a speedup over is worth nothing, which is why the baseline is printed next to every number here.
Say all of that out loud when you report the result. Naming the limits is not a weakness in the finding — it is the part that makes the rest of it believable.