Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.quux.org!i2pn.org!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: Mon, 23 Sep 2024 01:34:55 +0000
Organization: Rocksolid Light
Message-ID: <4f84910a01d7db353eedadd7c471d7d3@www.novabbs.org>
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> <vcprkv$2asrd$1@dont-email.me> <e2c993172c11a221c4dcb9973f9cdb86@www.novabbs.org> <vcqe6f$2d8oa$1@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="3077038"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$vSdafQT0D4JPfoh9wKTNoeoKLqiy0hJN25Rsh4.zoi9XWWRnMnG.6
Bytes: 5498
Lines: 91

On Mon, 23 Sep 2024 0:53:35 +0000, jseigh wrote:

> On 9/22/2024 5:39 PM, MitchAlsup1 wrote:
>> On Sun, 22 Sep 2024 19:37:02 +0000, Paul A. Clayton wrote:
>>
>>> On 9/21/24 4:45 PM, 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.
>>>
>>> If I understand correctly, atomic accesses (Enhances
>>> Synchronization Facility) effective use a complete memory barrier;
>>> software could effectively provide a memory barrier "instruction"
>>> by performing an otherwise pointless atomic/ESF operation.
>>>
>>> Are there no cases where an atomic operation is desired but
>>> sequential consistency is not required?
>>
>> Probably--but in the realm of ATOMICs it is FAR better to be
>> a bit slower than to ever allow the illusion of atomicity to
>> be lost. This criterion is significantly harder when doing
>> multi-location ATOMIC stuff than single location ATOMIC stuff.
>>
>>>                                         Or is this a tradeoff of
>>> frequency/criticality and the expected overhead of the implicit
>>> memory barrier? (Memory barriers may be similar to context
>>> switches, not needing to be as expensive as they are in most
>>> implementations.)
>>
>> The R in RISC stands for Reduced. An ISA devoid of MemBar is
>> more reduced than one with MemBars. Programmers are rarely
>> in a position to understand all the cases where MemBar are
>> needed or not needed {{excepting our own Chris M. Thomasson}}
>>
>
> Not quite sure what we are talking about here but I won't
> let that stop me from commenting. :)

Its a free forum

> As far as loads and stores go, if they are atomic then
> a load will not see a value that was not from some store.

When you include stores from devices into memory, we agree.
A LD should return the last written value.

When you include device control registers; all bets are off.

> Regarding memory barriers, that depends on the hardware
> memory model and the program logic assuming one knows
> how to do concurrent algorithms.

In particular, we are talking about a sequence of instructions
with the properties:: a) an external observer can see only
the previous or new values of a concurrent data structure
and none of the intermediate changes, and b) should the
event fail somewhere in the middle, no-one saw any of
the intermediate state, either.

The event is bigger than the memory reference instruction.

And finally, getting the MemBarIzation correct seems to
be beyond many-most programmers leading to error prone
applications.

> Speaking of memory models, remember when x86 didn't have
> a formal memory model.  They didn't put one in until
> after itanium.  Before that it was a sort of processor
> consistency type 2 which was a real impedance mismatch
> with what most concurrent software used a a memory model.

When only 1 x86 would fit on a die, it really did not mater
much. I was at AMD when they were designing their memory
model.

> Joe Seigh