Travis (travis.downs.delete@this.gmail.com) on August 19, 2018 2:07 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on August 19, 2018 12:22 pm wrote:
> >
> > It depends on HOW your system is organized. Consider the current iPhone, which appears (as far as I can
> > tell) to have a low latency (12..15 cycle or so) large L2 that covers the large+small CPUs (but not the
> > GPU or IO). For that sort of system "near remote" atomics seem like a pretty good win for many purposes.
>
> Why are they a win? Even if you can do it all in L2, you are probably doubling the cost or worse.
>
> > Half of ARC references are remote only (increments); the other half depend on the
>
> You chose a convenient naming here: "remote only" - but you really mean "the result is not examined, right"?
> Why do it remotely when you could do it locally which is much faster? After you increment, you are probably
> decrementing most of the time pretty soon, so even more reason to bring it into the cache.
>
> > result (decrements, testing against zero). I don't know, given GCD usage these days,
> > how much transitioning there is between CPUs (including large to small CPUs).
>
> Probably less one out of a million decrements are done on a thread (not CPU) different than the
> one that incremented it. Most reference counts probably never exceed two and are never shared.
> That's just the overwhelming use of references/pointers/smart-pointers in every language.
>
> Of course sometimes you migrate CPUs, but then you are talking about the huge cost of moving over all
> the core-private caches (perhaps just L1 in the A* cores case), so having a few lines living in L2 helps
> pretty much not at all (logically, that "migrated cores" argument leads to getting rid of the L1 entirely
> and keeping everything in L2 just because of core migration - an obvious non-starter).
>
> Also, the reference count is presumably tightly packed with the object data itself, or other
> interesting, unshared data in the same cache line: so it's not like you can just point at
> the reference count and force it to live in L2, since it applies to the entire line.
>
> Note the level that sharing occurs at doesn't really matter much for this argument: closer to the core
> sharing makes "remote" atomics faster, but it also means the downside of the normal local atomics when
> actual sharing occurs is much less so the gain for remote in that scenario is correspondingly reduced.
>
> > I also don't know how much quasi-common "occasionally" updated
> > material (like comm-pages, and OS data structures)
> > exists that's best thought of and treated as living in common L2 rather than on a particular CPU.
>
> Practically nothing. Again you are begging the argument by implicitly linking "quasi-common occasionally
> updated material" with "best thought of and treated as living in common L2". That's the problem.
> Common, rarely updated data is best living right next to the core(s) that need it, just like
> all other data: duplicated in many L1s if needed. You don't screw the common case (loads of the
> shared lines directly from L1), just to speed up the uncommon update case.

You may be correct, I am suggesting this stuff as hypotheticals, not as definites.

However I am leery of the sort of arguments you are giving for the reasons I gave; I am quite willing to accept that many readers here are extreme experts on the best way of doing things FOR SPECIFIC TARGETS TODAY. That's rather different from the best way of doing different things, given different constraints.
To give just one example (different from what we are saying, but same point) if you were to describe a language like Objective C, to most of the denizens of this board, that's a horrible idea along multiple dimensions. Way too much time wasted on run-time resolution of indirect calls that "should" be resolved at compile time. And by some lights that's a good argument; but by other lights it's a terrible argument because it's optimizing for the wrong thing.

What WOULD I consider convincing data that remote atomics are a silly idea?
One possibility would be a design document from ARM describing why they added them, the problems they want to solve, and the problems they do NOT see them solving. Another would be internal discussions from Apple about what's expensive and what's not in the current OS+runtime. (Such discussions are rare but do occasionally surface; there was one late last year talking about what works well vs badly in GCD, and where that system should evolve to). Another would be academic papers talking about systems (real or simulated) that use remote atomics and where that is vs is not a good idea.