- Multi-threading question - 8 Updates
- merge-sort with alloca()-buffer - 1 Update
- C++17 and alignment... - 16 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 07:37AM +0100 >>> https://www.kernel.org/ >> Spinning is a userland-feature. > The kernel spins. ... No, spinning for a mutex is done in userland. The kernel simply stops a threads relaes it only when the futex is released - but not by spinning, that could be better done in userland. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 21 10:39PM -0800 On 1/21/2021 10:37 PM, Bonita Montero wrote: > The kernel simply stops a threads relaes it only when the futex > is released - but not by spinning, that could be better done in > userland. Spinning can happen in both lands, however... Usually, when talking about spinning it is used to avoid transitions from user to kernel land. As for a general spin count, well, its too sensitive to system conditions to give any concrete numbers. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 08:26AM +0100 > Spinning can happen in both lands, ... Spinning for a mutex doesn't make sense in the kernel. But there are spinlocks in the kernel, but that's a facility not provided to the userland. |
| scott@slp53.sl.home (Scott Lurndal): Jan 22 03:43PM >The kernel simply stops a threads relaes it only when the futex >is released - but not by spinning, that could be better done in >userland. You are obviously not a kernel engineer. The kernel itself has spin locks for it's own needs. I give up. You snip attributions and useful context. Begone troll. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 04:49PM +0100 > You are obviously not a kernel engineer. The kernel itself has > spin locks for it's own needs. I'm aware of kernel spinlocks. But they don't supply userland-mutexes. And that's what we're talking about. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 05:40PM +0100 > Spinning for a mutex doesn't make sense in the kernel. > But there are spinlocks in the kernel, but that's a facility > not provided to the userland. I just see that there are POSIX userland spinlocks ([*]). But this is very dangrous since a thread holding spinlock could be scheduled away while other threads keep spinning. I think that's provided only for a extremely rare purpose of threads that are pinned to dedicated CPU -threads that aren't allowed to execute different threads (CPU-bin- ning). But I don't think some should use that and Linus Torvalds also said that userland-spinlocks are a bad idea. [*] https://pubs.opengroup.org/onlinepubs/009696699/functions/pthread_spin_lock.html |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 06:20PM +0100 That's the "adaptive" mutex locking code of pthread_mutex_lock in the glibc 2.31: | else if (__builtin_expect (PTHREAD_MUTEX_TYPE (mutex) | == PTHREAD_MUTEX_ADAPTIVE_NP, 1)) | { | if (! __is_smp) | goto simple; | | if (LLL_MUTEX_TRYLOCK (mutex) != 0) | { | int cnt = 0; | int max_cnt = MIN (max_adaptive_count (), | mutex->__data.__spins * 2 + 10); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | do | { | if (cnt++ >= max_cnt) | { | LLL_MUTEX_LOCK (mutex); | break; | } | atomic_spin_nop (); That's just a PAUSE-instruction | } | while (LLL_MUTEX_TRYLOCK (mutex) != 0); | | mutex->__data.__spins += (cnt - mutex->__data.__spins) / 8; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | } | assert (mutex->__data.__owner == 0); | } | else |
| Juha Nieminen <nospam@thanks.invalid>: Jan 22 05:31PM > I don't know how to ask for this somewhere else. And I don't know why you bother asking at all, because you seem completely unwilling to read any answers. |
| Juha Nieminen <nospam@thanks.invalid>: Jan 22 05:29PM > You were talking about introsort first. And introsort is is partitially > quicksort, partititially heapsort. And neither quicksort nor heapsort > are stable. Did you read my first message at all? You wrote that your merge sort is slower than std::sort(), and I explained that to make merge sort faster you need to optimize it by using insertion sort for segments that are small enough, just like what std::sort() (which uses introsort) does. At no point did I make any mention whatsoever about using quicksort or heapsort. I don't understand where you are getting that from. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 21 09:34PM -0800 On 1/21/2021 3:17 PM, Chris M. Thomasson wrote: > Thanks to Bonita, I learned that C++17 actually works with alignas wrt > using new. This is very nice and am looking forward to using it quite a > bit. Here is some crude sample code: [...] Liking C++17 more and more. Thanks Bonita! std::vector seems to work fine with alignas. The way new works with alignas is very interesting. Love it. MSVC 2019 has a limit on alignas, but that's okay. _______________________ #include <iostream> #include <atomic> #include <cstdint> #include <cstdlib> #include <vector> static constexpr std::size_t ct_pages_n = 3; static constexpr std::size_t ct_page_size = 8192; static constexpr std::size_t ct_l2_cacheline_size = 64; template<typename T> static inline bool ct_assert_align(T const* ptr, std::size_t alignment) { return ! ((std::uintptr_t)(ptr) % alignment); } struct alignas(ct_l2_cacheline_size) ct_cacheline { std::atomic<std::uint64_t> m_state; }; struct alignas(ct_page_size) ct_page { ct_cacheline m_line_0; ct_cacheline m_line_1; ct_cacheline m_line_2; ct_cacheline m_line_3; }; static_assert(sizeof(ct_page) == ct_page_size); static_assert(sizeof(ct_cacheline) == ct_l2_cacheline_size); static void ct_page_iter( std::vector<ct_page> const& pages, std::size_t n ) { for (std::size_t i = 0; i < n; ++i) { ct_page const& page = pages[i]; if (! ct_assert_align(&page.m_line_2, ct_l2_cacheline_size)) { std::cout << "Crap!\n"; } } } int main() { std::vector<ct_page> page(ct_pages_n); // validate first element wrt page alignment if (! ct_assert_align(&page[0], ct_page_size)) { std::cout << "Big Time Crap!\n"; } // validate cache lines ct_page_iter(page, page.size()); return 0; } _______________________ Can you run this with outputting any Crap on your end? |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 07:38AM +0100 > I am getting a compile time error using a ct_page_size of 8192 * 4. > _________________________ > Error C2345 align(32768): illegal alignment value Sorry, that's stpuid. I'd never expect a support for alignment at the size of a page. BTW: a page is 4kB on x86. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 21 10:41PM -0800 On 1/21/2021 10:38 PM, Bonita Montero wrote: > Sorry, that's stpuid. I'd never expect a support for alignment at the > size of a page. > BTW: a page is 4kB on x86. Why? The larger the alignment the more one can steal from the aligned pointer. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 07:56AM +0100 > Why? ... Because there isn't any native type, even those platform-specific like those __512*-datatypes, which need an alignment of kBs. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 21 10:57PM -0800 On 1/21/2021 10:56 PM, Bonita Montero wrote: >> Why? ... > Because there isn't any native type, even those platform-specific > like those __512*-datatypes, which need an alignment of kBs. One can over align on purpose to steal bits and do other fancy things wrt, say, memory allocators. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 08:22AM +0100 >> like those __512*-datatypes, which need an alignment of kBs. > One can over align on purpose to steal bits and do other fancy > things wrt, say, memory allocators. There's no reason to declare data structures to be aligned beyond any native data type. |
| David Brown <david.brown@hesbynett.no>: Jan 22 08:43AM +0100 On 22/01/2021 08:22, Bonita Montero wrote: >> things wrt, say, memory allocators. > There's no reason to declare data structures to be aligned beyond > any native data type. Of course there is. What's the biggest native type? A 16-byte quad precision floating point, or 128-bit integer? Some sort of 64-byte SIMD vector? In the PC world, for high-performance code you would often want alignment based on cache line sizes. Once non-volatile ram becomes more common, it may be of interest to align to flash erase block lines. Certainly 4 KB alignment could be of interest in many cases. Alignments bigger than that are probably a lot less useful, however. In my embedded programming I have found use for large aligned data in circular buffers, especially when handled by DMA. And then there is the possibility of using the low bits in an aligned address for odd purposes - the bigger the alignment, the more bits you have to play with. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 08:53AM +0100 > vector? In the PC world, for high-performance code you would often want > alignment based on cache line sizes. Once non-volatile ram becomes more > common, it may be of interest to align to flash erase block lines. You can't directly address non-volatile RAM. They have a register-based block-level interface. > Certainly 4 KB alignment could be of interest in many cases. No, not for a single data structure. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 21 11:59PM -0800 On 1/21/2021 11:53 PM, Bonita Montero wrote: > block-level interface. >> Certainly 4 KB alignment could be of interest in many cases. > No, not for a single data structure. Why not? |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 09:10AM +0100 >>> Certainly 4 KB alignment could be of interest in many cases. >> No, not for a single data structure. > Why not? Because from the language-perspective a structure only needs to be aligned to the structure element with the largest alignment-requirement. |
| David Brown <david.brown@hesbynett.no>: Jan 22 11:04AM +0100 On 22/01/2021 08:53, Bonita Montero wrote: >> common, it may be of interest to align to flash erase block lines. > You can't directly address non-volatile RAM. They have a register-based > block-level interface. No - NVDIMM devices are directly addressable. Non-volatile ram is "randomly accessible memory". (That is different from SSDs and other non-volatile devices, which are viewed as block devices by the OS.) >> Certainly 4 KB alignment could be of interest in many cases. > No, not for a single data structure. You are very categorical about what you think people would never want to do. Don't you realise that you only ever see a very small section of the programming world? I've had occasional use for buffers with alignment a good deal bigger than 4 KB (in connection with DMA cyclic buffers in embedded systems). On PC's, I'd imagine that aligning to page boundaries could be useful in some types of coding. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 12:57PM +0100 > You are very categorical about what you think people would never want > to do. No, I think that the compiler only has to support alignment up to its built-in datatypes. > I've had occasional use for buffers with alignment a good deal bigger > than 4 KB (in connection with DMA cyclic buffers in embedded systems). Kernel-programming is beyond the means of C or C++. And you use the allocation-functions of your OS that give you aligned blocks. |
| David Brown <david.brown@hesbynett.no>: Jan 22 03:33PM +0100 On 22/01/2021 12:57, Bonita Montero wrote: >> to do. > No, I think that the compiler only has to support alignment up to its > built-in datatypes. What a compiler /has/ to support is not the same as what developers might find useful. A quick check of the C11 standards (since I have that document open, but not C++17 standards) shows that the compiler /has/ to support alignment up to the size of "max_align_t" (which is implementation dependent). It does not have to support anything bigger, but it can. Compilers are also free to have other alignment support beyond "alignas" (most do, since most have support that preceded the standardised "alignas"). A quick check with gcc shows it is quite happy with alignments up to 0x10000000, or 2 ^ 24. (I'm not suggesting that is likely to be useful.) Different compilers can have different limits. >> than 4 KB (in connection with DMA cyclic buffers in embedded systems). > Kernel-programming is beyond the means of C or C++. And you use > the allocation-functions of your OS that give you aligned blocks. Kernel programming is almost always done in C or C++. It is not "beyond their means". And I didn't use the large alignment in kernel programming - it was application code (though on such embedded systems there is usually no separate "kernel space" and "user space"). And I most certainly would /not/ use an allocation function for such purposes, even if I had an OS on the system. Quite clearly, there are uses of aligned data that are well beyond the levels of your knowledge and experience. That's fine, of course - you no doubt have done coding that is well outside the range of my knowledge and experience too. But you really should learn that there is a world beyond what you know - stop making up nonsense about what you think people do or do not want to do, based solely on your own small section of the programming world. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 04:00PM +0100 > What a compiler /has/ to support is not the same as what developers > might find useful. ... We're talking about C++, and not about your wishlist. > A quick check with gcc shows it is quite happy with alignments up to > 0x10000000, or 2 ^ 24. (I'm not suggesting that is likely to be > useful.) Different compilers can have different limits. For userland that's not necessary because if someone needs such an alignment, f.e. if he writes his own memory-allocator for an aligned pool, he uses VirtualAlloc(), mmap() or something else. But I don't see any need for a new to support an alignment of 24 bits. > Kernel programming is almost always done in C or C++. It is not "beyond > their means". Kernel-programming in C or C++ is totally different than in user-mode. You can only use a small portion of the standard library. And you have a totally different memory-allocation scheme. So you can't say kernel-programming is directly supported in C or C++. |
| David Brown <david.brown@hesbynett.no>: Jan 22 04:39PM +0100 On 22/01/2021 16:00, Bonita Montero wrote: >> What a compiler /has/ to support is not the same as what developers >> might find useful. ... > We're talking about C++, and not about your wishlist. Yes, C++ - not your unwarranted guesses about what people might want, need and use, and what tools might support. > alignment, f.e. if he writes his own memory-allocator for an aligned > pool, he uses VirtualAlloc(), mmap() or something else. But I don't > see any need for a new to support an alignment of 24 bits. I don't care if /you/ think it is useful or not. The point is that at least some compilers support it. > You can only use a small portion of the standard library. And you have > a totally different memory-allocation scheme. > So you can't say kernel-programming is directly supported in C or C++. I don't know why you are so convinced that you know everything, no matter how easily people demonstrate your ignorance. But obviously you have no interest in learning anything beyond your small section of the programming world - not even an interest in learning that there /is/ a world beyond it. I'll go back to my usual policy of ignoring you. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 04:48PM +0100 >> see any need for a new to support an alignment of 24 bits. > I don't care if /you/ think it is useful or not. The point is that at > least some compilers support it. There's no need for a support of 24 bit aligned allocations because if you need it that way you don't use new. > have no interest in learning anything beyond your small section of the > programming world - not even an interest in learning that there /is/ a > world beyond it. You simply didn't understand what I said above. |
| 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