Re:Examining ARM vs. x86 Memory Models with Rust
by BeeOnRope on Saturday June 27, 2020 @08:52AM
(#23661524)
Reordering rarely or never comes from "cache coherence" on CPUs, but rather core local effects like store buffering, out of order execution, coalescing and out of order commit in the store buffer, etc.
Re:Examining ARM vs. x86 Memory Models with Rust
by ajross on Saturday June 27, 2020 @09:24AM
(#23661717)
I don't follow your point. Ordering control is necessarily a feature of the cache layer. You're right that there are local pipeline effects too, but if you have a memory ordering requirement in your architecture it has to be built into the cache design all the way up and down the hierarchy.
In practice that's the stuff that's expensive.
Re:Examining ARM vs. x86 Memory Models with Rust
by BeeOnRope on Saturday June 27, 2020 @09:28AM
(#23661734)
I'm saying that everyone making CPUs uses a strongly ordered cache coherency subsystem and re-ordering only comes from "pipeline effects" [1].
Slightly longer version of the same claim here:
https://news.ycombinator.com/item?id=23661588
---
[1] I prefer the term core-local because I think it's somewhat more accurate as it can include things like the delayed processing of invalidations and sibling core interactions in SMT which might not fall under "pipeline" effects but are still local to the (physical) core.
Re:Examining ARM vs. x86 Memory Models with Rust
by ajross on Saturday June 27, 2020 @10:20AM
(#23661984)
That may well be true in ARM application processors, at least between CPUs. Though nothing in the architectural memory model guarantees that so I'd be surprised if there weren't some surprises (DMA on most of those CPUs is upstream of the cache, for example, and not susceptible to that kind of optimization).
I can guarantee it's not for "everyone making CPUs". I'm literally writing code as we speak on a multi CPU cache-incoherent system. It's a big world.
Re:Examining ARM vs. x86 Memory Models with Rust
by jeffreygoesto on Saturday June 27, 2020 @12:01PM
(#23662609)
TriCore by any chance? ;-)
Re:Examining ARM vs. x86 Memory Models with Rust
by ajross on Saturday June 27, 2020 @12:14PM
(#23662675)
Xtensa
Re:Examining ARM vs. x86 Memory Models with Rust
by Retr0spectrum on Saturday June 27, 2020 @08:37AM
(#23661444)
The cost in terms of transistors may be small, but what about performance? (This is not a rhetorical question, I'm curious to know)
Re:Examining ARM vs. x86 Memory Models with Rust
by ajross on Saturday June 27, 2020 @09:27AM
(#23661730)
The fastest general purpose CPUs in the world implement a strongly ordered architecture, so clearly it can be done.
Re:Examining ARM vs. x86 Memory Models with Rust
by throwaway_pdp09 on Saturday June 27, 2020 @12:27PM
(#23662755)
My question was exactly @Retr0spectrum's, the cost in performance, but I don't accept your answer (yet). I presume you mean intel and intel has a large transistor budget to burn, and quite like did to get that fastest perf. If you don't have to enforce strong ordering, how much extra a) actual speed b) transistor budget could you free up?
(not a hardware guy
May. Not will. The difference here is important, because the actual memory ordering presented is an issue of hardware implementation choice (and of course the local vagaries like cache line alignment, interrupt order and the behavior of other CPUs on the bus). You can't just write some sample code to demonstrate it and expect it's going to work the same on "ARM".
In fact I'd be really curious how Apple handles this during the Mac transition. I wouldn't be at all surprised if, purely for the sake of compatibility, they implement an strongly ordered x86-style cache hierarchy. Bugs in this world can be extremely difficult to diagnose, and honestly cache coherence transistors aren't that expensive relative to the rest of the system.