Path: ...!weretis.net!feeder8.news.weretis.net!newsfeed.bofh.team!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: big, fast, etc, was is Vax addressing sane today
Date: Fri, 13 Sep 2024 23:12:24 +0000
Organization: Rocksolid Light
Message-ID: <1e328cbbe4890b785bca89546ab22b0b@www.novabbs.org>
References: <vbd6b9$g147$1@dont-email.me> <2024Sep11.113204@mips.complang.tuwien.ac.at> <vbsh3q$3n09p$1@dont-email.me> <vbtqib$2sce$2@dont-email.me> <vbvhs3$2std$1@gal.iecc.com> <vc0pi6$oj8p$1@dont-email.me> <vc1756$r3ge$1@dont-email.me> <20240913145539.000029b5@yahoo.com> <vc2bla$120mf$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1962025"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$uFS7rcPVK0nkdLixUgGXOO8zI56CPLUErTXb73I/0ssc1xE6DMih.
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3291
Lines: 48

On Fri, 13 Sep 2024 21:43:06 +0000, Thomas Koenig wrote:

> Michael S <already5chosen@yahoo.com> schrieb:
>> On Fri, 13 Sep 2024 11:20:06 -0000 (UTC)
>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>
>>> Anything else?
>>>
>>
>> Another thing that SAP HANA seems to use more intensely than anybody
>> else is Intel TSX. TSX (at least RTM part, I am not sure about HLE
>> part) still present in the latest Xeon generation, but is strongly
>> de-emphasized.
>
> Sounds like a market niche...  Mitch, how good is your ESM for
> in-memory databases?

I do not think the in-memory part has anything to do with ESM
ATOMIC behavior.

I have no actual data, all I have is mental analyses.

The real think about ESM is that it allows one to code in such a way
as to need FEWER ATOMIC events--because each event can do more work;
so, thereby one needs fewer events.

1) You can acquire several cache lines and perform a single event
that would take a more typical ISA multiple ATIMOIC instructions.
This attacks the exponent of how rapidly things degrade under
contention.

2) secondly if a higher privilege thread contends with a lower thread
the higher privileged thread wins.

3) amongst equally privileged threads the one(s) that have made more
forward progress succeed while those just getting started fail.

4) There are ways for SW to get a count of the amount of interference
and each thread choose more wisely such that contention is reduced
on subsequent tries. There are some ATOMIC things for which this takes
a BigO( n**3 ) and makes it BigO( 3 ) {yes constant time}. A more
typical; use with new contenders coming and going randomly goes from
BIgO( n**3 ) to between BigO( n*ln(ln(n)) ) and BigO( n*ln(n) ).

HOWEVER:: if one uses ESM to simply implement locking behavior; only
part 1) above applies. That is if one uses ESM to create you standard
{test&set, test*test*set, LoadLocked-StoreCOnditional, CAS, DCAS,
DCADS, TCADS,...} to get a performing kernel that depends on how
the SW is written, not necessarily how HW performs ESM.