Path: ...!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, 18 Nov 2024 15:34:03 -0800
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <vhgitb$1fro3$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 19 Nov 2024 00:34:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9787b18f7626d1c750fb4a6ec8af4b65";
	logging-data="1568515"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19C7UkX0vFfJbAWh8nkJry5DC+Z24Jsn8k="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:iKUqomJrDEgmTY+73nu85UyFN4M=
Content-Language: en-US
In-Reply-To: <vhgi4p$1fms3$1@dont-email.me>
Bytes: 4944

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?