Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on August 22, 2018 3:07 pm wrote:
> anon (anon.delete@this.anon.com) on August 21, 2018 4:27 pm wrote:
> > I assume you mean each core sending a non-cache-coherent message off core somewhere (a memory
> > controller?) which atomically increments a single location. That's crazy. First of all you have
> > the same scaling problem, now you just offloaded it to the non-coherent messaging system and
> > the entity performing the remote atomic. Secondly, high performance use cases that would care
> > (like networking) literally count cache misses (or any type of operation that goes out of the
> > core). Adding one more per packet might cut your performance by double digit percentages.
>
> And yet there have been high-performance network processors implementing those. Take Freescale's QorIQ T4240:
> it had twelve cores (*) and remote atomics. They weren't cache-coherent but they also didn't go all the way
> to RAM since the logic was part of the system fabric and IIRC operated directly on the L3 caches.
>
> *) Which were really Bulldozer-like modules with a single front-end shared by two separate
> back-ends so you might as well consider it a 24-core machine depending on how you count.

Yeah I mean remote atomics do seem good for these kinds of "fire and forget" cases where you want to increment a value or whatever but don't care about the result. That kind of behavior is fairly limited however, to things like atomic counters and some types of lock unlock (but not lock).

Did any of these systems have remote atomics as their only atomic instructions, or where they always an optional behavior if you chose the remote atomic instructions? The latter idea makes sense to me, the first not so much.