Path: ...!news.nobody.at!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Memory ordering
Date: Mon, 25 Nov 2024 15:59:02 -0800
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <vi3305$33bl6$1@dont-email.me>
References: <vfono1$14l9r$1@dont-email.me> <vh4530$2mar5$1@dont-email.me>
 <-rKdnTO4LdoWXKj6nZ2dnZfqnPWdnZ2d@supernews.com>
 <vh5t5b$312cl$2@dont-email.me>
 <5yqdnU9eL_Y_GKv6nZ2dnZfqn_GdnZ2d@supernews.com>
 <2024Nov15.082512@mips.complang.tuwien.ac.at> <vh7rlr$3fu9i$1@dont-email.me>
 <2024Nov15.182737@mips.complang.tuwien.ac.at> <vh8c3f$3j6ql$2@dont-email.me>
 <2024Nov16.083744@mips.complang.tuwien.ac.at> <vhb587$6hbv$7@dont-email.me>
 <2024Nov17.161508@mips.complang.tuwien.ac.at> <vhduhg$sga5$1@dont-email.me>
 <2024Nov18.081104@mips.complang.tuwien.ac.at> <vhgi4p$1fms3$1@dont-email.me>
 <vhgitb$1fro3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 26 Nov 2024 00:59:09 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f4f177e73d590858d34dc86f3bbaa5e5";
	logging-data="3255974"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19uDwumby0XmPDJafm64JfjwdibPKYCkLo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:siy7Q4MDivSwaDnsCrO2X8Xgwco=
In-Reply-To: <vhgitb$1fro3$1@dont-email.me>
Content-Language: en-US
Bytes: 5176

On 11/18/2024 3:34 PM, Chris M. Thomasson wrote:
> On 11/18/2024 3:20 PM, Chris M. Thomasson wrote:
>> On 11/17/2024 11:11 PM, Anton Ertl wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>> What if you had to write code for a weakly ordered system, and the
>>>>>> performance guidelines said to only use a membar when you absolutely
>>>>>> have to. If you say something akin to "I do everything using
>>>>>> std::memory_order_seq_cst", well, that is a violation right off 
>>>>>> the bat.
>>> ...
>>>> I am trying to say you might not be hired if you only knew how to 
>>>> handle
>>>> std::memory_order_seq_cst wrt C++... ?
>>>
>>> I am not looking to be hired.
>>>
>>> In any case, this cuts both ways: If you are an employer working on
>>> multi-threaded software, say, for Windows or Linux, will you reduce
>>> your pool of potential hires by including a requirement like the one
>>> above?  And then pay for longer development time and additional
>>> hard-to-find bugs coming from overshooting the requirement you stated
>>> above.  Or do you limit your software support to TSO hardware (for
>>> lack of widely available SC hardware), and gain all the benefits of
>>> more potential hires, reduced development time, and fewer bugs?
>>>
>>> I have compared arguments against strong memory ordering with those
>>> against floating-point.  Von Neumann argued for fixed point as follows
>>> <https://booksite.elsevier.com/9780124077263/downloads/ 
>>> historial%20perspectives/section_3.11.pdf>:
>>>
>>> |[...] human time is consumed in arranging for the introduction of
>>> |suitable scale factors. We only argue that the time consumed is a
>>> |very small percentage of the total time we will spend in preparing an
>>> |interesting problem for our machine. The first advantage of the
>>> |floating point is, we feel, somewhat illusory. In order to have such
>>> |a floating point, one must waste memory capacity which could
>>> |otherwise be used for carrying more digits per word.
>>>
>>> Kahan writes <https://people.eecs.berkeley.edu/~wkahan/SIAMjvnl.pdf>:
>>>
>>> |Papers in 1947/8 by Bargman, Goldstein, Montgomery and von Neumann
>>> |seemed to imply that 40-bit arithmetic would hardly ever deliver
>>> |usable accuracy for the solution of so few as 100 linear equations in
>>> |100 unknowns; but by 1954 engineers were solving bigger systems
>>> |routinely and getting satisfactory accuracy from arithmetics with no
>>> |more than 40 bits.
>>>
>>> The flaw in the reasoning of the paper was:
>>>
>>> |To solve it more easily without floating–point von Neumann had
>>> |transformed equation Bx = c to B^TBx = B^Tc , thus unnecessarily
>>> |doubling the number of sig. bits lost to ill-condition
>>>
>>> This is an example of how the supposed gains that the harder-to-use
>>> interface provides (in this case the bits "wasted" on the exponent)
>>> are overcompensated by then having to use a software workaround for
>>> the harder-to-use interface.
>>
>> well, if you used std::memory_order_seq_cst to implement, say, a mutex 
>> and/or spinlock memory barrier logic, well, that would raise a red 
>> flag in my mind... Not good.
> 
> Don't tell me you want all of std::memory_order_* to default to 
> std::memory_order_seq_cst? If your on a system that only has seq_cst and 
> nothing else, okay, but not on other weaker (memory order) systems, right?

defaulting a relaxed to a seq_cst is a bit much.... ;^o