On Wed, 8 May 2024, Thiago Macieira wrote:

> On Wednesday 8 May 2024 11:17:51 GMT-7 Nate Eldredge wrote:
>> In the code you linked, I only saw a generic compare-exchange
>> implementation. Have you tried at all to create any machine-specific
>> implementations, using inline assembly for LL/SC and/or RMW instructions
>> where available? I'd be curious what kind of code the compiler can
>> produce. If you haven't, I might try my hand at it, just for fun.
>
> Yes, I tried writing x86-specific code. That's why I began this: so I could use
> the new CMPccXADD instructions. The tests that I added do show the compiler
> emits the correct instructions (by way of the intrinsic).

Oh yes, now I see that part of the code. Interesting!

> I have no interest in writing code for other architectures.

Understandable, given who you work for :) I might try an ARM
implementation sometime as an exercise for myself.

> More complex operations are troublesome. It's highly unlikely the hardware
> will implement that in single or few instructions, so it's only going to work
> with LL/SC and you have to know whether the operation is acceptable in that
> block. For example, I could see some low-power architectures not having a
> divide instruction, thus an operation that attempted a division always failing
> (or even if such an instruction is present, it taking 70-100 cycles to
> complete may be too much).
>
> It might be important to know whether the particular sequence of operations is
> loop-free or not.

Right, which goes back to the idea of falling back to compare-exchange.

> On the other hand, implementing a compare-exchange loop with proper PAUSE
> hints and backoffs is important too. Improper looping shows up on our
> benchmarking a dozen times a year...

That's a good point, and again, not something that can be done portably as
it stands.

Thanks for the discussion!

-- 
Nate Eldredge
nate_at_[hidden]