Related anecdote, a coworker suggested I use <a href="https://pkg.go.dev/math#FMA" rel="nofollow">https://pkg.go.dev/math#FMA</a> to optimize a multiply and add which surprised me quite a bit: why would there be an opt-in to fused multiply and add? Indeed, if you dive into the code (<a href="https://cs.opensource.google/go/go/+/refs/tags/go1.21.5:src/math/fma.go;l=95" rel="nofollow">https://cs.opensource.google/go/go/+/refs/tags/go1.21.5:src/...</a>) it's quite a bit more complicated than your normal a*x+b syntax, so how could this possibly yield a performance improvement?<p>It turns out, with some more research (<a href="https://github.com/golang/go/issues/25819">https://github.com/golang/go/issues/25819</a>), that the function was added not to guarantee performance but to guarantee <i>precision</i>, namely that fused mutiply and add yields higher precision than doing the operations stepwise and in certain situations you'd like to guarantee precision. Which is cool, but absolutely not what I would've guessed on first read, and the first commenter also closed the issue with the same take!<p>So I was able to successfully counterpoint using math.FMA() as a performance optimization and maybe a small personal takeaway to not optimize unless I really know what the thing is doing.