Related anecdote, a coworker suggested I use https://pkg.go.dev/math#FMA https://pkg.go.dev/math#FMA to optimize a multiply and add which surprised me quite a b

Related anecdote, a coworker suggested I use https://pkg.go.dev/math#FMA https://pkg.go.dev/math#FMA 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 (https://cs.opensource.google/go/go/+/refs/tags/go1.21.5:src/math/fma.go;l=95 https://cs.opensource.google/go/go/+/refs/tags/go1.21.5:src/...) it's quite a bit more complicated than your normal a*x+b syntax, so how could this possibly yield a performance improvement? It turns out, with some more research (https://github.com/golang/go/issues/25819 https://github.com/golang/go/issues/25819), that the function was added not to guarantee performance but to guarantee precision, 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! 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.