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: <2024Sep11.113204@mips.complang.tuwien.ac.at> <20240913145539.000029b5@yahoo.com> 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 schrieb: >> On Fri, 13 Sep 2024 11:20:06 -0000 (UTC) >> Thomas Koenig 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.