Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Memory ordering (was: Arguments for a sane ISA 6-years later)
Date: Mon, 29 Jul 2024 14:10:26 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 49
Message-ID: <2024Jul29.161026@mips.complang.tuwien.ac.at>
References: <b5d4a172469485e9799de44f5f120c73@www.novabbs.org> <v7ubd4$2e8dr$1@dont-email.me> <v7uc71$2ec3f$1@dont-email.me> <2024Jul26.190007@mips.complang.tuwien.ac.at> <v872h5$alfu$2@dont-email.me>
Injection-Date: Mon, 29 Jul 2024 16:27:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5399d9ef69b5f7b7cf843d1b51aebed9";
	logging-data="553332"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5MrlLIqnGc48KQRe2Bsky"
Cancel-Lock: sha1:6wPtEcrxpwEY1FteozNw4kqUBL8=
X-newsreader: xrn 10.11
Bytes: 3120

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 7/26/2024 10:00 AM, Anton Ertl wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[...]
>> By contrast, one can design hardware for strong ordering such that the
>> slowness occurs only in those cases when actual (not potential)
>> communication between the cores happens, i.e., much less frequently.
>> 
>>> and sometimes use cases do not care if they encounter "stale" data.
>> 
>> Great.  Unless these "sometimes" cases are more often than the cases
>> where you perform some atomic operation or barrier because of
>> potential, but not actual communication between cores, the weak model
>> is still slower than a well-implemented strong model.
>
>A strong model? You mean I don't have to use any memory barriers at all?

In the paragraph above I had a weaker model and a stronger model in
mind, where the stronger model needs fewer barriers and atomic
operations than the weak model.

But sure, sequential consistency does not require any memory barriers,
so that would be the ultimate strong model, and, if implemented
efficiently, would beat the weaker TSO, just as an efficiently
implemented TSO beats weaker models.

>Tell that to SPARC in RMO mode...

What about it?  If you mean that SPARC in TSO mode is slower, that may
be the case.  That's why I specified "well-implemented" above.

>Even the x86 requires a 
>membar when a store followed by a load to another location shall be 
>respected wrt order.

So "the x86" (whatever you mean by that) is not sequentially
consistent.

>I 
>thought it was easier for a HW guy to implement weak consistency? At the 
>cost of the increased complexity wrt programming the sucker! ;^)

Yes, that's why the hardware people love to give us weak consistency.
It's our job to say no and tell them to finish the job.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>