5 ms·

This article is about 10 times longer than it needs to be. Also no need for the dripping condescension. I’m even among the most receptive to what he’s trying to

This article is about 10 times longer than it needs to be. Also no need for the dripping condescension. I’m even among the most receptive to what he’s trying to say, but got exhausted after about 20% of the article and had to give up.

vitiral 4y ago
As someone already sold on arenas I appreciated both the depth and battle story style. Perhaps the author is mis-targeting: they are preaching to the choir instead of converting the sinners =]
- sfpotter 4y ago
  If they’re preaching, it’s quite a long and boring sermon, IMO ;-) Battle stories should be exciting
Diggsey 4y ago
Yeah, arena allocators are a great tool, but they are not a magic bullet either. Also the author's condescension about automatic memory management is... telling. Remembering to call "free" is only one small part of why tools like RAII are good, and arena allocators do not help with the other parts. The overall goal is to be able to write correct, reliable, performant software. Arena allocators help prevent missed or double frees, but they don't help with the other memory safety issues. For example, sometimes objects in different arenas need to reference each other and C does not help prevent you from accessing those references after one of the arenas has been freed. On top of that there are general issues with arena allocators: 1. They can be inefficient for resizable collections where you don't know the total length in advance. The multiple re-allocations results in a lot of wasted space in the arena. 2. In C, it's implicit which objects should belong to which arena. 3. It's not composable. A library doesn't necessarily know which objects should use which arena, or may not even support arena allocation at all. 4. There are other resources than just memory. There's a reason it's called RAII and not MAII - because it allows you to clean up all kinds of resources (eg. file handles) when an arena allocator doesn't typically support any kind of destructor. 5. It requires more thought to structure your program in this way. For some programs that may be effort well spent, but a lot of programs are not bound by allocation performance, and for those programs not thinking about allocation at all leaves more time for thinking about correctness in other aspects. 6. Languages which do automatic memory management can still support arenas, and may offer additional benefits when they do (eg. Rust's explicit lifetimes can tie an object to the arena it came from). 7. The stack and heap are global resources that most code can simply assume exist, and use with no extra ceremony. When you have arenas in play, these need to be passed as additional arguments. Adding a new allocation to a function can require sweeping changes to add a new arena parameter to every function above it in the call stack.
- jeltz 4y ago
  I generally agree with what you wrote but have some corections based on having worked with arena allocators. 4. Nothing prevents arena allocators to track other resources than memory. 7. This is not a big problem in practice from my experience. You can just do like Zig and always pass an allocator or you can use global/thread local variables like PostgreSQL. But I also would like to add my biggest issue with arena allocators: they do nothing against use after free.
