Dynamic benchmark

Two builds, one shape

The comparison is meaningful only when both paths do the same work at the same shape. Static means the kernel was compiled with M, N, K in the types; dynamic means it reads them at runtime. Same buffers, same seed, same reference check, same session, interleaved.

path      shape    median      spread    samples
static    512       <median>    <spread>  20
dynamic   512       <median>    <spread>  20
dynamic   500       <median>    <spread>  20

The static-versus-dynamic ratio at 512 is the headline. It is not the cost of shape handling in the narrow sense: the static build also unrolls differently, folds strides, and drops the tensor.dim and the masks. Call it the cost of genericity, then decompose it if you need to. One useful pair is dynamic dims with a peeled static interior against dynamic dims with affine.min in every iteration; the difference between those isolates the tail machinery from the dimension arithmetic.

Keep the compiler honest

If the dynamic entry point is called with constants, the compiler can clone and specialize it, and you measure the static path twice. Pass the extents through argv or a volatile read, and check the IR for arith.constant where a tensor.dim should be. The same check catches a pipeline that constant-folds a guard you believed was runtime.

Report the dynamic number at a size the static build cannot run, too. A dynamic kernel that is only fast at 512 has specialised itself by accident, and the second shape is what shows it.

Things that break

Comparing static 512 against dynamic 1000 measures a different amount of work. Forgetting the reference check in the dynamic build lets a broken fast path set the headline. And a ratio whose bands overlap is not a result; the static and dynamic medians have to clear the spread before the delta can be called the cost of genericity.