Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: jseigh <jseigh_es00@xemaps.com>
Newsgroups: comp.arch
Subject: Re: Is Intel exceptionally unsuccessful as an architecture designer?
Date: Sat, 21 Sep 2024 18:49:20 -0400
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <vcnihg$1ono3$2@dont-email.me>
References: <memo.20240913205156.19028s@jgd.cix.co.uk>
 <vcda96$3p3a7$2@dont-email.me>
 <21028ed32d20f0eea9a754fafdb64e45@www.novabbs.org>
 <RECGO.45463$xO0f.22925@fx48.iad> <20240918190027.00003e4e@yahoo.com>
 <vcfp2q$8glq$5@dont-email.me> <jwv34lumjz7.fsf-monnier+comp.arch@gnu.org>
 <vckpkg$18k7r$2@dont-email.me> <vckqus$18j12$2@dont-email.me>
 <920c561c4e39e91d3730b6aab103459b@www.novabbs.org>
 <vcl6i6$1ad9e$1@dont-email.me>
 <d3b9fc944f708546e4fbe5909c748ba3@www.novabbs.org>
 <%dAHO.54667$S9Vb.39628@fx45.iad> <vcna56$1nlod$2@dont-email.me>
 <a7708487530552a53732070fe08d9458@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 22 Sep 2024 00:49:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b1159e7e7c889c486126828359848369";
	logging-data="1859331"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/4608Mss03s0EsEQT7jVG4"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:YIlaocBCJnaoWdGQXs+kuwax8Dc=
In-Reply-To: <a7708487530552a53732070fe08d9458@www.novabbs.org>
Content-Language: en-US
Bytes: 2926

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.

Joe Seigh