Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #124819 > unrolled thread
| Started by | Joseph Seigh <jseigh_es00@xemaps.com> |
|---|---|
| First post | 2026-09-16 18:25 -0400 |
| Last post | 2026-10-15 19:26 -0400 |
| Articles | 20 on this page of 117 — 5 participants |
Back to article view | Back to comp.lang.c++
Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-09-16 18:25 -0400
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-09-18 16:07 -0400
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-19 13:34 -0700
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-09-20 10:58 -0400
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-20 14:51 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-20 16:09 -0700
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-09-20 20:19 -0400
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-20 19:26 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-21 14:50 +0200
Re: Consequential RCU boltar@caprica.universe - 2026-09-21 15:47 +0000
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-21 18:45 +0200
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-09-25 18:25 +0200
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-25 18:40 +0200
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-09-25 13:47 -0400
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-25 20:54 +0200
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-09-25 17:20 -0400
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-26 16:23 +0200
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-09-26 15:36 -0400
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-27 14:56 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-28 15:50 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-29 08:31 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-02 11:13 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-10-03 14:19 +0200
Re: Consequential RCU boltar@caprica.universe - 2026-10-03 15:50 +0000
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-03 14:12 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-10-04 11:34 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 17:13 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-10-09 08:33 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-12 12:58 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 17:15 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-28 15:44 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-28 15:45 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-24 15:31 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-24 15:28 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-25 08:33 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-28 15:42 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-29 08:40 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:30 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-09-30 09:54 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-02 11:11 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-10-03 14:22 +0200
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-10-02 14:39 -0400
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 11:39 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-06 06:28 +0200
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-10-06 08:36 +0200
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-06 10:38 +0200
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-10-06 10:42 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 13:19 -0700
Re: Consequential RCU David Brown <david.brown@hesbynett.no> - 2026-10-07 10:49 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 13:11 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-05 19:00 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-05 10:57 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-05 21:03 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 13:15 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-07 05:19 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 21:29 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-07 15:01 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 13:12 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-08 05:57 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 11:41 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-09 08:16 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-19 12:07 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-05 21:23 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 13:18 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-07 05:19 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 18:10 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-09 08:16 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 21:31 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 21:33 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 21:34 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-07 15:00 +0200
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-07 15:26 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 13:17 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-08 05:55 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 12:19 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 14:20 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-09 08:14 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-09 11:05 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 13:13 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-08 05:56 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-10 14:20 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-11 06:59 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-11 14:07 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-12 05:18 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-11 20:31 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-12 06:32 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-12 13:14 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-13 08:14 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-13 00:08 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-13 00:10 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-13 09:43 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-13 12:29 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-14 05:56 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-14 14:02 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-16 05:28 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-16 13:28 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-12 13:19 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-12 13:24 -0700
Re: Consequential RCU Bonita Montero <Bonita.Montero@gmail.com> - 2026-10-13 11:33 +0200
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 18:53 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-08 18:55 -0700
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-10-11 11:11 -0400
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-11 14:10 -0700
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-10-11 21:44 -0400
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-11 20:04 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-11 20:07 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-11 20:34 -0700
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-10-13 13:01 -0400
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-13 12:36 -0700
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-10-13 19:34 -0400
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-13 16:46 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-14 14:16 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-14 14:46 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-15 11:23 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-15 11:26 -0700
Re: Consequential RCU "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-15 11:49 -0700
Re: Consequential RCU Joseph Seigh <jseigh_es00@xemaps.com> - 2026-10-15 19:26 -0400
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-03 14:22 +0200 |
| Message-ID | <119qs1q$306a9$2@dont-email.me> |
| In reply to | #124898 |
On 02/10/2026 20:11, Chris M. Thomasson wrote: > On 9/30/2026 12:54 AM, David Brown wrote: >> On 30/09/2026 01:30, Chris M. Thomasson wrote: >>> On 9/28/2026 11:40 PM, David Brown wrote: >> >>>> gcc inline assembly is a /much/ better solution here. It's okay if >>>> you don't know how to write it - and it is certainly okay if you did >>>> not know how to do so a decade ago. But you should understand why >>>> it is better, and then decide if you are going to learn about it. >>>> >>>> (Of course for this particular case, if you can persuade the gcc C++ >>>> library folk to make their standard cas16 lock-free, then using the >>>> standard function is best.) >>> Difficult to totally disagree with that David. Shit. Its my own >>> personal problem with the syntax of GCC inline asm. I am a bit scared >>> of it. Sigh. Clobbers what? When and where? cdecl for the ABI and >>> externally assembled functions are fine for me, LTO aside for a >>> moment, can be bad do not go into my asm! BUT. Again. Shit. Its a >>> personal problem wrt me saying inline bad! Sorry! >>> >> >> Not knowing the syntax for gcc inline assembly is not a "problem" as >> such - most C programmers never need it. It is just a strong >> recommendation that /if/ you want to write assembly code, then your >> results would be much improved by using inline assembly format rather >> than external assembly functions. And you are already familiar with >> the hard part, the actual assembly. So don't look at this as a >> problem of any sort - look at it as a fun, challenging and useful new >> direction for your existing skills and interests. >> >>> Also, if C++ gains a LOCK CMPXCHG16B for a double word, two >>> contiguous 64 bit words on a 64 bit machine, well GOOD! Show me. I >>> have had some experiences with it trying to tell me its not lock free. >> >> The C++ standard library supports 16 byte compare-and-exchange. The >> gcc implementation of that library does not use that instruction, and >> thus does not support lock-free 16 byte compare-and-exchange. C++ has >> supported this since C++11 - this is a QOI issue, not a language or >> standard library issue. File an issue on the gcc bugzilla - that's >> how you get progress (or how we will learn if there are good reasons >> not to use it.) >> > > I first need to show why its a qoi to begin with. If the arch supports a > single instruction for a double word atomic rmw op (DWCAS), it should be > using that instruction. And! it needs to report it as always lock-free. > Then the user has all the info they need for a fallback to asm. Then > show a bunch of examples where its needed. But that should not be all > that hard. Say okay, if the C/C++ does not make this atomic RMW lock- > free on an arch that supports it, then its useless for anything lock- > free on said arch. ASM to the rescue? The inline asm certainly gives you a way to get efficient use of the instruction before it is in the toolchain implementation. But the toolchain implementation is the best long-term solution. So do both - use the inline asm yourself while encouraging gcc to implement it in their library for the future.
[toc] | [prev] | [next] | [standalone]
| From | Joseph Seigh <jseigh_es00@xemaps.com> |
|---|---|
| Date | 2026-10-02 14:39 -0400 |
| Message-ID | <119otp7$2bs8n$1@dont-email.me> |
| In reply to | #124895 |
On 9/29/26 7:30 PM, Chris M. Thomasson wrote: > On 9/28/2026 11:40 PM, David Brown wrote: >> On 29/09/2026 00:42, Chris M. Thomasson wrote: ... >> >> (Of course for this particular case, if you can persuade the gcc C++ >> library folk to make their standard cas16 lock-free, then using the >> standard function is best.) > Difficult to totally disagree with that David. Shit. Its my own personal > problem with the syntax of GCC inline asm. I am a bit scared of it. > Sigh. Clobbers what? When and where? cdecl for the ABI and externally > assembled functions are fine for me, LTO aside for a moment, can be bad > do not go into my asm! BUT. Again. Shit. Its a personal problem wrt me > saying inline bad! Sorry! > > Also, if C++ gains a LOCK CMPXCHG16B for a double word, two contiguous > 64 bit words on a 64 bit machine, well GOOD! Show me. I have had some > experiences with it trying to tell me its not lock free. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 The rationale seems to be you can mix a lock-free operation with locked operations since __atomic_always_lock_free and __atomic_is_lock_free apply to the data type not specific builtins. Given that there seems to be no shortage of x86 specific gcc builtins, I can't think of any reason why there's no cmpxchg16b builtin.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-08 11:39 -0700 |
| Message-ID | <11a8o0d$402c$1@dont-email.me> |
| In reply to | #124900 |
On 10/2/2026 11:39 AM, Joseph Seigh wrote: > On 9/29/26 7:30 PM, Chris M. Thomasson wrote: >> On 9/28/2026 11:40 PM, David Brown wrote: >>> On 29/09/2026 00:42, Chris M. Thomasson wrote: > ... >>> >>> (Of course for this particular case, if you can persuade the gcc C++ >>> library folk to make their standard cas16 lock-free, then using the >>> standard function is best.) >> Difficult to totally disagree with that David. Shit. Its my own >> personal problem with the syntax of GCC inline asm. I am a bit scared >> of it. Sigh. Clobbers what? When and where? cdecl for the ABI and >> externally assembled functions are fine for me, LTO aside for a >> moment, can be bad do not go into my asm! BUT. Again. Shit. Its a >> personal problem wrt me saying inline bad! Sorry! >> >> Also, if C++ gains a LOCK CMPXCHG16B for a double word, two contiguous >> 64 bit words on a 64 bit machine, well GOOD! Show me. I have had some >> experiences with it trying to tell me its not lock free. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 > > The rationale seems to be you can mix a lock-free operation > with locked operations since __atomic_always_lock_free and > __atomic_is_lock_free apply to the data type not specific > builtins. > > Given that there seems to be no shortage of x86 specific > gcc builtins, I can't think of any reason why there's > no cmpxchg16b builtin. Really strange!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-10-06 06:28 +0200 |
| Message-ID | <11a1tdl$1k3so$1@raubtier-asyl.eternal-september.org> |
| In reply to | #124893 |
Am 29.09.2026 um 08:40 schrieb David Brown: > The whole point of using lock-free algorithms here, and the double > compare-and-swap, is speed. If you use external assembly so that all > your important data has to be pushed from registers to the stack, then > you have a call, then you pull the data off the stack again - you've a > dozen extra instructions at the call site, a dozen extra instructions at > the cas16 site, doing nothing except spoiling your efficient code. A CAS16 is that slow that the additional call doesn't hurt. And usually a CAS involves remote cacheline re-loading which is a magnitude more expensive than a trivial function call.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 08:36 +0200 |
| Message-ID | <11a24u4$1m8mp$1@dont-email.me> |
| In reply to | #124914 |
On 06/10/2026 06:28, Bonita Montero wrote: > Am 29.09.2026 um 08:40 schrieb David Brown: > >> The whole point of using lock-free algorithms here, and the double >> compare-and-swap, is speed. If you use external assembly so that all >> your important data has to be pushed from registers to the stack, then >> you have a call, then you pull the data off the stack again - you've a >> dozen extra instructions at the call site, a dozen extra instructions >> at the cas16 site, doing nothing except spoiling your efficient code. > > A CAS16 is that slow that the additional call doesn't hurt. > And usually a CAS involves remote cacheline re-loading which > is a magnitude more expensive than a trivial function call. > I am not an expert in these algorithms and their timings, but I would have thought this only applies when there has been a conflict - some other thread/cpu has been accessing the data structure since you last used it. And equally, while a function call can have low overheads if everything is in the instruction cache, if the code for it has to be pulled in from main memory then it will add significant extra time. Still, it is a relevant point that real-life timing is more than just the number of instructions.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-10-06 10:38 +0200 |
| Message-ID | <11a2c22$1or6q$1@raubtier-asyl.eternal-september.org> |
| In reply to | #124915 |
Am 06.10.2026 um 08:36 schrieb David Brown: > And equally, while a function call can have low overheads if everything > is in the instruction cache, if the code for it has to be pulled in from > main memory then it will add significant extra time. Absolutely not, theres an instruction and a uOp cache.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 10:42 +0200 |
| Message-ID | <11a2c9u$1ou6l$1@dont-email.me> |
| In reply to | #124916 |
On 06/10/2026 10:38, Bonita Montero wrote: > Am 06.10.2026 um 08:36 schrieb David Brown: > >> And equally, while a function call can have low overheads if >> everything is in the instruction cache, if the code for it has to be >> pulled in from main memory then it will add significant extra time. > > Absolutely not, theres an instruction and a uOp cache. > Please re-read what I wrote.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-06 13:19 -0700 |
| Message-ID | <11a3l4q$297t1$3@dont-email.me> |
| In reply to | #124917 |
On 10/6/2026 1:42 AM, David Brown wrote: > On 06/10/2026 10:38, Bonita Montero wrote: >> Am 06.10.2026 um 08:36 schrieb David Brown: >> >>> And equally, while a function call can have low overheads if >>> everything is in the instruction cache, if the code for it has to be >>> pulled in from main memory then it will add significant extra time. >> >> Absolutely not, theres an instruction and a uOp cache. >> > > Please re-read what I wrote. > I "think" he is confusing things... Using RCU for hyper fast read side, vs implementing the guts of a strong atomic ref counter.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-07 10:49 +0200 |
| Message-ID | <11a513d$2m3b2$2@dont-email.me> |
| In reply to | #124920 |
On 06/10/2026 22:19, Chris M. Thomasson wrote: > On 10/6/2026 1:42 AM, David Brown wrote: >> On 06/10/2026 10:38, Bonita Montero wrote: >>> Am 06.10.2026 um 08:36 schrieb David Brown: >>> >>>> And equally, while a function call can have low overheads if >>>> everything is in the instruction cache, if the code for it has to be >>>> pulled in from main memory then it will add significant extra time. >>> >>> Absolutely not, theres an instruction and a uOp cache. >>> >> >> Please re-read what I wrote. >> > > I "think" he is confusing things... Using RCU for hyper fast read side, > vs implementing the guts of a strong atomic ref counter. I am not sure you read the posts either. I wrote "while a function call can have low overheads if everything is in the instruction cache ...", and Bonita replied "Absolutely not, there's an instruction cache". Then you followed up with something completely different.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-07 13:11 -0700 |
| Message-ID | <11a691e$370r9$1@dont-email.me> |
| In reply to | #124928 |
On 10/7/2026 1:49 AM, David Brown wrote: > On 06/10/2026 22:19, Chris M. Thomasson wrote: >> On 10/6/2026 1:42 AM, David Brown wrote: >>> On 06/10/2026 10:38, Bonita Montero wrote: >>>> Am 06.10.2026 um 08:36 schrieb David Brown: >>>> >>>>> And equally, while a function call can have low overheads if >>>>> everything is in the instruction cache, if the code for it has to >>>>> be pulled in from main memory then it will add significant extra time. >>>> >>>> Absolutely not, theres an instruction and a uOp cache. >>>> >>> >>> Please re-read what I wrote. >>> >> >> I "think" he is confusing things... Using RCU for hyper fast read >> side, vs implementing the guts of a strong atomic ref counter. > > I am not sure you read the posts either. > > I wrote "while a function call can have low overheads if everything is > in the instruction cache ...", and Bonita replied "Absolutely not, > there's an instruction cache". > > Then you followed up with something completely different. > > oh well. I did! I was responding to the guts of Bonita's ref count impl. Sorry!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-10-05 19:00 +0200 |
| Message-ID | <11a0l38$150m3$1@raubtier-asyl.eternal-september.org> |
| In reply to | #124819 |
Am 17.09.2026 um 00:25 schrieb Joseph Seigh:
> https://jseigh.wordpress.com/2026/09/07/consequential-concurrent-
> sequential-rcu/
RCU isn't necessary. If shared_ptr<X> would have an assignment operator
that takes an atomic<shared_ptr<X>> on the right side and this assign-
ment operator would first compare its own pointer vs the current poin-
ter of the atomic. If both are the same nothing further happens - and
the cachelines holding the atomic<shared_ptr<X>> could remain in shared
mode.
I implemented that and the following code is the assignment-operator
of shared_obj<T> taking a tshared_obj<T>. The fast path is in the first
method and the slow path is in the second method:
template<typename T, int ThreadMode>
FORCEINLINE auto shared_obj<T, ThreadMode>::operator =( const
tshared_obj<T, ThreadMode> &tso ) noexcept -> shared_obj &
{
data *pDtaRef = tso.m_pAtmData.load( std::memory_order_relaxed );
if( m_pData != pDtaRef ) [[unlikely]]
slowAssign( tso, pDtaRef );
return *this;
}
template<typename T, int ThreadMode>
NOINLINE void shared_obj<T, ThreadMode>::slowAssign( const
tshared_obj<T, ThreadMode> &tso, data *pDtaRef ) noexcept
{
using namespace std;
for( ; ; )
{
if( !pDtaRef )
{
data *pData = m_pData;
if( pData && pData->decr() )
delete pData;
m_pData = nullptr;
return;
}
if( pDtaRef == (data *)-1 )
{
tso.m_pAtmData.wait( pDtaRef );
pDtaRef = tso.m_pAtmData.load( memory_order_relaxed );
}
else if( tso.m_pAtmData.compare_exchange_strong( pDtaRef, (data *)-1,
memory_order_relaxed, memory_order_relaxed ) ) [[likely]]
break;
if( m_pData == pDtaRef )
return;
}
m_pData = pDtaRef;
m_pData->incr( memory_order_acquire );
tso.m_pAtmData.store( pDtaRef, memory_order_relaxed );
tso.m_pAtmData.notify_all();
}
I ran the numbers on that and an assignment takes about a nanosecond
if the tshared_ptr hasn't changed. I ran the same benchmark on a
shared _ptr<X> vs a atomic<shared_ptr<X>> and depending on the num-
ber of threads the time per operation goes up to several microseconds.
And my thshared_ptr only has the size of a pointer because when it
is locked it morphes into a futex having the locked value of -1.
The usual atomic<shared_ptr<X>>s have the size of two pointers.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-05 10:57 -0700 |
| Message-ID | <11a0odn$16c2e$1@dont-email.me> |
| In reply to | #124910 |
On 10/5/2026 10:00 AM, Bonita Montero wrote: > Am 17.09.2026 um 00:25 schrieb Joseph Seigh: > >> https://jseigh.wordpress.com/2026/09/07/consequential-concurrent- >> sequential-rcu/ > RCU isn't necessary. If shared_ptr<X> would have an assignment operator > that takes an atomic<shared_ptr<X>> on the right side and this assign- > ment operator would first compare its own pointer vs the current poin- > ter of the atomic. If both are the same nothing further happens - and > the cachelines holding the atomic<shared_ptr<X>> could remain in shared > mode. > I implemented that and the following code is the assignment-operator > of shared_obj<T> taking a tshared_obj<T>. The fast path is in the first > method and the slow path is in the second method:[...] Not sure what you mean. Traditional RCU reads do not need any atomic RMW's and/or memory barriers (alpha aside for a moment).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-10-05 21:03 +0200 |
| Message-ID | <11a0sae$17vgj$1@raubtier-asyl.eternal-september.org> |
| In reply to | #124911 |
Am 05.10.2026 um 19:57 schrieb Chris M. Thomasson: > On 10/5/2026 10:00 AM, Bonita Montero wrote: >> Am 17.09.2026 um 00:25 schrieb Joseph Seigh: >> >>> https://jseigh.wordpress.com/2026/09/07/consequential-concurrent- >>> sequential-rcu/ >> RCU isn't necessary. If shared_ptr<X> would have an assignment operator >> that takes an atomic<shared_ptr<X>> on the right side and this assign- >> ment operator would first compare its own pointer vs the current poin- >> ter of the atomic. If both are the same nothing further happens - and >> the cachelines holding the atomic<shared_ptr<X>> could remain in shared >> mode. >> I implemented that and the following code is the assignment-operator >> of shared_obj<T> taking a tshared_obj<T>. The fast path is in the first >> method and the slow path is in the second method:[...] > > Not sure what you mean. Traditional RCU reads do not need any atomic > RMW's and/or memory barriers (alpha aside for a moment). If I try to update my shared_obj<T> from a tshared_obj<T> and both are the same there are no atomic RMW-operations. Just a read of the pointer in memory which is in shared state in the cache. The update is just about a nanosecond if the tshared_obj<T> is still the same as at the last time I updated my shared_obj<T>. RCU is rather silly compared to that.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-06 13:15 -0700 |
| Message-ID | <11a3ktt$297t1$1@dont-email.me> |
| In reply to | #124912 |
On 10/5/2026 12:03 PM, Bonita Montero wrote: > Am 05.10.2026 um 19:57 schrieb Chris M. Thomasson: >> On 10/5/2026 10:00 AM, Bonita Montero wrote: >>> Am 17.09.2026 um 00:25 schrieb Joseph Seigh: >>> >>>> https://jseigh.wordpress.com/2026/09/07/consequential-concurrent- >>>> sequential-rcu/ >>> RCU isn't necessary. If shared_ptr<X> would have an assignment operator >>> that takes an atomic<shared_ptr<X>> on the right side and this assign- >>> ment operator would first compare its own pointer vs the current poin- >>> ter of the atomic. If both are the same nothing further happens - and >>> the cachelines holding the atomic<shared_ptr<X>> could remain in shared >>> mode. >>> I implemented that and the following code is the assignment-operator >>> of shared_obj<T> taking a tshared_obj<T>. The fast path is in the first >>> method and the slow path is in the second method:[...] >> >> Not sure what you mean. Traditional RCU reads do not need any atomic >> RMW's and/or memory barriers (alpha aside for a moment). > > If I try to update my shared_obj<T> from a tshared_obj<T> and both are > the same there are no atomic RMW-operations. Just a read of the pointer > in memory which is in shared state in the cache. The update is just > about a nanosecond if the tshared_obj<T> is still the same as at the > last time I updated my shared_obj<T>. > RCU is rather silly compared to that. > It seems like you are trying to compare using RCU to actually implement a strong atomic ref counted pointer. Of course RCU s not needed for that. Afaict, you might be missing the forest for the trees?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-10-07 05:19 +0200 |
| Message-ID | <11a4dnp$2gsaa$1@raubtier-asyl.eternal-september.org> |
| In reply to | #124918 |
Am 06.10.2026 um 22:15 schrieb Chris M. Thomasson: > It seems like you are trying to compare using RCU to actually implement > a strong atomic ref counted pointer. Of course RCU s not needed for > that. Afaict, you might be missing the forest for the trees? You don't understand my idea.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-06 21:29 -0700 |
| Message-ID | <11a4hrg$2i092$1@dont-email.me> |
| In reply to | #124922 |
On 10/6/2026 8:19 PM, Bonita Montero wrote: > Am 06.10.2026 um 22:15 schrieb Chris M. Thomasson: > >> It seems like you are trying to compare using RCU to actually >> implement a strong atomic ref counted pointer. Of course RCU s not >> needed for that. Afaict, you might be missing the forest for the trees? > > You don't understand my idea. > Are you trying to make a strong atomic ref count safe or not? RCU really does not have to have anything to do with that.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-10-07 15:01 +0200 |
| Message-ID | <11a5frn$2sm77$2@raubtier-asyl.eternal-september.org> |
| In reply to | #124924 |
Am 07.10.2026 um 06:29 schrieb Chris M. Thomasson: > Are you trying to make a strong atomic ref count safe or not? > RCU really does not have to have anything to do with that. My idea is totally different from RCU, but you can do the same thing with it with nearly no overhad.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-07 13:12 -0700 |
| Message-ID | <11a692l$370r9$2@dont-email.me> |
| In reply to | #124930 |
On 10/7/2026 6:01 AM, Bonita Montero wrote: > Am 07.10.2026 um 06:29 schrieb Chris M. Thomasson: > >> Are you trying to make a strong atomic ref count safe or not? >> RCU really does not have to have anything to do with that. > > My idea is totally different from RCU, but you can do the same > thing with it with nearly no overhad. > So, you are making a proxy collector? I am quite fond of them. Joe knows all about them.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-10-08 05:57 +0200 |
| Message-ID | <11a74au$3fl36$3@raubtier-asyl.eternal-september.org> |
| In reply to | #124933 |
Am 07.10.2026 um 22:12 schrieb Chris M. Thomasson: > So, you are making a proxy collector? I am quite fond of them. Joe knows > all about them. I think Joe understood my idea and you didn't.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-08 11:41 -0700 |
| Message-ID | <11a8o5d$402c$2@dont-email.me> |
| In reply to | #124939 |
On 10/7/2026 8:57 PM, Bonita Montero wrote:
> Am 07.10.2026 um 22:12 schrieb Chris M. Thomasson:
>
>> So, you are making a proxy collector? I am quite fond of them. Joe
>> knows all about them.
>
> I think Joe understood my idea and you didn't.
>
I think you should use his atomic_ptr and be done with it. It pure
lock-free. Yours is not:
____________
NOINLINE void shared_obj<T, ThreadMode>::slowAssign( const
tshared_obj<T, ThreadMode> &tso, data *pDtaRef ) noexcept
{
using namespace std;
for( ; ; )
{
if( !pDtaRef )
{
data *pData = m_pData;
if( pData && pData->decr() )
delete pData;
m_pData = nullptr;
return;
}
if( pDtaRef == (data *)-1 )
{
tso.m_pAtmData.wait( pDtaRef );
pDtaRef = tso.m_pAtmData.load( memory_order_relaxed );
}
else if( tso.m_pAtmData.compare_exchange_strong( pDtaRef, (data
*)-1, memory_order_relaxed, memory_order_relaxed ) ) [[likely]]
break;
if( m_pData == pDtaRef )
return;
}
m_pData = pDtaRef;
m_pData->incr( memory_order_acquire );
tso.m_pAtmData.store( pDtaRef, memory_order_relaxed );
tso.m_pAtmData.notify_all();
}
____________
Sigh.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web