This is a special post for quick takes by leogao. Only they can create top-level comments. Comments here also appear on the Quick Takes page and All Posts page.
i think it would be pretty valuable for someone to look into how to do really good compute exhaustion for treaty verification. a key insight is that unlike memory optimization, where it's very difficult to know for sure how much memory a workload should use; in some sense, it is basically impossible to reduce the number of matmul flops via optimizations without serving a different model, and all optimizations are just about using more of the possible matmul cycles. i'd be excited to fund good work on this. some problems that would need to be handled:
hardware lottery: gpus naturally have variance in how good they are. nobody really knows if this changes a lot over time as gpus age. need to design the protocol to be robust to this, maybe can hardwire clock speeds? https://arxiv.org/abs/2208.11035
the nameplate flop numbers are completely bullshit. gpus can almost never sustain that level of workload. there is literally a physical limitation that the chip cannot deliver enough power to constantly run the tensor cores.
ideally we want to use up every single possible matmul cycle. this means not just launching time-filling kernels, but ideally injecting code into normal matmul kernels to fill in the gaps created by shmem loads or whatever. good to figure out if this is even possible.
for the PoW, ideally we want to estimate the compute spent within like 0.1% of the true amount; this might rule out some naive probabilistic approaches depending on details.
it would be nice to be confident that the hash function is actually strong and not easily cheatable
it would be nice to double check how much error strassen would introduce, and whether that's enough to detect defection