gpuemu vs torch.allclose / torch.testing.assert_close
torch.allclose is the field-standard kernel correctness check — one shape, one dtype, one seed. In a measured 26-op corpus it caught 0/9 LLM-style bugs. gpuemu's operator-aware regime caught 9/9.
| Capability | gpuemu | torch.testing.assert_close |
|---|---|---|
| Multiple shapes per op | Yes | No |
| Adversarial / boundary inputs | Yes | No |
| fp64 reference oracle | Yes | No |
| Per-op calibrated tolerances | Yes | No |
| Byte-for-byte failure replay | Yes | No |
| Static PTX/SASS lint | Yes | N/A |
| In-tree, zero-dependency | Partial | Yes |
torch.testing.assert_close (and torch.allclose) is the standard, simple, in-tree way to
assert two tensors match. Almost every kernel test and every LLM-kernel benchmark uses it.
The problem isn’t the function — it’s how it’s used as a correctness oracle: one shape, one dtype, one seed. That configuration is structurally blind to tail-mask leaks, accumulator-scale bugs, and online-softmax rescale errors, because those only fire on specific shapes the test never picks.
In our measured 26-op corpus, the one-shape oracle accepted 9/9 LLM-style buggy kernels. gpuemu’s regime — fp64 oracle + op-schema fuzzing + calibrated tolerances — caught all nine with zero false positives on fifteen controls.
Use both: keep assert_close for unit assertions; add gpuemu as the correctness gate.
Frequently Asked Questions
Isn't gpuemu just assert_close in a loop?
No. assert_close compares two tensors at fixed tolerance. gpuemu generates op-schema-aware adversarial inputs, computes a high-precision fp64 reference, calibrates tolerance per op and dtype, and snapshots every failing input for replay. The loop is the least of it.