Maynard Handley (name99.delete@this.name99.org) on August 18, 2018 2:42 pm wrote:

> compressed pages), or remote atomics (to speed up common atomic operations like ARC increments);

We've been over this before, but remote atomics make no sense for the vast majority of code. A "remote atomic" necessarily has a latency of whatever shared thing is remote and doing the increment, so in the range of 10s of clocks for something like L3, or in the 100s of clocks if it happens in memory (or a bit less if in the memory controller).

Existing atomic operations are almost totally local operations, that work at "core speed", and don't require any coherence traffic at all (except when another core wants the line, just applies to non-atomics as well).

The overwhelming majority of the time when something line is operated on atomically, the last core to use that line was the same core. Making this case fast is really important.

Remote atomics is like throwing out the best case which almost always happens in favor of always worst-case behavior, just to make that worst-case behavior a little better. Now every atomic access in your program has to go out over long-latency, power sucking busses, and the core has to wait forever to get the result back (and it almost always does need the result, as in your ARC example).

It just makes no sense as an implementation of existing atomics.

Now there are some specific sharing patterns where it may work, but it would have to be a new instruction.