| scott@slp53.sl.home (Scott Lurndal): Jun 25 02:34PM >> as fast as a non-atomic access to the same location. >Iirc, an atomic RMW, like a LOCK XADD will be slower than a plain >non-atomic access. Even if everything is single threaded. Why would you think that? The processor needs to acquire exclusive access to the cache line in order to modify. That is basically an implicit lock, and is done regardless of the LOCK prefix. Modern processors may delegate the XADD operation to the cache rather than loading from the cache, performing the operation, and storing back to cache. Only if the access straddles two cache lines will the system bus lock be acquired (or in very rare cases when the processor cannot acquire the cache line in a certain amount of time after which the processor will assert the bus lock). |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 25 12:16PM -0700 On 6/25/2021 7:34 AM, Scott Lurndal wrote: >> Iirc, an atomic RMW, like a LOCK XADD will be slower than a plain >> non-atomic access. Even if everything is single threaded. > Why would you think that? Iirc, I did some tests in the past where I ran a large loop of volatile non-atomic accesses vs LOCK XADD in a single thread and, iirc, the LOCK XADD was slower. It was something like: volatile unsigned long target = 0; for (unsigned long i = 0; i < N; ++i) { ++target; } vs for (unsigned long i = 0; i < N; ++i) { ct_atomic_xadd(&target, 1); } This was before C++ made atomics/membars standard. ct_atomic_xadd was implemented in assembly language and externally assembled. > lock be acquired (or in very rare cases when the processor cannot > acquire the cache line in a certain amount of time after which the > processor will assert the bus lock). Well, shit. I need to code up the test again to refresh my memory. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment