Why change the title? That's also against HN policy
I was surprised by how simple an allocator is
21–30 of 48 posts
Re: I was surprised by how simple an allocator is
#22Applications 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.
I think I found some solution for arenas in Go: https://pkg.go.dev/github.com/Snawoot/freelist
Has some shortcomings, but I think it should work.
Re: I was surprised by how simple an allocator is
#23>Seeing that mimalloc does not offer this feature
If you click on the issue you will see that mimalloc already does offer this feature via mi_manage_os_memory to create an arena, mi_heap_new_in_arena to create a heap that uses the arena, and mi_heap_malloc to allocate memory from the heap.
Re: I was surprised by how simple an allocator is
#24Earlier quoted context omitted.
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" https://www.youtube.com/watch?v=LIb3L4vKZ7U
Author of the post here. This talk was one of the talks I watched when learning about allocators. I thought about writing a part of the post about this talk but I didn't have much time.
Re: I was surprised by how simple an allocator is
#25but 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 implementa…
Allocator choice is a spice, not a staple. There’s various reasons to use one design vs another for your use case and no “one-size fits all”. Sometimes you want continuous memory. Sometimes you want sorted memory. Sometimes you want fast memory damned the internal fragmentation. Others, you want terse memory because you’re trying to fit a struct in 32 bytes. There’s a use case for it all.
Re: I was surprised by how simple an allocator is
#26Yes, but the article doesn't really show with code why it's simple.
A basic first-fit free-list type allocator can be less than 100 LoC - in x86 Asm. Using free space to store the overhead is a simple but effective optimisation too.
Re: I was surprised by how simple an allocator is
#27Applications 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.
defer and a stack allocator would probably go well together.
Start of scope mark the allocators state. defer when it goes out of scope you release everything. Cheezy would be the release function takes a list of objects to keep.
Re: I was surprised by how simple an allocator is
#28allocators can be simple but how about memory management kernel subsystems?
One question I have for those who know the topic at a greater depth: Are there simpler memory managers that don't use a fixed page size? Or does that make it a lot more complex? imagine requesting allocation of 1 byte and the kernel allocating a page of 1 byte and immediately you request 20GB and you get a 20GB page. Other than memory-management metadata taking up more memory on its own, what are the downsides of dynamic page sizes?
Re: I was surprised by how simple an allocator is
#29allocators can be simple but how about memory management kernel subsystems? One question I have for those who know the topic at a greater depth: Are there simpler memory managers that don't use a fixed page size? Or does that make it a lot more complex? imagine requesting allocation of 1 byte and the kernel allocating a page of 1 byte and immediately you request 20GB and you get a 20GB page. Other than memory-managem…
That's essentially what an allocator is, it's an abstraction between a requested size and alignment from the user space program and the memory management API that interfaces with the MMU hardware (which maps virtual addresses into physical addresses where the virtual address is a "page" number + offset). The MMU is what's dealing in pages and offsets more than the kernel.
Re: I was surprised by how simple an allocator is
#30> "The C standard library provides malloc/free/resize"
It does not provide a `resize`. You're thinking of `realloc` on hosted environments.