News for hackers. Stuff that matters.
Re:TIL: Go's CompareAndSwap is not always Compare-and-swap by kevmo314 on Monday January 08, 2024 @02:57PM (#38917219)
Related anecdote, a coworker suggested I use 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/...) 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), 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.

Re:TIL: Go's CompareAndSwap is not always Compare-and-swap by dominikh on Monday January 08, 2024 @04:19PM (#38918296)
Note that the source you're seeing there is the fallback implementation, which is only used if there is no instruction for FMA in the architecture you're compiling for. On AMD64, for example, the call to math.FMA will be replaced by the VFMADD231SD instruction.
Re:TIL: Go's CompareAndSwap is not always Compare-and-swap by pcwalton on Monday January 08, 2024 @06:54PM (#38920287)
In fact, on AArch64 there is no integer multiply instruction; there's only multiply-add, and if you just want a multiply you supply the zero register as the addend.