Casey debunks the divide-vs-multiply performance myth
- https://www.youtube.com/watch?v=pslodI0Mh_0
- Original title: Casey Destroys Optimization Myths | TheStandup
- (TheStandup with Casey Muratori, TJ, Trash et al.)
A comedic "standup" episode whose technical core is Casey Muratori taking apart a viral tweet that said "don't use division, use reciprocal multiplication instead." Casey explains why the advice is misleading on both correctness and performance grounds.
The tweet claimed replacing `x / pi` with `x * (1/pi)` in a loop is a free speedup, citing 20–40 cycles for a divide. Casey's three objections:
- Correctness — inverting then multiplying is not the same answer in floating point. He gives an accessible explanation of float representation (sign / exponent / mantissa, the "floating" point) and why finite precision means the inverted result can differ enough to matter in scientific computing (though never for a UI element). The classic `0.1 + 0.2 = 0.30000…04` is the same root cause, not a JavaScript bug.
- Wrong cycle counts — on a modern Zen 4/5 chip a float divide has ~<10 cycle latency, not 20–40 (that number likely came from ChatGPT). More importantly, in a load–op–store loop nothing waits on the result, so what matters is throughput: multiply ~0.5 cycles, divide ~2–3 cycles.
- It usually doesn't matter — the loop is bounded by memory (L1/L2 cache latency, bandwidth), so the divide overlaps with other work and the "optimization" is often pointless.
The meta-lesson: out-of-context perf rules ("always invert," "always/never memset") make people optimize the wrong thing. Performance requires actually understanding the machine — a few weeks of learning, not a tweet. Casey also notes integer divide is genuinely slow, and people often conflate it with the cheap float divide.