- hinkley 4y ago
  > 3. It's not composable. A library doesn't necessarily know which objects should use which arena, or may not even support arena allocation at all. > 6. Languages which do automatic memory management can still support arenas, and may offer additional benefits when they do (eg. Rust's explicit lifetimes can tie an object to the arena it came from). Languages with automatic memory management don't expose the arenas as an implementation detail, and so they are free to work out how to compose them, and when to change their minds. Java has had copying collectors practically from the beginning, and that ability to rewrite pointers after the fact affords you the ability to work with heuristics that have known failure modes, where any mistake becomes a use-after-free bug. Moving an object out of a volatile arena is just an inconvenience. So it evolved from generational collectors, to thread local arenas, to thread local arenas where some objects that are likely to survive are never allocated into the arena but 'pre-tenured'. This process really hit its stride with the introduction of escape analysis, which is a logical ancestor of today's borrow checker. With escape analysis you know for certain some objects never escape, in which case you can even inline simple objects (eg, register allocation). And if an arena has an escape probability of 0, there's less guard logic to deal with, and there is some short circuiting one can do when considering the root set for Mark and Sweep.
adamrezich 4y ago
on the contrary, I find this article to be excellent. none of this stuff was ever taught to me in school, which is nuts given that the school I went to was specifically tailored toward video game development, and had[0] students create their own game engines almost entirely from scratch in C (a helper library was provided to do basic graphics things) during their second semester, and then had students create their own game engines, entirely from scratch, in C++ during their sophomore year. again: nothing like this was ever presented to us, except as some sage wisdom from upperclassmen who had figured it out on their own. you learn malloc/free when you learn C, then you learn new/delete/RAII when you learn C++, and you get a brief overview of how garbage collection broadly works in higher-level languages, and that's it, that's the education about memory management. I had never explicitly heard of the concept of a "lifetime" until Rust started gaining traction. it wasn't until working on my sophomore year game engine that an upperclassman explained the idea of building a memory-managing array-like data structure that, instead of reallocating when the capacity is reached, instead leaves the existing items where they were and allocates a new "page" of memory, so as to ensure pointers to existing items remain functional. hell, I'd never even been exposed to the idea of a per-frame "scratch" pool allocator until I saw Jon Blow talk about having such a thing as a built-in feature of his new programming language. once I saw how it worked, I was floored—it's such an easy-to-explain concept, infinitely useful, basically gives you "garbage collection for free" for any number of one-off things you need allocations for in a given frame of a video game (or other interactive application)—without the need for Actual Garbage Collection! I agree that this article is a bit lengthy, but in my opinion it does a great job of setting up the knowledge necessary to understand what it's talking about, so I'm not really sure how I'd do a better job. what in particular did you find condescending about it, especially within the first fifth of the article? --- [0] from what I've heard, this from-scratch game-engine-creation is now gone from the curriculum entirely, and now students just make shit in unreal or unity, which is tragic, imo.
- sfpotter 4y ago
  "Through my years in a university computer science program, this way of thinking was peddled repeatedly. Learning how to manage memory in C was an endeavor to “learn how things work”, strictly for academic purposes. The idea that anyone would ever actually do manual memory management in C these days was just unthinkable—I mean, after all, it’s current year, and everyone knows that once it’s current year, an arbitrary set of ideas that I don’t like become intrinsically false." It's impossible for me not to read this without imagining a sneering tone. And a few paragraphs later: "As you may be able to tell from my tone, I think this way of thinking is nonsensical." As for your post, it's hard for me to get worked up about whatever the game programming curriculum is these days. There are more important things in the world. Good to keep things in perspective: it's school... for game programming.
abnercoimbre 4y ago
We're having Ryan at Handmade Seattle [0] this November to discuss memory management strategies (with other engineers across the memory-safety spectrum.) You might prefer a public, conversational setting at the conference instead of a personal blog post. That said the article made useful technical points. And he wasn't hurling expletives or denigrating any individual. [0] https://handmade-seattle.com/ https://handmade-seattle.com/
- sfpotter 4y ago
  That’s great! Good luck with your conference. I hope you can appreciate that there’s room between “technically correct” and “hurling expletives” for some someone to simply dislike an article. I regret my response struck a nerve—it certainly was not meant as an attack on its author.

vitiral 4y ago

As someone already sold on arenas I appreciated both the depth and battle story style. Perhaps the author is mis-targeting: they are preaching to the choir instead of converting the sinners =]

sfpotter 4y ago
If they’re preaching, it’s quite a long and boring sermon, IMO ;-) Battle stories should be exciting

Diggsey 4y ago

Yeah, arena allocators are a great tool, but they are not a magic bullet either. Also the author's condescension about automatic memory management is... telling. Remembering to call "free" is only one small part of why tools like RAII are good, and arena allocators do not help with the other parts. The overall goal is to be able to write correct, reliable, performant software. Arena allocators help prevent missed or double frees, but they don't help with the other memory safety issues. For example, sometimes objects in different arenas need to reference each other and C does not help prevent you from accessing those references after one of the arenas has been freed. On top of that there are general issues with arena allocators: 1. They can be inefficient for resizable collections where you don't know the total length in advance. The multiple re-allocations results in a lot of wasted space in the arena. 2. In C, it's implicit which objects should belong to which arena. 3. It's not composable. A library doesn't necessarily know which objects should use which arena, or may not even support arena allocation at all. 4. There are other resources than just memory. There's a reason it's called RAII and not MAII - because it allows you to clean up all kinds of resources (eg. file handles) when an arena allocator doesn't typically support any kind of destructor. 5. It requires more thought to structure your program in this way. For some programs that may be effort well spent, but a lot of programs are not bound by allocation performance, and for those programs not thinking about allocation at all leaves more time for thinking about correctness in other aspects. 6. Languages which do automatic memory management can still support arenas, and may offer additional benefits when they do (eg. Rust's explicit lifetimes can tie an object to the arena it came from). 7. The stack and heap are global resources that most code can simply assume exist, and use with no extra ceremony. When you have arenas in play, these need to be passed as additional arguments. Adding a new allocation to a function can require sweeping changes to add a new arena parameter to every function above it in the call stack.

