Re:Examining ARM vs. x86 Memory Models with Rust
by Jweb_Guru on Saturday June 27, 2020 @04:59AM
(#23660469)
Because ensuring release/acquire for every operation (at least in the x86 way) requires supporting total store order, which requires much stronger cache coherence in the normal (no barrier) case and hence results in a lot more bus traffic. ARM didn't just make the memory model weaker for no reason.
[ Parent
| on HN ]
Re:Examining ARM vs. x86 Memory Models with Rust
by BeeOnRope on Saturday June 27, 2020 @09:02AM
(#23661588)
I am pretty sure this is not correct. Every reordering effect I'm aware of is a core-local effect. That is, it happens in the core before (or at the moment) the data hits the L1D. It does not occur due to a weaker cache coherence system.
Having a cache coherence system which was itself weaker, allowing reorderings consistent with the memory model, makes barriers and "implicit barriers" like address dependencies very expensive, and there is little evidence this is the case.
Even in a hypothetical core which had a cache coherency system coupled to the memeory model, you aren't really avoiding any coherence traffic, just allowing certain reorderings such as satisfying requests out of order.
Re:Examining ARM vs. x86 Memory Models with Rust
by bestboy on Saturday June 27, 2020 @06:20AM
(#23660823)
Seems plausible to me. I guess it would be pretty hard to maintain a TPD of about 200W for 80 3GHz ARM cores [1]. The bus traffic to synchronize 80 CPU caches can probably be significant.
[1] https://www.anandtech.com/show/15871/amperes-product-list-80...