Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Is Intel exceptionally unsuccessful as an architecture
 =?UTF-8?B?ZGVzaWduZXI/?=
Date: Tue, 24 Sep 2024 00:26:40 +0000
Organization: Rocksolid Light
Message-ID: <da4b40d27bc25009a42fb2c29c8c4b0a@www.novabbs.org>
References: <memo.20240913205156.19028s@jgd.cix.co.uk> <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> <vcprkv$2asrd$1@dont-email.me> <e2c993172c11a221c4dcb9973f9cdb86@www.novabbs.org> <vcqe6f$2d8oa$1@dont-email.me> <4f84910a01d7db353eedadd7c471d7d3@www.novabbs.org> <20240923105336.0000119b@yahoo.com> <6577e60bd63883d1a7bd51c717531f38@www.novabbs.org> <vcsmvq$2s1qd$2@dont-email.me> <23d9473740db6c0ecc7e1d4a2179c75e@www.novabbs.org> <vcsphq$2sh9d$1@dont-email.me> <b23480c6afdce45b31fb9ae2e2397846@www.novabbs.org> <vcsr4o$2sh9d$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3217557"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$DPF9Jja3k43v.TEo/lGTrOYX7CQ41.l3r72DV52bC5L7nWJQRjNYG
Bytes: 4025
Lines: 47

On Mon, 23 Sep 2024 22:46:47 +0000, Chris M. Thomasson wrote:

> On 9/23/2024 3:32 PM, MitchAlsup1 wrote:

>>
>> I got rid of all MemBars and still have a fairly relaxed memory model.
>
> That is interesting to me! It's sort-of "out of the box" so to speak?
> How can a programmer take advantage of the relaxed aspect of your model?
>
Touch a DRAM location and one gets causal order.
Touch a MM I/O location and one gets sequential consistency
Touch a config space location and one gets strongly ordering
Touch ROM and one gets unordered access.

You see, the memory <ordering> model is not tied to a CPU state, but
to what LD and ST instructions touch.
>
>>> Think of allowing a rouge thread to pound a CAS with random data wrt the
>>> comparand, trying to get it to fail... Of course this can be modifying a
>>> reservation granule wrt LL/SC side of things, right? Pessimistic (CAS)
>>> vs Optimistic (LL/SC)?
>>
>> Or methodological (ESM).
>
> Still, how does live lock get eluded in your system? Think along the
> lines of a "rouge" thread causing havoc? Banging on cache lines ect...
> ;^o

ESM switches modes automagically. It starts out as Optimistic, and when
that fails, it switches to methodological {note by the time the failure
has been detected, the core is now sequentially consistent and will be
performing the 'event' in program order and sequentially consistent.
Should the methodological event fail, the core will ask the ATOMIC
request granter using all of the addresses. IF this succeeds, then the
core is allowed to NAK interference so that it will succeed. Upon
success, those addresses are removed from the granter.

So, for example:: a timer goes off and every core tries to pick a
thread of the wait queue. The first access will likely fail, the
second access will fail but the granter counted the amount of
interference. So the third request is to a thread nobody else
is attempting to dequeue. First 2 requests were to the element
at the front of the queue, third requests is to a thread indexed
down the queue by the interference number.

Thus BigO( n^3 ) becomes BigO( 3 ). In practice BigO(n^3) becomes
BigO(ln2(n)) due to random arrival and departure.