Hacker News

points by tialaramex 1 day ago | 0 comments

Odin ends up pointlessly carrying around Allocator structures for each such container, each of which is two words (so e.g. 16 bytes on a modern system) because of how Odin works.

So e.g. that growable array of i64 you've asked for - just the data structure itself, not the array which was the whole point - needs 40 bytes on a modern machine because it has 8 bytes for a pointer to the array, 8 bytes for the size of that array, 8 bytes for how much was used, 8 bytes for a pointer to the allocator procedures and 8 bytes for a (sometimes unused) metadata structure for that allocator.

It's not a huge amount of waste, but what you get for it isn't worth it.

In Zig they're at least not paying for this with runtime space, they're paying for it with the programmer's need to make sure they talk about the same allocator everywhere.

[–] rallyroger 1 day ago

But instead you bloat up every call site with an extra argument that needs to be passed, which takes up a few bytes of instructions + claiming a register for it which could have been used for other arguments (and having the allocator in a register is probably a waste since it's a hopefully rare thing to need to access).

[–] bunderbunder 1 day ago

I wonder how bad that really is in practice.

Hypothetically the code is consolidating sites where allocation happens. Zig’s design seems to really push you toward this by making anything else a PITA. So then that allocator reference is being used frequently and already sitting in a register anyway.

The few extra instructions for explicitly passing it might be small compared to the cost of having objects carry their own references. That would grow each instance by ~8 bytes. It would mean that the pointer to the allocator needs to be pulled from a unique memory location for each instance, which is maybe an order of magnitude slower than already having it in a register. Larger data structures would also mean more cache misses, which are another order of magnitude slower.

And this is all chicken feed compared to actually taking a walk of shame out to the DRAM to fetch more memory. So the language ergonomics encouraging you to consolidate your allocation might trump all other considerations in practice.

[–] tialaramex 1 day ago

Note that in Odin you are already paying for an extra register because you silently move a magic "context" variable around in a register.

I haven't looked at the details in Odin, but it's definitely sensible to have the growth decision inline, which means only the (rare) growth itself needs the extra parameter.

[–] philippta 1 day ago

FWIW you can make procedures contextless:

    proc "contextless" ()

[–] tialaramex 1 day ago

You can, but Odin does not mark these procedures contextless and indeed it mustn't because in some cases it will fill out the allocator values by looking in the context, which it couldn't do if it did not have context.

[–] 14113 1 day ago

But you need to keep track of the allocator somewhere, as otherwise you don't know how to deallocate a container, or its contents. You either pay a very small cost in memory, or have to structure all your code to keep track of the allocator for everything you create.

[–] tialaramex 1 day ago

Or it can just live in the type system, as it does in Rust. This is basically always going to be cheaper, and for the case where you just want a single global default allocator it's free instead of two pointers.

I think with Rust 1.100 next month you could write an OdinStyleAllocator type which impl std::alloc::Allocator and has the two pointers inside it, and do the thing Odin does here if you wanted that but I expect you'd snap out of it.