11–20 of 26 posts
"What’s the behavior in the VLA version when n is so large that sizeof(*identity) doesn’t fit in a size_t?" Isn't size_t supposed to be as large as to fit the cardinality of the largest type you can create?
(Used · for multiplication, because HN turns stars into emphasis.)
>If there’s any risk that nmemb is too large, it must be guarded. [...] However, if median is expected to safely accommodate COPY_MAX elements, it may as well always allocate an array of this size. If it can’t, then that’s not a safe maximum. Et voilà, a library function that could have been portable between the smallest microcontroller and the largest workstation becomes restricted to a single application.
Not to mention that using stack allocation on low-memory device is extremely dangerous... at least with malloc you get a nice diagnostic, while alloca will just do random program damage.
>If there’s any risk that nmemb is too large, it must be guarded. [...] However, if median is expected to safely accommodate COPY_MAX elements, it may as well always allocate an array of this size. If it can’t, then that’s not a safe maximum. Et voilà, a library function that could have been portable between the smallest microcontroller and the largest workstation becomes restricted to a single application.
Um, no? That COPY_MAX would still need a different value between small MCU and full-blown PC. Not to mention that using stack allocation on low-memory device is extremely dangerous... at least with malloc you get a nice diagnostic, while alloca will just do random program damage.
In really small embedded you should not be allocating anything meaningful in the stack anyway.
> Stack allocations are trivial and fast by comparison: Allocation is a matter of bumping the stack pointer, and no synchronization is needed. And this is why runtimes with moving garbage collectors can be faster than malloc - allocation with such a GC is always this cheap even when it's to the heap. (The costs move elsewhere, of course, but ideally to another thread, and are temporally and spatially grouped so that…
Earlier quoted context omitted.
Allocation is always cheap, also with manual memory management. It's reclaiming/freeing memory which is the tricky part ;) Best approach is still to minimize dynamic allocation as much as possible. One can often get surprisingly far with an entirely static memory layout that's defined upfront at application start.
In support of flohofwoe's point: good implementations of malloc will, on the common path, just bump a pointer without synchronization. The allocation path of good manual allocator implementations and garbage collectors will probably look similar.
How does this work when the heap address space becomes fragmented, with randomly distributed available space and objects that are still live? You can't just bump when the next piece of memory may still be in use, and when you're not able to move memory.
>If there’s any risk that nmemb is too large, it must be guarded. [...] However, if median is expected to safely accommodate COPY_MAX elements, it may as well always allocate an array of this size. If it can’t, then that’s not a safe maximum. Et voilà, a library function that could have been portable between the smallest microcontroller and the largest workstation becomes restricted to a single application.
Um, no? That COPY_MAX would still need a different value between small MCU and full-blown PC. Not to mention that using stack allocation on low-memory device is extremely dangerous... at least with malloc you get a nice diagnostic, while alloca will just do random program damage.
Earlier quoted context omitted.
In support of flohofwoe's point: good implementations of malloc will, on the common path, just bump a pointer without synchronization. The allocation path of good manual allocator implementations and garbage collectors will probably look similar.
> In support of flohofwoe's point: good implementations of malloc will, on the common path, just bump a pointer without synchronization. How does this work when the heap address space becomes fragmented, with randomly distributed available space and objects that are still live? You can't just bump when the next piece of memory may still be in use, and when you're not able to move memory.
"What’s the behavior in the VLA version when n is so large that sizeof(*identity) doesn’t fit in a size_t?" Isn't size_t supposed to be as large as to fit the cardinality of the largest type you can create?
They're trying to allocate an n·n element array. If int and size_t are 32b (typical 32-bit architectures), and n == INT_MAX, then n·n·sizeof(float) can't be represented by a size_t. (Used · for multiplication, because HN turns stars into emphasis.)
Regardless, even without these unobtainium big machines, the cardinality of the largest array for a platform (by any number of dimensions) must be representable in size_t. A too large of an array would not fit in RAM and you should get a compile/link/out of memory error.
> Stack allocations are trivial and fast by comparison: Allocation is a matter of bumping the stack pointer, and no synchronization is needed. And this is why runtimes with moving garbage collectors can be faster than malloc - allocation with such a GC is always this cheap even when it's to the heap. (The costs move elsewhere, of course, but ideally to another thread, and are temporally and spatially grouped so that…
Very good GCs can be faster compared to common system allocators while minimizing the STW moment, but you cannot beat using a proper allocator for your needs.
How do you know this to be true?
And why isn't a GC a 'proper' allocator?