Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news.in-chemnitz.de!news.swapon.de!eternal-september.org!feeder3.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: Is Intel exceptionally unsuccessful as an architecture designer?
Date: Sun, 22 Sep 2024 12:07:16 -0700
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <vcppt4$2abkd$1@dont-email.me>
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>
 <vcnihg$1ono3$2@dont-email.me> <vcovvb$26noh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 22 Sep 2024 21:07:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0029950ff4e92ba21a7d99fa35b943c5";
	logging-data="2436749"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180xwMreKtlonTtuZeJDyNxsKV8EYW8/lE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9VUi0YR0gHC0vOrI2R9k8f0Pu4w=
In-Reply-To: <vcovvb$26noh$1@dont-email.me>
Content-Language: en-US
Bytes: 2630

On 9/22/2024 4:44 AM, jseigh wrote:
> On 9/21/24 18:49, jseigh wrote:
>>
>> Well, we have asymmetric memory barriers now (membarrier() in linux)
>> so we can get rid of memory barriers in some cases.  For hazard
>> pointers which used to be a (load, store, mb, load) are now just
>> a (load, store, load).  Much faster,  from 8.02 nsecs to 0.79 nsecs.
>> So much so that other things which has heretofore been considered
>> to add negligible overhead are not so much by comparison.  Which can
>> be a little annoying because some like using those a lot.
>>
> 
> I should correct those timings slightly.  The measurements were for a
> hazard pointer load, a dummy dependent load, and a hazard pointer clear.
> If I measure w/o the dummy dependent load, the timings go from
> 7.75 to 0.61 nsecs respectively.

Think of an Alpha with its required mb for dependent load's?