I was surprised by how simple an allocator is
tgmatos.github.io
I was surprised by how simple an allocator is
1–10 of 48 posts
Re: I was surprised by how simple an allocator is
#2[stub for offtopicness]
lol, I read this as "alligators are monkeys with typewriters" and thought it would be a well interesting article
but it's just more blah-blah about ai :/
Re: I was surprised by how simple an allocator is
#3[stub for offtopicness]
lol, I read this as "alligators are monkeys with typewriters" and thought it would be a well interesting article but it's just more blah-blah about ai :/
As Andrei Alexandrescu famously said, "Allocator is to allocation what alligators is to allegation"
Re: I was surprised by how simple an allocator is
#4[stub for offtopicness]
lol, I read this as "alligators are monkeys with typewriters" and thought it would be a well interesting article but it's just more blah-blah about ai :/
I think you might be commenting on the wrong article — this is an implementation of a memory allocator, as in, malloc.
Re: I was surprised by how simple an allocator is
#5Re: I was surprised by how simple an allocator is
#6On first seeing this I wasn't sure what analogy the author was trying to make. After reading the article my best guess is that they are simply trying to say that, writing an allocator is easier than it seems on the surface.
Though it's not clear to me that the article does a good job of establishing that this is actually true ("mimalloc is only a few thousand lines of code" doesn't pass the smell test).
Re: I was surprised by how simple an allocator is
#7but saying they're useless ignores a bunch of real systems that wouldn't run without them.
in unity, you literally can't do burst compiled jobs efficiently unless you choose the right allocator. they expose `Temp`, `Persistent`, etc because GC isn't even an option when you're fighting for milliseconds per frame. no allocator choice = frame skips = shipped bugs.
in embedded, FreeRTOS gives you multiple heap implementations for a reason. sometimes you need fixed size pools, sometimes you care about fragmentation. malloc's out of the question. same in any real time firmware, safety critical or not.
infra world has been using arena allocators for years. folly's `Arena`, grpc's arena, even jemalloc has thread caching and slab style region reuse built in. this isn't academic. large scale systems hit allocation pressure that general purpose allocators can't tune for globally.
and rust's whole alloc abstraction : it's more about expressing ownership across lifetimes in memory sensitive codebases. `Bumpalo` isn't a premature optimization. it's what you reach for when you know the object graph layout and want to free it in one call. also safe by design. it's not even painful to use.
imo allocator choice is an interface decision. it shapes how the rest of your code handles memory lifetimes. once you start passing memory lifetimes as part of your type system or job model, the whole architecture shifts. this is way deeper than faster malloc
Re: I was surprised by how simple an allocator is
#8[stub for offtopicness]
[flagged]
Re: I was surprised by how simple an allocator is
#9Applications should use more special-purpose memory allocators. Much of the complexity in memory management is designing for an unknown usage pattern and things can be quite simple when allocator is specialized and patterns are predictable.
This is difficult though in higher-level languages. Go tried and failed with arenas.
Re: I was surprised by how simple an allocator is
#10[stub for offtopicness]
From the title I thought he meant VCs.