- Multi-threading question - 3 Updates
- Users needed - 7 Updates
- Win32: WaitOnAddress vs. WaitForSingleObject - 5 Updates
- C++17 and alignment... - 3 Updates
- merge-sort with alloca()-buffer - 7 Updates
| Vir Campestris <vir.campestris@invalid.invalid>: Jan 25 09:41PM On 23/01/2021 00:47, Chris M. Thomasson wrote: > Never heard of TPAUSE before... > https://www.felixcloutier.com/x86/tpause > Sounds very nice! As Bonita says (but doesn't get the quoting right) and as you'll find in the proper manual at <https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf> User wait: TPAUSE, UMONITOR, UMWAIT Intel Atom processor based on Tremont microarchitecture and another 24 mentions of TPAUSE. Andy |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 25 01:53PM -0800 On 1/25/2021 1:41 PM, Vir Campestris wrote: > User wait: TPAUSE, UMONITOR, UMWAIT Intel Atom processor based on > Tremont microarchitecture > and another 24 mentions of TPAUSE. Very useful. It kind of seems that they were designed to aid in transactional memory scenarios that can livelock. I need to read: Programming with Intel® Transactional Synchronization Extensions |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 25 02:13PM -0800 On 1/24/2021 2:37 AM, Bonita Montero wrote: > Can you compile and link this: [...] > on my TR 3990X, it's about 3 clock cycles. It's used in spin-loops > and should be related to the time cacheline needs to travel from > one cache to another, and that's much more than 3 clock cycles. When I get some time. I need to use MASM for it, in an externally assembled file. Its been a while since I used MASM or GAS. |
| scott@slp53.sl.home (Scott Lurndal): Jan 25 04:06PM >you say, "no one cares for", it can mean -- no one wants >that. Anyway, when you are an entrepreneur, you have >to care about things that some people don't care about. He's saying that in the world of professional programming, the size of the executable codefile is completely uninteresting and not worth spending any time optimizing. You should worry about finding someone to pay you first. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 25 07:14PM +0100 > He's saying that in the world of professional programming, > the size of the executable codefile is completely uninteresting > and not worth spending any time optimizing. C++ is used mostly for large scale program development. And for this purposes the code-size doesn't matter. |
| David Brown <david.brown@hesbynett.no>: Jan 25 09:46PM +0100 On 25/01/2021 19:14, Bonita Montero wrote: >> and not worth spending any time optimizing. > C++ is used mostly for large scale program development. > And for this purposes the code-size doesn't matter. I think you'll find that C++ is used for a wide variety of purposes, and while code size doesn't matter in all cases, sometimes it does. It also depends on what you mean by "code size". If you are talking about a file on a disk, it usually doesn't matter much - especially on systems that only load in the parts they need. But the size of the active code sections can matter - the cache friendliness of important parts of the code can make a significant difference to the speed. (Like code size, often code speed is not particularly important - but sometimes it is.) Basically, when you make general statements about how C++ is used and what is important, you will get it wrong. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 25 12:59PM -0800 On 1/25/2021 12:46 PM, David Brown wrote: > sometimes it is.) > Basically, when you make general statements about how C++ is used and > what is important, you will get it wrong. Exactly. Well done. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 25 04:13PM -0500 On 1/25/21 3:46 PM, David Brown wrote: >> C++ is used mostly for large scale program development. >> And for this purposes the code-size doesn't matter. > I think you'll find that C++ is used for a wide variety of purposes, and No she won't - the only thing Bonita will ever find is what C++ is used for by Bonita, and that apparently only includes large scale program development. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jan 25 09:36PM On 25/01/2021 16:06, Scott Lurndal wrote: > He's saying that in the world of professional programming, > the size of the executable codefile is completely uninteresting > and not worth spending any time optimizing. Not always true. We're writing code for embedded devices, and we keep running into the storage size limits. We could of course make them bigger but (a) that wouldn't help people who've already bought them and (b) it makes them more expensive. Andy |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Jan 25 02:01PM -0800 > the only thing Bonita will ever find is what C++ is used > for by Bonita, and that apparently _only_ includes Bonita didn't say that, she said "C++ is used _mostly_ for ..." Whether that's true or not is an empirical question. I understand C++ is used a lot more in embedded, but I'm guessing that's still smaller than "large scale development." I don't understand why people feel the need to comment on the deficiencies of the poster as opposed to the content of the post. It does no good to the group. And to paraphrase my old grammar school teacher, when James talks about Bonita, we learn more about James than we do about Bonita. Daniel |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 24 04:32PM -0800 On 1/24/2021 9:24 AM, Manfred wrote: > viewpoint. Which can happen to be an interesting anthropology exercise. > Then there is always the weird case (e.g. "do not use smart pointers"), > where it helps to discuss it with the boss. One point, smart pointers come in different "flavors" so to speak. Check this one out: http://atomic-ptr-plus.sourceforge.net/ Joe Seigh is HYPER smart, and I loved conversing with him over on comp.programming.threads. He created a very nice smart pointer that has strong atomic semantics. Here is the patent: https://patents.google.com/patent/US5295262 (read all...) It is a beautiful algorihtm that can be directly implemented in pure C++ now, well now with C++11. Well, DWCAS, aka 100% lock-free on a double word, MUST be lock-free in order for it to "shine", so to speak. He coined the term, Proxy Garbage Collection. I came up with several algorithms that do not need DWCAS. Here is one of them: https://groups.google.com/g/lock-free/c/X3fuuXknQF0/m/u9IPh5fKoFcJ (read all to see my simulation code in Relacy...) https://pastebin.com/raw/f71480694 (raw code) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 24 05:13PM -0800 On 1/16/2021 1:35 PM, Chris M. Thomasson wrote: > > } > But, either way, it is in the wrong place. A release barrier must be > placed _before_ the atomic logic that actually increments the semaphore. [...] You need to correct this error! |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 25 09:58AM +0100 >> placed _before_ the atomic logic that actually increments the semaphore. > [...] > You need to correct this error! If I'm doing a kernel call in this case I don't need a barrier. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 25 12:53PM -0800 On 1/25/2021 12:58 AM, Bonita Montero wrote: >>> placed _before_ the atomic logic that actually increments the semaphore. >> [...] >> You need to correct this error! Manually adding in relevant message: _______________________________________ > > { > > m_semCounter.fetch_add( 1, std::memory_order_relaxed ); > > return futex( (uint32_t *)&m_semCounter, FUTEX_WAKE, 1, nullptr, > 0, 0 ) == 1; > > } > But, either way, it is in the wrong place. A release barrier must be placed _before_ the atomic logic that actually increments the semaphore. [...] _______________________________________ > If I'm doing a kernel call in this case I don't need a barrier. Huh? Your code is broken. Even if a syscall acts like a barrier. You snipped relevant parts again. See, your barrier is in the _wrong_ place for releasing a semaphore. Its simply in the wrong place, period. You can correct that rather easily. A release member needs to be _before_ the atomic logic that actually increments the semaphore. There is a simple way to correct your code. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 25 12:58PM -0800 On 1/25/2021 12:53 PM, Chris M. Thomasson wrote: >>> [...] >>> You need to correct this error! > Manually adding in relevant message: I forgot to add in my name for my comment. See, if you would just sort of "give in" and add proper quotes, I would not have to do this manually. Anyway, to reiterate... Even if a syscall is a full barrier, think #StoreLoad on the SPARC, it is still in the wrong place in your code. Big time. > > > return futex( (uint32_t *)&m_semCounter, FUTEX_WAKE, 1, > nullptr, > 0, 0 ) == 1; > > > } Chris M. Thomasson wrote: |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 25 10:01AM +0100 >> So there's no need for such a large alignment. > There are many reasons to use a "large" alignment. I'm still asking for those reasons and no none tell me them. > Also, over alignment is useful wrt, say, a cacheline. Iirc, when > hyperthreading first came out one would use 128 byte cachelines, > split in two. That's a differnt thing than alignment on page-sizes; which isn't needed because you use different allocation-functions then which do this alignment. > https://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/pentium4_hh/advice4_hh/avoiding_64k_aliasing.htm Use mmap() or VirtualAlloc ... |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 25 12:45PM -0800 On 1/25/2021 1:01 AM, Bonita Montero wrote: >>> So there's no need for such a large alignment. >> There are many reasons to use a "large" alignment. > I'm still asking for those reasons and no none tell me them. I told you several of them in this thread. You have a knack to snip relevant information. Also, please... Please try to quote properly. ;^) Remember when you were "convinced" that a mutex is an atomic counter? Then I showed how you are wrong? This is going down a similar path... > That's a differnt thing than alignment on page-sizes; which isn't > needed because you use different allocation-functions then which > do this alignment. What if somebody wants to do page alignment using standard C++? Why do you insist on telling them they should not be able to do that? Just because you think something should not be done, does not mean you are correct. You should write to compiler vendors and tell them that over alignment on a page should not be supported. :^) I am happy that some compilers support that. >> https://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/pentium4_hh/advice4_hh/avoiding_64k_aliasing.htm > Use mmap() or VirtualAlloc ... The link references offsetting thread stacks to get around the deadly 64k aliasing issue. It would cause false sharing all over the place. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 25 12:49PM -0800 On 1/25/2021 12:45 PM, Chris M. Thomasson wrote: > correct. You should write to compiler vendors and tell them that over > alignment on a page should not be supported. :^) > I am happy that some compilers support that. To clarify, I am happy that some compilers support over alignment up to, and even beyond page alignment. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 24 05:06PM -0800 > I don't know about everyone else, but personally I've found the topics > introduced by Bonita to be worthy, and the discussions between > Bonita and Chris to be interesting. I hope these continue. So do I. Bonita makes me think of my past. Making me remember hard core threading sync algorithms. |
| Richard Damon <Richard@Damon-Family.org>: Jan 24 09:27PM -0500 > other posts, where disassembly code is discussed. But there are lots of things > that we can do, but would prefer not to have to do. > Daniel The fact that she said she COULDN'T debug the code in a macro. (emphasis added). It wasn't just harder, it couldn't be done. Then when the technique was described, it was then dismissed as apparently something very uncommon to do. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 24 06:47PM -0800 On 1/24/2021 11:00 AM, Ian Collins wrote: >> expansion to 'debug' them. You can also step through the assembly code >> generated if it is an execution problem. > CLion supports inspecting and stepping through macros. I did not know that! Thanks Ian, and everyone else. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 24 06:52PM -0800 On 1/24/2021 6:27 PM, Richard Damon wrote: > added). It wasn't just harder, it couldn't be done. > Then when the technique was described, it was then dismissed as > apparently something very uncommon to do. I have noticed a little pattern akin to that as well. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 24 10:43PM -0800 > but if the user actually did mistakenly omit a right parenthesis or > add an extra argument, any compiler error message would likely be > incomprehensible. Frequently incomprehensible are also the compiler errors from template metaprogramming. There was briefly nice constexpr metaprogramming but C++17 deleted a way to handle compile-time errors (and to have compile time diagnostics) using it. So metaprogramming of C++ has bad diagnostics ... should it be avoided because of that? > with one of your points of view, sometimes you respond with > disparaging comments about that person, and sometimes you > don't? Depending on who it is? I do not know why low experience is defamatory? We all started there. It is better to be without experience than to have long experience how some ugly things are without alternatves but still pretend to be blind to it. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 25 07:14AM > I don't know about everyone else, but personally I've found the topics > introduced by Bonita to be worthy, and the discussions between > Bonita and Chris to be interesting. I hope these continue. I agree BM may write about interesting things, and people make serious attempts to respond. The problem is, it always goes downhill from there. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Jan 25 06:18AM -0800 On Monday, January 25, 2021 at 2:14:52 AM UTC-5, Jorgen Grahn wrote: > I agree BM may write about interesting things, and people make serious > attempts to respond. The problem is, it always goes downhill from > there. All discussions go downhill very quickly as soon as people start feeling the need to comment on the deficiencies of the poster as opposed to the content of the post. Daniel |
| 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