> std::atomic<float> and std::atomic<double> are lock-free on major
> implementations, so there's no mutex. Typically fetch_add and friends are
> implemented with a compare-exchange loop.

Oh, right, I hadn't thought of that. My bad, it was right there.

What this means, though, is that the cost of manipulating the floating point
environment in the processor state is non-negligible.

On x86 without SSE2, it would be expensive x87 instructions to save and reload the state. Note that the FP state setup doesn’t need to happen within the retry loop.

If the chip has SSE2, the compiler could use something like:

stmxcsr [rsp]

ldmxcsr [value_00001F80]

retry:

movss xmm1, [rdi]

mov eax, [rdi]

addss xmm1, xmm0

movd ecx, xmm1

lock cmpxchg [rdi], ecx

jnz short retry

ldmxcsr [rsp]

LDMXCSR has a 7-cycle latency, but this whole sequence’s timing is dominated by the 100+-cycle lock cmpxchg.

I don’t know anything about the timing for changing the FP state nor the two types of atomic operations (LL-SC form and the newer x86-like CAS instruction).

Melissa