dip1000 and preview in combine to cause extra safety errors

[Patrick Schluter]

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.