Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82547 > unrolled thread

Little program to test concurrency of .fetch_add and .compare_exchange_weak

Back to article view | Back to comp.lang.c++

Contents

  Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-05 18:13 +0100
    Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-05 19:56 +0000
      Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-05 15:22 -0800
        Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-05 23:43 +0000
          Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-05 19:31 -0800
        Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 06:26 +0100
      Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 06:24 +0100
        Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-06 10:45 +0000
          Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 13:09 +0100
    Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 06:27 +0100
    Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak scott@slp53.sl.home (Scott Lurndal) - 2021-12-06 18:02 +0000
      Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-07 06:27 +0100
        Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak scott@slp53.sl.home (Scott Lurndal) - 2021-12-07 18:06 +0000
          Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-07 19:14 +0100
            Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak scott@slp53.sl.home (Scott Lurndal) - 2021-12-07 18:49 +0000
              Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-07 19:54 +0100
                Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak scott@slp53.sl.home (Scott Lurndal) - 2021-12-07 19:14 +0000
                  Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak scott@slp53.sl.home (Scott Lurndal) - 2021-12-07 19:25 +0000
                    Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-08 09:50 +0100
                    Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-08 00:59 -0800
                      Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-08 15:41 +0100
                        Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak scott@slp53.sl.home (Scott Lurndal) - 2021-12-08 15:48 +0000
                          Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-08 17:35 +0100
                      Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Öö Tiib <ootiib@hot.ee> - 2021-12-08 10:57 -0800
                        Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Manfred <noname@add.invalid> - 2021-12-09 00:27 +0100
                        Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak Juha Nieminen <nospam@thanks.invalid> - 2021-12-09 06:30 +0000
                  Re: Little program to test concurrency of .fetch_add and .compare_exchange_weak David Brown <david.brown@hesbynett.no> - 2021-12-08 09:08 +0100

Page 2 of 2 — ← Prev page 1 [2]

#82588

Am 08.12.2021 um 09:59 schrieb Chris M. Thomasson:
> On 12/7/2021 11:25 AM, Scott Lurndal wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 07.12.2021 um 19:49 schrieb Scott Lurndal:
>>>
>>>>
>>>>> How do you know?
>>>>
>>>> Because this would be slower since the lock-modifications
>>>> woudln't be done in the L1-caches but in far memory. That's
>>>> just a silly idea.
>>>
>>> Hello, it's a cache-coherent multiprocessor.   You need to
>>> fetch it exclusively into the L1 first, so instead of sending the fetch
>>> (or invalidate if converting a shared line to owned),
>>> you send the atomic op and it gets handled atomically at
>>> the far end (e.g. LLC, PCI express device, SoC coprocessor)
>>> saving the interconnect (mesh, ring, whatever) bandwidth and
>>> the round-trip time between L1 and LLC and reducing contention
>>> for the line.
>>>
>>> If it's already in the L1 cache, then the processor will
>>> automatically treat it as a near-atomic, this is expected
>>> to be a rare case with correctly designed atomic usage.
>>
>> In case you need a public reference for a shipping processor:
>>
>> https://developer.arm.com/documentation/102099/0000/L1-data-memory-system/Instruction-implementation-in-the-L1-data-memory-system 
>>
>>
> 
> 
> You have encountered the rabbit hole of Bonita! I have proved her/it 
> wrong several times. No good, goes nowhere.

What he links isn't a proof for what he says.
The above CPU doesn't implement the mentioned interconnect. It's
just a minor improvement for this special kind of CPU -architecture
to speed up lock-flipping with concurrent cores.

[toc] | [prev] | [next] | [standalone]

#82589

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 08.12.2021 um 09:59 schrieb Chris M. Thomasson:

>> You have encountered the rabbit hole of Bonita! I have proved her/it 
>> wrong several times. No good, goes nowhere.
>
>What he links isn't a proof for what he says.

As you note Chris, Christof/Bonita cannot admit he
was wrong.

>The above CPU doesn't implement the mentioned interconnect.

Of course not, ARM doesn't make CPUs.  They provide the IP
used to make real CPUs;  for example the Amazon AWS Graviton 2 and 3.

Yet, ARM does provide interconnect IP which fully supports
near and far atomics.

Some of the current Neoverse N2 licensees are listed here:

https://www.design-reuse.com/news/49872/arm-neoverse-n2-v1-platform.html

[toc] | [prev] | [next] | [standalone]

#82590

Am 08.12.2021 um 16:48 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 08.12.2021 um 09:59 schrieb Chris M. Thomasson:
> 
>>> You have encountered the rabbit hole of Bonita! I have proved her/it
>>> wrong several times. No good, goes nowhere.
>>
>> What he links isn't a proof for what he says.
> 
> As you note Chris, Christof/Bonita cannot admit he
> was wrong.
> 
>> The above CPU doesn't implement the mentioned interconnect.
> 
> Of course not, ARM doesn't make CPUs.  They provide the IP
> used to make real CPUs;  for example the Amazon AWS Graviton 2 and 3.
> 
> Yet, ARM does provide interconnect IP which fully supports
> near and far atomics.

They're not far in the sense of the mentioned interconnect.

[toc] | [prev] | [next] | [standalone]

#82591

