What about an `undefs` function in `Base`?

[Sukera]

@mkitti

As Carsten Bauer mentioned, there is a better solution than undefs for the novice user where they can obtain nearly the same performance. This is calloc, a standard C function. On operating systems, there also more specialized methods in the same vein.

“Better” is a very subjective term here, as has already been explained in the very thread you linked. There is more to the story there than “just” dropping in calloc as a replacement to malloc and be done with it.

@mkitti

I have since packaged this into ArrayAllocators.jl. Let me offer a brief demonstration.

This benchmark is misleading because it does not zero the memory until sum is called. Please don’t sweep the big caveat of using calloc under the rug and present it as a pure win in performance - it just isn’t. I’ve already benchmarked this in the other thread extensively.

@DNF

Would that work for all kinds of data types? zeros really only makes sense for numerical data. What about allocations of unitialized data in general?

No - this only “works” for types where a zero bitpattern also happens to coincide with the zero of that type, as I mentioned in the linked thread:

@Sukera

In fact, for user defined types zeros has to use malloc with initialization because a zero-filled block of memory may not be valid for zero of a user defined type! As you note, it may be boxed or a number of other things, like not being isbits or simply not having a block of zeros as its zero representation.

In which case, using calloc by default means the memory is initialized twice, once by the kernel when it gives you the memory that’s filled with 0, and once when julia has to inevitably call zero to initialize the data properly. This will lead to users being confused about why zeros is slower than it needs to be and should thus be avoided.

@mkitti

The knowledge I’m using above is:

1. The underlying memory representation of Vector{Vector{Int}} is an array of pointers.
2. #undef actually means those pointers are C_NULL (in other words, 0)
3. When set, the pointers point to a jl_array structure which has 48 bytes of meta data before the array contents.

All of these are internal implementation details you cannot rely on. Do not assume these to be true.

---

The interface for allocation I would prefer to all options presented here looks like this:

"""
Allocate a single object of type `T`, using memory managed by `Allocator`.
Return a `T`, throws an OutOfMemory exception when it fails to allocate memory.
"""
allocate(::Allocator, ::T)

"""
Allocate `n` objects of type `T`, using memory managed by `Allocator`.
Return a collection of `T`, throws an OutOfMemory exception when it fails to allocate memory.
"""
allocate(::Allocator, ::T, n)

This is how Zig does it, and for good reason - you don’t need more. Rust has some more fanciness for deallocation. Both of these can be used in the compiler to hoist allocations to the stack if need be. The second one semantically returns an Array (or a fixed-size equivalent) when passed a default GC.

@jar1

In this API there’s no room to say where the memory comes from, we just pull it out of the sky. If I have a block of memory, I might want to split it up and make arrays and dictionaries out of it, e.g. using allocate!(block, Array, Float64, (2,2)).

That’s because “splitting the memory up” to create other objects out of is not a safe operation - if you allocate a large array and use that as the “backing memory” for multiple objects, you’re well on the way of reimplementing a memory manager yourself. For the regular julia GC, it would have to keep that big chunk around as long as even a single other object (that may use only a tiny portion of that memory) is still accessible. You really need the allocator passed in the API to handle that part of the operation for you.