jeltz 4y ago
I generally agree with what you wrote but have some corections based on having worked with arena allocators. 4. Nothing prevents arena allocators to track other resources than memory. 7. This is not a big problem in practice from my experience. You can just do like Zig and always pass an allocator or you can use global/thread local variables like PostgreSQL. But I also would like to add my biggest issue with arena allocators: they do nothing against use after free.
hinkley 4y ago
> 3. It's not composable. A library doesn't necessarily know which objects should use which arena, or may not even support arena allocation at all. > 6. Languages which do automatic memory management can still support arenas, and may offer additional benefits when they do (eg. Rust's explicit lifetimes can tie an object to the arena it came from). Languages with automatic memory management don't expose the arenas as an implementation detail, and so they are free to work out how to compose them, and when to change their minds. Java has had copying collectors practically from the beginning, and that ability to rewrite pointers after the fact affords you the ability to work with heuristics that have known failure modes, where any mistake becomes a use-after-free bug. Moving an object out of a volatile arena is just an inconvenience. So it evolved from generational collectors, to thread local arenas, to thread local arenas where some objects that are likely to survive are never allocated into the arena but 'pre-tenured'. This process really hit its stride with the introduction of escape analysis, which is a logical ancestor of today's borrow checker. With escape analysis you know for certain some objects never escape, in which case you can even inline simple objects (eg, register allocation). And if an arena has an escape probability of 0, there's less guard logic to deal with, and there is some short circuiting one can do when considering the root set for Mark and Sweep.

adamrezich 4y ago

on the contrary, I find this article to be excellent. none of this stuff was ever taught to me in school, which is nuts given that the school I went to was specifically tailored toward video game development, and had[0] students create their own game engines almost entirely from scratch in C (a helper library was provided to do basic graphics things) during their second semester, and then had students create their own game engines, entirely from scratch, in C++ during their sophomore year. again: nothing like this was ever presented to us, except as some sage wisdom from upperclassmen who had figured it out on their own. you learn malloc/free when you learn C, then you learn new/delete/RAII when you learn C++, and you get a brief overview of how garbage collection broadly works in higher-level languages, and that's it, that's the education about memory management. I had never explicitly heard of the concept of a "lifetime" until Rust started gaining traction. it wasn't until working on my sophomore year game engine that an upperclassman explained the idea of building a memory-managing array-like data structure that, instead of reallocating when the capacity is reached, instead leaves the existing items where they were and allocates a new "page" of memory, so as to ensure pointers to existing items remain functional. hell, I'd never even been exposed to the idea of a per-frame "scratch" pool allocator until I saw Jon Blow talk about having such a thing as a built-in feature of his new programming language. once I saw how it worked, I was floored—it's such an easy-to-explain concept, infinitely useful, basically gives you "garbage collection for free" for any number of one-off things you need allocations for in a given frame of a video game (or other interactive application)—without the need for Actual Garbage Collection! I agree that this article is a bit lengthy, but in my opinion it does a great job of setting up the knowledge necessary to understand what it's talking about, so I'm not really sure how I'd do a better job. what in particular did you find condescending about it, especially within the first fifth of the article? --- [0] from what I've heard, this from-scratch game-engine-creation is now gone from the curriculum entirely, and now students just make shit in unreal or unity, which is tragic, imo.

sfpotter 4y ago
"Through my years in a university computer science program, this way of thinking was peddled repeatedly. Learning how to manage memory in C was an endeavor to “learn how things work”, strictly for academic purposes. The idea that anyone would ever actually do manual memory management in C these days was just unthinkable—I mean, after all, it’s current year, and everyone knows that once it’s current year, an arbitrary set of ideas that I don’t like become intrinsically false." It's impossible for me not to read this without imagining a sneering tone. And a few paragraphs later: "As you may be able to tell from my tone, I think this way of thinking is nonsensical." As for your post, it's hard for me to get worked up about whatever the game programming curriculum is these days. There are more important things in the world. Good to keep things in perspective: it's school... for game programming.

abnercoimbre 4y ago

We're having Ryan at Handmade Seattle [0] this November to discuss memory management strategies (with other engineers across the memory-safety spectrum.) You might prefer a public, conversational setting at the conference instead of a personal blog post. That said the article made useful technical points. And he wasn't hurling expletives or denigrating any individual. [0] https://handmade-seattle.com/ https://handmade-seattle.com/

sfpotter 4y ago
That’s great! Good luck with your conference. I hope you can appreciate that there’s room between “technically correct” and “hurling expletives” for some someone to simply dislike an article. I regret my response struck a nerve—it certainly was not meant as an attack on its author.