• Patrick Schluter (19/37) Nov 16 2022 - heap allocation (gc or not) always imply a shared resource that

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

https://forum.dlang.org/post/nwocnkmpbtwntottdhhz forum.dlang.org

On Tuesday, 14 June 2022 at 02:29:57 UTC, forkit wrote:
 On Tuesday, 14 June 2022 at 01:54:03 UTC, rikki cattermole 
 wrote:
 There is no such thing as hardware assisted memory allocation.

 Memory allocators were data structures in 1980, and they still 
 are today.

 if I have a lot of spare memory, I cannot see the advantage of 
 stack allocation over heap allocation.

 i.e:

 advantage of stack allocation (over heap allocation):
 - no gc pauses
 - better memory utilisation

 these advantages become less relevant when plenty of spare 
 memory is available, true? In this situation, the only 
 advantage stack allocation would have over heap allocation, is 
 that stack allocation is somehow faster than heap allocation.

- heap allocation (gc or not) always imply a shared resource that 
require synchronization in some form or another.
- heap allocation (gc or not) has a much worse cache utilization 
(gc touches a lot of cache lines which will degrade cache 
utilisation).
- heap allocation (gc or not) is never O(1). Big allocations 
require often syscalls to request the memory from the system 
(sbrk, mmap, etc.) which themselves have non-linear complexities.
- as rikki already said, stack allocation is just adding a 
integer to a pointer (modern processors also have special stack 
optimizations that reduce the operations on stack/call/returns to 
almost nothing). Furthermore, as the stack is intensively used 
resource, its cache utilisation is enormous and as it is a thread 
local resource, there is normally few contention on the cache 
lines.

the main drawback of stack allocation is its limited size of and 
the risk of stack overflow.