On Wednesday, 8 December 2021 at 10:59:51 UTC+2, Chris M. Thomasson wrote:
> On 12/7/2021 11:25 AM, Scott Lurndal wrote: 
> > sc...@slp53.sl.home (Scott Lurndal) writes: 
> >> Bonita Montero <Bonita....@gmail.com> writes: 
> >>> Am 07.12.2021 um 19:49 schrieb Scott Lurndal: 
> >> 
> >>> 
> >>>> How do you know? 
> >>> 
> >>> Because this would be slower since the lock-modifications 
> >>> woudln't be done in the L1-caches but in far memory. That's 
> >>> just a silly idea. 
> >> 
> >> Hello, it's a cache-coherent multiprocessor. You need to 
> >> fetch it exclusively into the L1 first, so instead of sending the fetch 
> >> (or invalidate if converting a shared line to owned), 
> >> you send the atomic op and it gets handled atomically at 
> >> the far end (e.g. LLC, PCI express device, SoC coprocessor) 
> >> saving the interconnect (mesh, ring, whatever) bandwidth and 
> >> the round-trip time between L1 and LLC and reducing contention 
> >> for the line. 
> >> 
> >> If it's already in the L1 cache, then the processor will 
> >> automatically treat it as a near-atomic, this is expected 
> >> to be a rare case with correctly designed atomic usage. 
> > 
> > In case you need a public reference for a shipping processor: 
> > 
> > https://developer.arm.com/documentation/102099/0000/L1-data-memory-system/Instruction-implementation-in-the-L1-data-memory-system 
> >
> You have encountered the rabbit hole of Bonita! I have proved her/it 
> wrong several times. No good, goes nowhere.

But it what comp.lang.c++ is. Whenever you come here then BM is
present, wrong (or not even wrong), desperately trying to shadow
it by snipping out of context, removing attributions, misrepresenting
what others wrote, moving goalposts etc. Keeping hearth and home
warm. ;-D
 

[toc] | [prev] | [next] | [standalone]

#82593

On 12/8/2021 7:57 PM, Öö Tiib wrote:
> removing attributions

At least this part appears to have improved, as of recent. For all the 
rest, there's still a long way to go, but never loose hope ;)

[toc] | [prev] | [next] | [standalone]

#82594

Öö Tiib <ootiib@hot.ee> wrote:
>> You have encountered the rabbit hole of Bonita! I have proved her/it 
>> wrong several times. No good, goes nowhere.
> 
> But it what comp.lang.c++ is. Whenever you come here then BM is
> present, wrong (or not even wrong), desperately trying to shadow
> it by snipping out of context, removing attributions, misrepresenting
> what others wrote, moving goalposts etc. Keeping hearth and home
> warm. ;-D

The same pattern repeats again and again and again. I can't decide if
it's amusing or tiresome.

At least she doesn't use as many insults and derogatory tone anymore
towards people who are just trying to help, so I suppose that's an
improvement.

[toc] | [prev] | [next] | [standalone]

#82584

On 07/12/2021 20:14, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 07.12.2021 um 19:49 schrieb Scott Lurndal:
> 
>>
>>> How do you know?
>>
>> Because this would be slower since the lock-modifications
>> woudln't be done in the L1-caches but in far memory. That's
>> just a silly idea.
> 
> Hello, it's a cache-coherent multiprocessor.   You need to
> fetch it exclusively into the L1 first, so instead of sending the fetch
> (or invalidate if converting a shared line to owned),
> you send the atomic op and it gets handled atomically at
> the far end (e.g. LLC, PCI express device, SoC coprocessor)
> saving the interconnect (mesh, ring, whatever) bandwidth and
> the round-trip time between L1 and LLC and reducing contention
> for the line.
> 
> If it's already in the L1 cache, then the processor will
> automatically treat it as a near-atomic, this is expected
> to be a rare case with correctly designed atomic usage.
> 

This is such an obvious improvement that I am constantly amazed how long
it has taken to be implemented.  Using ordinary memory for atomic
operations, locks, etc., is massively inefficient compared to a
dedicated hardware solution.

I've used a multi-core embedded microcontroller with a semaphore block,
consisting of a number (16, IIRC) of individual semaphores.  Each of
these was made of two 16-bit parts - the lock tag and the value.  You
can only change the value if you have the lock, and you get the lock by
writing a non-zero tag when the tag is currently 0 (unlocked).  You
release it by writing your tag with the high bit set.  It is all very
simple, and extremely fast - no need to go through caches, snooping, or
any of that nonsense because it is dedicated and connected close to the
cpu's core buses.

Obviously in a "big" system you need to handle more than two cores (and
with the Z-Gen and CLX system, other bus masters), support larger
numbers of locks, and security is a rather different matter!  But the
principle of having dedicated hardware, memory mapped but not passing
through caches and slow external memory, is the same.

Atomic operations carried out by the core on memory in the L1 caches
will be fast as long as their are no conflicts, but you wouldn't bother
with atomics unless there /were/ a risk of conflict.  And then they get
slow.  With a "far atomics" solution, you should be able to get much
more consistent timings and efficient results.

(At least, that is my understanding of it, without having actually used
them!)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web