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:20:57 -0800
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <vhgi4p$1fms3$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 19 Nov 2024 00:20:57 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9787b18f7626d1c750fb4a6ec8af4b65";
	logging-data="1563523"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18uGvEhoNMLI7EKl1vj//5QOfnECNxelRE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:n76ieAnRbGPYfWG7gRQDwlDGVj8=
Content-Language: en-US
In-Reply-To: <2024Nov18.081104@mips.complang.tuwien.ac.at>
Bytes: 4589

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.