Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.quux.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Is Intel exceptionally unsuccessful as an architecture =?UTF-8?B?ZGVzaWduZXI/?= Date: Mon, 23 Sep 2024 01:34:55 +0000 Organization: Rocksolid Light Message-ID: <4f84910a01d7db353eedadd7c471d7d3@www.novabbs.org> References:

<21028ed32d20f0eea9a754fafdb64e45@www.novabbs.org> <20240918190027.00003e4e@yahoo.com>

<920c561c4e39e91d3730b6aab103459b@www.novabbs.org> <%dAHO.54667$S9Vb.39628@fx45.iad>

MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="3077038"; mail-complaints-to="usenet@i2pn2.org"; posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A"; User-Agent: Rocksolid Light X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 X-Rslight-Site: $2y$10$vSdafQT0D4JPfoh9wKTNoeoKLqiy0hJN25Rsh4.zoi9XWWRnMnG.6 Bytes: 5498 Lines: 91 On Mon, 23 Sep 2024 0:53:35 +0000, jseigh wrote: > On 9/22/2024 5:39 PM, MitchAlsup1 wrote: >> On Sun, 22 Sep 2024 19:37:02 +0000, Paul A. Clayton wrote: >> >>> On 9/21/24 4:45 PM, MitchAlsup1 wrote: >>>> On Sat, 21 Sep 2024 20:26:13 +0000, Chris M. Thomasson wrote: >>>> >>>>> On 9/21/2024 6:54 AM, Scott Lurndal wrote: >>>>>> mitchalsup@aol.com (MitchAlsup1) writes: >>>>>> https://www.marvell.com/products/cxl.html >>>>> >>>>> What about a weak coherency where a programmer has to use the >>>>> correct >>>>> membars to get the coherency required for their specific needs? >>>>> Along >>>>> the lines of UltraSPARC in RMO mode? >>>> >>>> In my case, I suffered through enough of these to implement a >>>> memory hierarchy free from the need of any MemBars yet provide >>>> the performance of relaxed memory order, except when >>>> certain kinds of addresses are touched {MMI/O, configuration >>>> space, ATOMIC accesses,...} In these cases, the core becomes >>>> {sequentially consistent, or strongly ordered} depending on the >>>> touched address. >>> >>> If I understand correctly, atomic accesses (Enhances >>> Synchronization Facility) effective use a complete memory barrier; >>> software could effectively provide a memory barrier "instruction" >>> by performing an otherwise pointless atomic/ESF operation. >>> >>> Are there no cases where an atomic operation is desired but >>> sequential consistency is not required? >> >> Probably--but in the realm of ATOMICs it is FAR better to be >> a bit slower than to ever allow the illusion of atomicity to >> be lost. This criterion is significantly harder when doing >> multi-location ATOMIC stuff than single location ATOMIC stuff. >> >>> Or is this a tradeoff of >>> frequency/criticality and the expected overhead of the implicit >>> memory barrier? (Memory barriers may be similar to context >>> switches, not needing to be as expensive as they are in most >>> implementations.) >> >> The R in RISC stands for Reduced. An ISA devoid of MemBar is >> more reduced than one with MemBars. Programmers are rarely >> in a position to understand all the cases where MemBar are >> needed or not needed {{excepting our own Chris M. Thomasson}} >> > > Not quite sure what we are talking about here but I won't > let that stop me from commenting. :) Its a free forum > As far as loads and stores go, if they are atomic then > a load will not see a value that was not from some store. When you include stores from devices into memory, we agree. A LD should return the last written value. When you include device control registers; all bets are off. > Regarding memory barriers, that depends on the hardware > memory model and the program logic assuming one knows > how to do concurrent algorithms. In particular, we are talking about a sequence of instructions with the properties:: a) an external observer can see only the previous or new values of a concurrent data structure and none of the intermediate changes, and b) should the event fail somewhere in the middle, no-one saw any of the intermediate state, either. The event is bigger than the memory reference instruction. And finally, getting the MemBarIzation correct seems to be beyond many-most programmers leading to error prone applications. > Speaking of memory models, remember when x86 didn't have > a formal memory model. They didn't put one in until > after itanium. Before that it was a sort of processor > consistency type 2 which was a real impedance mismatch > with what most concurrent software used a a memory model. When only 1 x86 would fit on a die, it really did not mater much. I was at AMD when they were designing their memory model. > Joe Seigh