Re: Is Intel exceptionally unsuccessful as an architecture designer?

On 9/21/2024 3:49 PM, jseigh wrote:

On 9/21/24 16:45, MitchAlsup1 wrote:

On Sat, 21 Sep 2024 20:26:13 +0000, Chris M. Thomasson wrote:
>

On 9/21/2024 6:54 AM, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:
https://www.marvell.com/products/cxl.html

>
What about a weak coherency where a programmer has to use the correct
membars to get the coherency required for their specific needs? Along
the lines of UltraSPARC in RMO mode?

>
In my case, I suffered through enough of these to implement a
memory hierarchy free from the need of any MemBars yet provide
the performance of <mostly> relaxed memory order, except when
certain kinds of addresses are touched {MMI/O, configuration
space, ATOMIC accesses,...} In these cases, the core becomes
{sequentially consistent, or strongly ordered} depending on the
touched address.

 Well, we have asymmetric memory barriers now (membarrier() in linux)
so we can get rid of memory barriers in some cases.  For hazard
pointers which used to be a (load, store, mb, load) are now just
a (load, store, load).  Much faster,  from 8.02 nsecs to 0.79 nsecs.
So much so that other things which has heretofore been considered
to add negligible overhead are not so much by comparison.  Which can
be a little annoying because some like using those a lot.

Getting rid of a #StoreLoad memory barrier is very nice, indeed. This actually helps x86. Well, "original" SMR (aka, hazard pointers) on x86 needs a membar. MFENCE or a locked rmw.
WRT SPARC in RMO mode, well, iirc, it (SMR) needed a
MEMBAR #StoreLoad | #LoadStore | #LoadLoad | #StoreStore
not just a #StoreLoad | #LoadStore
?