hillarious, i was just about to make a comment about exactly that talk lol

Reminds me of a colleague, who says if life sucks, remember your also ugly, so now I need 2 of those ...

I had a similar but different problem thinking I was dumb when moving from the N to N+1 stage. Any time I was trying to write code, I would do the N stage despite feeling like I was trying to control an uncontrollable mess, and guarding against all sorts of obscure error points and handling them. And I'd feel like I was just dumb compared to others who did manage it. My "solution" at the time was to basically just write everything into self contained libraries that were pieced together by a main loop; but even that didn't work and was hard, especially with shared data. Easier, sure, but hard. But every now and then I'd steer away from "idiomatic" N ways of doing things and _slightly_ onto the path of N+1... I'd say I mostly hit the N+0.4 stage... And despite seeing its effects where things became easier to manage, and error handling collapsing down to just a few points, I just felt like it just wasn't "proper programming"; and that despite the objective better results, I should return to stage N because it is "proper" and what people teach. At some point I almost came up with a pool allocator for a project, and while I could see that it was better, I couldn't quite figure out the general trend that made it better or how to continue that trend, but I knew that the way I had done things before objectively sucked, and there *had* to be a better way. Thankfully, having found Casey and moving from C to Odin, I finally figured out what I was doing wrong, and this video finally clicked. I have a friend now who's getting into programming in Java, and the biggest advice I gave to him was to understand what problem he needs to solve, and once that gets solved, no matter how "wrong" or weird that solution is - stick to it _until_ the problem changes. Write the simplest thing you can, and if it works, then it works and is *done*. It's not wrong if it works and solves the problems you care about.

RAII shouldn’t have any extra error checks. The only thing it does is to ensure all resources are properly freed when the object is destroyed. For example, if you’re implementing a file handler or a network socket, you most likely need a .close() method to ensure there are no dangling handlers. With RAII, that .close() method is the destructor. Same thing with heap allocations. If your class does any heap allocations, then you just ensure all heap allocations are freed inside the destructor. No need for a separate .free() method that must be manually called. The destructor is always called when the variable goes out of scope. No risk of dangling file handlers just because the function returned early. If you’re handling multiple resources at the same time, then RAII ensures all resources are always freed in the correct order. If you’re only relying on stack allocations, then you don’t need to do anything extra. It’s already RAII. You’re probably using RAII without realizing it.

@@oscarfriberg7661 You can argue semantics like that. But the RAII I know is specifically about utilizing constructors and destructors, and is rooted in individual-object thinking. I've seen some proponents argue that the stack is also RAII or that linear allocators and memory arenas are also RAII, but I think that's a misrepresentation and muddling of the term. RAII is an idiom meant to prevent resource leaks of individual things. Pushing/popping to the stack is integrated in assembly language and precedes RAII. Also, linear allocators and memory arenas don't need constructors/destructors. E.g. a scratch arena could be 50MB (growable) that is zeroed once per frame, and thus there's never a concern about lifecycles of the memory pushed unto it. Talking about RAII in that context makes very little sense.

​​@@Muskar2no you are wrong or whoever told you that was wrong. RAII is about invariants and being able to enforce them. A class or type that is backed by a arena allocator, uses RAII to acquire/release its use, for instance, atomically reducing the use count in the destructor. The point of RAII is also to have a single place of exit so you don't have to consider it at every call site, it's automatic. Say you have activation frame A, and it does some things, until you have frames A, B, C, D, E, F, so 6 stack frames. In A you have created an arena allocator for everything below A. All the objects under this frame, use this arena. Their destructor may be designed to be a no-op, it may do something else, depending on if the arena can re use memory, but it will happen automatically. That's the point of RAII that, between initialization and destruction (even if said destruction is a no op and does nothing) class invariants are upheld. Even Casey gets RAII wrong, though he is right that it's thought of like he describes it, which is the *real* problem. You can have RAII and what Casey says and they will work perfectly together. Perfectly.

​@@simonfarre4907 RAII literally means Resource Acquisition Is Initialization, and stripping all the interpretations of that, it means ensuring all 'resources' of an 'object' are allocated and initialized before a programmer uses it. Which inherently is an individual element OOP concern, where your 'objects' points to their dependencies. That's not useful to think about if you simply have data that needs no initialization and has no 'resource' dependencies. E.g. when you create a bunch of int and float variables in a function (pushed on the stack), RAII makes no sense to talk about, because there's no concern that there's unallocated memory or a unknown pointer chain with a null pointer somewhere. It's all known by and visible to the programmer. Similarly, all individual elements that are allocated with an arena have no memory ownership concerns, because it is managed entirely by that arena (and the programmer always has a ballpark idea about the constraints of that arena's strategy). You could argue the arena is sort of RAII, because it needs to ask the OS for memory to be initialized, but that is a tiny dependency that both happens infrequently and isn't an interesting aspect of the program. When you say 'atomically reducing the use count in the destructor' what destructor are you talking about? A (scratch) arena for small short-lived allocations have no destructor for individual elements, the entire thing is just reset once per main loop and you just freely push things onto it. And the scratch arena itself typically lives for the lifetime of the application, so there's no need for any destructor. On the other hand, arenas for long-term data with well-defined ownerships may have the equivalent of a destructor if there is a realistic memory limitation and that its lifetime/scenario is no longer relevant to the application, but it is not a common thing and you still don't have destructors for individual structs, arrays or strings/buffers, because it simply isn't useful to think of the lifetime of each element - only of the batch/arenas. Putting the ownership concern to the individual element is the problem that multiplies all these concerns. Having it be automatic is beside the point, and can be done without destructors. Considering a stack-like arena, one arena will not arbitrarily change between freeing with no-ops, popping the stack-like pointer to reuse memory or also zeroing that memory. It will typically be well-defined behavior for that individual arena and by pushing individual objects to that arena, you also imply that its ownership and lifetime is equal to the behavior of that specific arena.

well put!

I assumed it was a joke I didn't get, until tugbars said 'well put!'. I'm not sure what you mean. The RET assembly instruction has moved the stack pointer since its inception with 8086. Garbage collectors are vastly more complicated than moving a stack pointer.

​@@Muskar2 The idea is to use scratch space as much as possible rather than allocating new memory on the heap or using static arrays. When modeled correctly, dynamic allocation can often be avoided. However, it's important to note that this may not always be possible.

@@Muskar2 Indeed, as tugbars said. More specifically, you can avoid dynamic allocators and use only arenas whenever your program is single core and not concurrent. That is, use two arenas, one for return and another for scratch, and alternate between them as needed.

@@mateusvmv I don't disagree. But what does scratch space has to do with the statement 'garbage collection is moving a stack pointer back up after the function ends'?

This is a dang good point. By forcing you to think about the trouble tiny lifetime focus causes, it really does encourage you to think bigger faster about things like arenas and such. But I still value the idea of rust/raii for stuff like dropping file handles and channel senders and receivers. And rust has really empowered me, someone who learned using higher level languages, to delve into lower level programming-- so I also credit it for that. But I'm not beholden to any language. I'm inspired by Casey's points here

How do you do n+1 style in Rust ?

@@lm-gn8xr Well, in some sense you get some stuff that is "allocated together" by default, by using things like Vec. And for some other stuff where you'd otherwise get a bunch of allocation, you can use an arena allocator crate like bumpalo. And then in certain cases you can simply just optimize your types to store references to things instead of owning them. E.g. MyThing

@@lm-gn8xr With user defined lifetime or / and custom allocators for all the resources that share the same lifetime. What is defined in n+1 is just group thinking and it's not that complex to do in Rust, without having to allocate on the heap each single elements that shares the same lifetime like someone stuck at n. You reserve the space for n resources, and make it last the whole program, the whole frame, etc. You end up with one big allocation, and one big destruction, wasting less CPU time and introducing less failure points than someone allocating things individually.

All you're doing is circumventing the protections that you paid so much to get.

I have been thinking about that for a while, and I still haven't quite decided, I just know that this video was the second most important and influential to my development; even tho I didn't get it at first.

The first might be don't overplan things.

Don’t be an architecture astronaut

​@@mattmurphy7030I'm not sure I understand what this means

@@logicaestrex2278 there’s literally a Wikipedia article

ZII applies to all allocations. What specifically is your concern with long lasting dynamic data in regards to zeroed memory? Typically the issues with long lasting dynamic data is high fragmentation once you approach the memory limits of the target system. But first realize that such concerns often are grown out of unfounded fear that the data will grow beyond your realistic expectations. E.g. having 20 GB of long lasting dynamic memory when you know only a few hundred MB is typically needed for the scenario in question, then a memory arena that lasts the lifetime of the program will typically be fine. Anyway, long-lasting dynamic memory-limited data is what free lists handle. And if you actually determined you need a free list, try to see if you can make the things into fixed size entities (aligned to 64B-factored boundaries for cache line efficiency), which makes fragmentation much more trivial to handle. On a sidenote: Hopefully you know not to use a linkedlist in production unless you're a senior - because they're rarely the best thing to do.

If a failed load returns a 0 count buffer then the parser should by default think it has reached the end of that buffer in the failure case (i.e. cursor < count is false). There's no need for another check. There are a bunch of similar situations where the all-0 case satisfies the end condition.

@@Botondar I see, that makes sense

​@@Botondar yes, but there are a butt load of cases also where this is not satisfied at all. You open a resource that does not exist and you return a zero initialized handle? really? so the caller has no mean to detect a failure and it can write to that resource (and I guess it will silently say it wrote 0 bytes). The cases where everything converge to the "empty case is equal to the final result" are RARE and even in those cases, often mislead the users. For sure it is not something to be taken as a new and better paradigm to program that fits all.

@@neural75 allowing the 0 case to flow through is completely orthogonal to proper error reporting, you could always have additional values that tell you whether there was an error or what it was. The point is to parameterize the code in such a way such that if the caller code doesn't check for an error, it will logically NO-OP.

@@Botondar The point is that zero cases treatment are rare and you end up having a lot of error handling anyhow, there is no magic bullet in programming and the first lesson to learn is really to stay away from slogans and a like.

Virtual memory on 64 bit systems helps a lot when you don't know how much memory is needed for a task, as you can reserve massive ranges without committing it all. But even then there will be outliers, though I don't think most programmers will have to deal with a 128GB+ JSON file. At that point, something has gone terribly wrong.

I don't quite see your reasoning, but you mention "functional programming", are you saying that what Casey is advocating for won't work in a functional paradigm specifically? Or is this a more general claim?

@@xDahl It's a general claim, I believe. Pooling resources does inherently create some cross-system coupling. By default, you're going to want to reduce coupling across your system. However, there are many cases where this coupling more than pays for itself in terms of massive performance advantage. Like everything else, you just need to look at things case-by-case to see if the trade-offs are worth it.

@@bryanedds8922 I will happily admit that I don't understand what you're saying here, and that's not a failure on your end to communicate, it's on my end to comprehend.

I think the idea is kind of like this. Lets say you only page 100 rows at a time. New up the memory for 100 blank row classes at once, don't delete them when you page. Clear them and fill them back up with the new page of info.

Why would your search crash or otherwise fail if it encounters a zeroed out struct? Null pointer dereference sure, but you're not going to make it that far on a row that has zero values or is zero length. It's never going to match the search criteria and should pass right through. Or did you mean as a return value? It's pretty easy to draw/print a result that has 0 rows.

@@justinbasinger7728 Sure, I can see reusing the same rows, dynamically expanding the table, or even just crashing when we run out of space, but it seemed like he was suggesting something else.

@@paulclarke8237 I really think it's that simple. Grab all the memory you need up front and deal with orchestrating that chunk yourself, instead of newing/deleteing for every object. I think the N+2 part is being clever with that management, and only getting what you need, trying to be as efficient as possible with it.

It can work like a sentinel to remove special cases from any loop. The search always succeeds and stays in bounds without bounds checking.

I principally agree that there is often some use-case for all kinds of approaches. But even in those rare exceptions where you can't do anything better than a complicated management of individual objects, it's usually still vital to not take on opaque complexity. Thinking about batches is inherently simpler, and allows you to only think about the actual logic of the program, rather than memory management.

I have some contenders, but I’m still not sure which one was the most influential, it’s been a while after all.

I can't send you links, as youtube appears to delete my own comments, but google "ginger bill memory allocation strategies", Bill has a few articles on different custom allocators that are well written and simple. Code examples are given in C, so it's fairly easy to follow as no advanced language features are used.

@@xDahl ok

performance is not the only benefit from an architecture that bundles all allocations together. he talks extensively about aggregating failure points. rust doesn't get that benefit from the borrow checker.

@@blarghblargh I certainly don't mean to be dismissive of this architecture but I do think I'd need to see it in action to really get it. To me currently the borrow checker really doesn't seem to cause much issues, at least on small scales. I know he mentions thinking about applications at small scales as being the difference between the average programmer and a pro but it does seem like the small approach is valid for small apps. Certainly when making a game the overhead/sys calls for memory greatly increase for thinking about things at a small scale.

What's your point?

Arena's aren't the only custom allocator you can use though, there's plenty of strategies that can be employed.

Casey is friends with Jonathan Blow, and it seems like Casey is more interested in JBlow's language, Jai.

Look into array languages, like APL, J, BQN, UIUA They are explicitly designed for batch computing.

In Julia there's an extra dot you can put in a lot of operations to make them vectorized, even your own functions if written with proper care

HLSL is a language designed to make it impossible to not make something vectorized, but it has its limits. And as far as I understand, languages are slightly limited by the instruction sets by making it more seamless. Tim Sweeney coined the term 'Vector Complete" in an old article about LRBni (Dobb), which essentially proposed standardizing instructions like vgather, vscatter, masking and setting destination registers, thus making it trivial for compilers to turn most work into SIMD, so long as iterations don't depend on each other and the call graph is statically known. Plus it would make it easier to make a high-level CPU language that learned into vectors. AVX introduced gather, but scatter is only supported on AVX-512 (12% of gamers today according to the Steam hardware survey) and is not implemented very efficiently yet. How do you propose a language could encourage SIMD?

I am unfortunately not in control over how many ads are shown, this channel and video aren't even monetized, so it's just youtube being youtube.

At that point, it seems to me you're just abusing that RAII is the easiest thing available in your language. RAII was specifically designed for dealing with individual elements. Anyway, you can accomplish the same ease of use with a 'defer' keyword (which executes at scope exit) or even integrating allocators into the language like Odin and Jai did, such that the only thing you can forget is to write the few lines of freeing logic one (or a few) places in your program. As for multi-threading, I found the ideal thing is to minimize contention (e.g. only contend the interlock line/instruction where the threads are dequeuing jobs). When more contention is introduced, I find debugging swiftly become extremely complicated. Scenarios that require contention by definition are just inherently complex, and I don't have much experience with easy ways to handle such scenarios - albeit the more transparent the easier to debug. But yeah, sounds like n+0.9 ish. n+2 is about taking advantage of what zero means to the CPU, how C can if(struct) to have a uniform data validity check, how all memory is initialized to zero by OS'es by default (for security reasons) [e.g. VirtualAlloc or mmap(MAP_ANONYMOUS)], how you can trivially cast zeroed memory to any size of object without any concern about data corruption or further initialization at the cost of no ASM instructions, and how having an enforced ZII standard in your codebase will make it much less verbose to check for errors and thus a much larger percentage of the code is actually dealing with work, rather than error checking - which makes it easier to refactor, debug and understand.

@@Muskar2 Hmmm.. > At that point, it seems to me you're just abusing that RAII is the easiest thing available in your language. RAII was specifically designed for dealing with individual elements. No. I think it is still good to have language elements that talk about life cycle of things and ownership. When someone fucks the granularity.... well... they would totally suck balls in some language like Zig I think anyways.. > Anyway, you can accomplish the same ease of use with a 'defer' keyword (which executes at scope exit) or even integrating allocators into the language like Odin and Jai did, such that the only thing you can forget is to write the few lines of freeing logic one (or a few) places in your program. No, you cannot do the "same". Because with a well written move semantics you can totally move things out of the scope instead of scope-deleting. You can totally pass around ownership without random extra costs all because of the type system... You can probably say that "you can accomplish the same for measurably many cases" - which is true and useful, but it is sometimes good to pass around the ownership out of local scope. That is with Zig how do you defer in a way to NOT get something deferred to end of scope but to much later? > the only thing you can forget is to write the few lines of freeing logic one (or a few) places in your program. Um... Same can be told about malloc / free too... You can totally just use them naked and "lets not forget it". Also its not just "freeing logic" - but everything that has a life-cycle basically. > Scenarios that require contention by definition are just inherently complex, and I don't have much experience with easy ways to handle such scenarios - albeit the more transparent the easier to debug. Real performant multiprocessing just.... sucks... that's it. There is not really so much magic way around it... There are ways to do it somewhat better (and I spent considerable time doing very inhereintly parallel train control an similar system that are event-based) but I too prefer the approach for single thread -> instruction level parallelism / cache optimized -> either simd or threads approach.... it is surprising how fast a single thread can be when well written and we are not alone on the CPU.... > But yeah, sounds like n+0.9 ish. n+2 is about taking advantage of what zero means to the CPU Yeah n+2 sounds like a very interesting low level coding idea. I did not play around enough with that to say if its really that HUGE or not because you often already "misuse" (use) this property in "normal" code too. But yeah I see validity to study in that direction for sure....

For strings its useful to use a string builder pattern to avoid unnecessary allocations. For large things such as "vectors" (bad C++ name, they are really arrays) no one is telling you to not use malloc for that when needed. What casey is speaking against is small allocations (individual structs and pieces of data structures) that could have easily been grouped into a single lifetime (the lifetime of the data structure or some program specific lifetime like a frame). You don't need to know the size of a data structure beforehand to group allocations, you allocate a pool of memory of a sufficiently large size and then you assign the memory using an allocation strategy, most often a bump allocator. Wether you agree with this or not, it is an objective fact that this leads to code that is orders of magnitude faster in normal computers than RAII. I have no idea about embedded systems though.

@@marcossidoruk8033 Yes a string builder (or std::stringstream in C++'s case) is a fine tool to use. It solves that particular problem rather well. And I also think you should absolutely always use a std::vector over manual malloc calls, solely to ensure you don't leak the memory. A bucket/pool does the same trick and I'm familiar with the pattern and I'm not opposed to it at all. My point is that is solves an issue which can be avoided quite easily. The "small allocations (individual structs and pieces of data structures)" mostly don't need to be on the heap to begin with. Containers that have a runtime determined (or even dynamic) size, yes, that's why we got vector, map and so on. But what else must go on the heap? If its size is known at compile time there's no benefit from putting on the heap aside from certain cases (like the multi threading one I mentioned). I think in a lot of ways, the "buckets" or "pools" or whatever you want to call them, do exist in the code I write, but they're just the containers. I see absolutely no reason for any ol' object (like an entity in your game) to go on the heap *on its own*.

@@bruderdasisteinschwerermangel If I'm understanding you right, what you're saying is that data of known size and life-time should be put on the call stack whenever possible? (or the global area if appropriate)

@@LinucNerd Yeah. And in the case where you might have multiple instances of something, you're probably gonna put them into a container of some sort. It's similar to the bucket/pool allocation to be fair. One other case where this might not work is if you work with inheritance/interfaces. Let's say component A gets a component that implements X and acts as the owner of that object. In that case you need to pass a pointer or reference. I'd probably use unique_ptr (that way A has full ownership of X) or make A non-movable and take the value by raw ptr or reference (but you have to ensure the life times align).

There isn't really an easy way to deal with this sort of situation, so I don't know what's the right thing to do. If you're in a team where people have wildly different ways of programming, at best what you can do is share your concerns and ideas with the team; but there's no guarantee that people will be convinced. Even in this comment section, I've had to delete comments from users who are so opposed to any criticisms or alternatives to smart-pointers and RAII, that they immediately went to name-calling and slander; ignoring every argument given by me and others. So the only advice I can give is try to reason with people who are willing to listen, and always be open to the idea that you could be wrong. To some degree you can have subsystems that uses custom allocators and grouped-element-thinking that interacts with N style code, but not always; but I'm not sure if it's a good idea to do that or just accept the N style of programming for the project to keep the codebase consistent.

Yeah, I also struggled to get what he was on about when I first saw this clip, Casey takes a lot of stuff for granted, but try to look into Arena/Bump-Allocators and then Pool-Allocators, generally any custom allocators would do, but these two are simplest and easiest to understand.

@@xDahl thanks for the hint. I'll check it out

@@kanecassidy9126 I think youtube deleted my own comment... So I can't send you a link, but google "ginger bill memory allocation strategies". I had forgotten to mention that earlier, I think it will come in handy as Bill gives code examples in C.

​@@kanecassidy9126 Silly me, Casey does give an example of turning N code into N+1 in this video at 18:45, although he doesn't show any code examples. In short, instead of individually allocating every piece of memory that a character needed (like, bones, animations, meshes, maybe textures? etc), he instead wrote a helper function that calculated how much memory he needed for the whole character and its data, and then did one large allocation for the whole thing. And after that, the helper function would set the pointers to reference other parts within the same allocation block. That way, he'd only have to do one allocation rather than 7 allocations, and his error code only had to check if he got the whole block (that can contain everything for that character), rather than checking every single allocation if it failed and handling it.

@@xDahl yeah I noticed that part but code example would be nicer. The issue is it's not that easy to turn any individual memory allocation into a batch in practice if there are many independent "moving parts".

I'd just give Zig a try, give yourself a few weeks to play with it and see how you like it. I'd also consider other languages like Jai or Odin.

@@xDahl add c3 to the list ;)

What is a generic string? What's the use case and life cycle in the program? More over, what is the program's lifetime? I'll get to that last one in a bit. Smart pointers are a tool that are fit for a specific purpose, but that doesn't mean they should be used everywhere, and that's unfortunately what a lot of people do. In _most_ cases you can group lifetimes together, and at the same time in many cases, avoid a lot of error handling. You should use specific and well crafted tools to solve for the problems you have, not use generic solutions that "fit everything", because those will not perform well, and will give you other concerns & problems. You can use smart pointers in cases where you _truly_ have arbitrary life times and references, and Casey would probably be fine with that! As for the "program lifetime". I wrote a program a few weeks ago, and I simply used an arena that grows for handling strings. It had an upper bound of 1GB, but it didn't allocate 1GB of memory, just reserves it and grows when needed (Virtual memory is nice). I think it in practice used less than 1MB? Not too sure. And when a reference got stale, it was simply "leaked"; and that's fine! Fact of the matter was that this program would only ever leak a few times with small strings, and it would only run for at _most_ 5 hours. There just wasn't a good reason to care about less than a few pages of memory for a program that isn't perpetually running. Just to clarify (because I've seen people misunderstand this point), I'm not saying you should leak memory willynilly, leaks are bad _in most cases_, but there are times where it's ok to do so. For the record: This is a rare thing for me to do, as in all other cases I've had I don't leak things, I just handle it, and it's easy to do with custom allocators.

​@@xDahl so, your solution is to replace malloc with your own fixed-size bump allocator? Or a set of such bump allocators? Idk, coupling coherent things into separated entities is the way to go, but replacing allocators is not something I'd use for generic cases. I'am interested in this because I dabble in prog language design, something C-like, but with nice features, like OOP syntactic sugar, generics and constexpr-like compile-time evaluation. I believe RAII's goal is noble, but the implementation is somewhat lacking. What mechanisms for memory management would you recommend for the general case? Some one size fits all tool like RAII or some set of tools? Letting it sort itself, like in C, proved it to be a disaster

​​@@Raspredval1337yes. this way of allocation applies to all things. and syringe having incoherent lifetimes is entirely problem with the way the programmer writes the code. it is very easy to change the lifetime of an object. "C's problem" is not actually a problem with C itself but a lack of usable libraries to back out that don't encourage slow and bug prone operations. Which C++ mostly fixed. Why I say that is because strings are null terminated. strings have no predetermined size. every allocation is a syscall. no built in bounds checking, no null pointer check, constantly relying on allocations from the system to not fail or pagefault you. No dynamic array library. no allocator. All of these things make C code horrible for safety and performance and stability because the default state is the bad one...

I think that's kind of the point of the whole thing. Yes, the lifetime of a single piece of memory can be incoherent when looked at in isolation, but usually it is constrained to a larger context. Is it really going to matter that I free the piece of memory as soon as it isn't needed any more (which is how RAII/manually inserting frees all over the place deals with it), or is it maybe sufficient to free it once I've left that larger context? And if I do need to hold onto that value, I can always copy it out before I free the allocation. That can end up being faster than dealing with the general purpose system allocator that needs to deal with synchronization, fragmentation, etc. And sure, if you end up finding that your objects are **so** dynamic, that they somehow make round trips through your entire program, then you can always fall back on some other resource management scheme. But that doesn't have to be the default.

@JaconSamsta That was so well articulated, I wish I could pin and double heart your comment.

They're different categories of concepts because ZII is n+2 and RAII is n.

@@cunning_weasel No, they are in a different category of concepts because they solve different problems entirely. It's not even apples and oranges it's apples and sounds

@@julkiewicz exactly. n+2 vs n.

99% of the time it's just used for allocation tho. So the ciriticism is still valid most of the time.

Right? I need more information because it seems like someone asked the question "okay so what happens when you don't have enough memory" and the solution was, if I understand correctly, to just go "la la la" and write to null and hope the stuff you needed didn't matter.

Maybe I'm getting your situation wrong, but a suggestion. If you're memory constraint, then you know how much memory you can allocate for the big tree structure at maximum. If that is the case, then you can just allocate that memory, that is reserved in the design anyway, as a heap of tree nodes. Then you can take nodes from there at will and if you no longer need them you can create an other tree of freed nodes. When you run out of nodes at the end of the heap, you start to consume nodes from the free-tree. This is all based on a design time maximum of simultaneously used tree nodes. The pattern of keeping a free-list of nodes has a name, but I don't know that right now.

That's boomer advice. The average developer doesn't even know enough optimization to do a premature one. The root of all evil nowadays is people writing code they don't need to solve problems they don't have.

@@Vitorruy1 very true.

but what if you have week references? Now, the computer has to spend time in each scope block to go thru every weak ref and check, is it okay to delete, ooops, no it's not, let's continue. Or to check if somebody has moved the resource from the object, to avoid double free. Plus, every time you want to make your own complex abstraction you'd need to satisfy the Rule of 5 (move\copy constructor, move\copy assign, destructor). And you can't just copypaste code from move\copy constructors into move\copy assign operations, what if the end user is _very special_ and selfassigns your objects? Next, think about errors in constructors, the only way to report an error is to throw from the constructor. Or to have valid and invalid states of the object, baked into the object definition. Now, for every method invocation of that could be invalid object you'd have to check if it's valid or not. Or assume it's always valid and have a ticking bomb in your code, waiting to segfault at runtime. You'd need to think about all that. RAII might be good for the end user, who doesn't have to write that code. But it's terrible for people who have to actually write and maintain that. Plus, why do you need to have an array of file handles, all in one scope, waiting to be deleted? If their lifetime is coherent, tie them into a collection and destroy that collection once. It takes like 15 seconds to write effectively a destructor with a for loop for that collection. And, unless you gonna need like 1000 collections of files, completely incoherent from one another, managing lifetimes of those collections would be trivial.

Or write a function Zoomer.

@@Raspredval1337 Naturally, don't use weak references where an owning reference suffices. Most RAII implementations don't even have weak references. Throwing from a constructor is a valid concern for languages that want to avoid exceptions. However, returning Optional from a constructor is a perfectly valid solution. It's also perfectly valid to disallow uninitialized RAII objects altogether and instead use Optional again for cases when you can't initialize them on construction. Modern languages are really good at handling optionals with pattern matching. File descriptors is just the most basic example of a managed resource. If you don't like it, think of textures, sockets, threads, etc.

@@Alexander_Sannikov I do not say automatic resource management is bad, I said, RAII itself is badly designed and in return promotes bad design

@@Raspredval1337 I think that the reason why C++ RAII is badly designed is largely because optionals didn't exist when the concept was created, and even today C++ does not have modern tools to unwrap optionals ergonomically. That being said, imo even bad C++ RAII is still better than zig's no RAII at all, when it comes to managing resources.

I am not sure how you make an off-by-one error with pools, elaborate? With a pool allocator, you return a pointer to a struct within your pool, so you reference each struct via a pointer, you're not dealing with an array directly.

@@xDahl Hey! Well, you can write a push_array function that would return an array of structs allocated in the pool. That's what I mean, in that case, if you either read or write past the array you will corrupt memory from other things, then the app will behave unexpectedly.

@@xDahl I suppose we're thinking of different kinds of pools. I believe Casey talks about a "generic" memory pool, where you can allocate all kinds of objects. Maybe I'm wrong, but I think you seem to be thinking of a "specific" pool of objects, e.g. a pool of entities only. I was referring to the former, where you can have, in the same pool, different kinds of objects allocated sequentially.

Ok I see what you mean, but I'm not entirely convinced about this being a valid issue/concern. See, when you allocate an array of entities, you have to request the size/amount of entities, so you already know how big the array is going to be; given that you know the size, you can just do bounds-checking. And if your language allows for it, you can just use a slice and the bounds-checking is automatic during runtime and compile time. Odin has this, and you can even disable run-time bounds-checking on release builds if you so choose. So I find this concern to be kind of odd. If you don't have access to slices, you could do it manually or see if it's possible to do some tricks on the matter. If I remember correctly, GingerBill wrote a header library for C that gave him slices, tho I am not familiar with it and haven't checked on it. That said, there _might_ be a trick you could use with virtual memory to catch these issues. See, given that memory is divided into pages, you could just bump the Arena until the next page minus the size of the allocation, and return that address, but before the return, mark the next memory page as unwritable; Now, if you get an off-by-one and start accessing the next page, you'll segfault, and you can catch that in a debugger. I wouldn't recommend this, I'm not entirely sure it would even work, as I've never done it. But it could potentially work for debug builds.

​@@xDahl I can agree this isn't a huge issue. I was just pointing out I had problems with this before. The actual point I was trying to make is that we already have the ability to bypass this issue by allocating things on the heap and using address sanitizer (in C that is). So my point is that we lose this ability when using the arenas. My idea atm is to write all the code using malloc/free during development, and once it's all settled down I can replace it all with memory arenas. But it's true that we can either write checks manually or write our own containers with auto checking, then with discipline we can avoid this issue by never accessing memory manually. Idk, I guess I just dislike the fact that we lose the ability to use address sanitizer.

No luck needed, a lot of teams already do this

It's the same. This could be applied to all kind of allocatable resources.

It doesn't apply at all. They aren't even the same category of things. How would "zero initialization" help with a typical use case of say file handle management. They only relate in that they both have "initialization" in the name.

@@julkiewicz To be a bit more fair, zero initialization was a marginal part of the video. Now here is the thing: this video seems over-concerned with memory and memory only, and even that only in a PC environment. These principles are perfectly applicable with GC as well - allocate a lot and then reuse it and basically never even run the GC at all - where memory is clearly a solved problem. RAII on the other hand never claimed to be only about memory (perhaps that's why it's not called MAII) and in general these other resources (a file handle, a database connection, whatever) are the more open-ended problem and I would naively think that indeed you still have to do basically the opposite for all that stuff.

@@julkiewicz Handling non-memory resources with an arena allocator works just as well as memory resources. You can put file handles into an arena. It just that it would lack certain benefits that memory resources uniquely has, namely having to loop through it to close the handles, but the principle is the same.

@@rndszrvaltas The reason there is so much focus on memory is because absolutely everything you do with a computer revolves around memory. Yes, this is applicable when using a GC too, but it can be surprisingly complicated and sometimes the GC can be surprisingly antagonistic to what you're trying to do. Yes, RAII is about all kinds of resources. Nobody has claimed it's for memory only. Howevery, since memory is such a big deal compared to other resoruces, it warrants finding custom solutions to the memory case of the problem, since custom solutions are usually easier to find and more efficient than general-purpose solutions.

Not quite but close, it's about realizing that individual-element-thinking and individual-element-allocation is a poor way of architecting a program. If you have a bunch of elements that in a wider context share the same life-time, then they should be grouped into the same allocation in an allocator. This is achieved by using custom allocators that fetch a big block of memory and then serve out pieces of memory for that particular context. Doing so removes a lot of error-handling, it removes a lot of bugs, it makes the program more secure, it makes the program faster, and makes the code easier to understand. When you pass around an allocator, you're also explicitly saying something about the elements & data you're working with, you're in a way encoding their life-time and relatedness as a value in code, and you're saying something about their intended usage. No amount of comments can do that, as comments can become out-of-date with what your code actually does, and comments can just be wrong by saying what you meant, not what you did.

@@xDahl ok, so Arena is not the only solution. It could be Arenas, custom allocators or startup-allocation/no-run-time-allocation for mission critical embedded applications. Right?

Correct, Arena's are not the only way, any custom allocator or allocation strategy that is well-fitted to your code would do. It doesn't just apply for mission critical code or embedded applications, you can use these ideas where applicable.

Looks like neovim, but could also be emacs

4coder but it really doesn't matter

it’s 4code, which is kinda like microemacs

Like @salim444 says, it really doesn't matter.

4coder is similar to microemacs?

No, It seems like it's pretty much dead. No new updates and he doesn't seem to talk about it at all...

afaik, he just got busy with other things. Though he also says that he isn't good at game design, gameplay that is, so once you get past some stage of the development cycle, things get less interesting.

@@xDahl The whole point of the handmade hero project was to create a "complete game, from scratch" within roughy 2 years. It didn't need to be some super interesting grand game and he didin't need to be that good at game design like a Jonnathan blow or something. It was specifically about the programming steps to making a game, and It should have stayed that way. But somewhere along the lines he started doing too much such as adding 3d sprites and doing more complex things with the world, and it seemed to overwhelm him? If he just kept it simple it probably would have been done by now...

in a sense he did finish it, but then started adding 3d and lighting to the engine after that and no longer has time for it.

@@jupiterapollo4985 These guys who spend a lot of time talking about their ideas don't seem to finish their games promptly.

In ZII you make the zero value useful and the default. It's not "undefined" to get or use a zero value, it's expected and the default behavior because you defined zero to be usable.

​@xDahl that is still not correct behavior in all cases. I agree with the OP. Crash is often better than "just works" because just works might not be correct and can make things a debugging hell. Null stubs have their place but calling them higher order thinking I'd ridiculous and they're not a better form of RAII, they are a totally different concept. And I still don't understand why ges talking about RAII in the context of allocations. Raii is about resource management, not about memory allocations. Yes sometimes memory can be thr resource, but most times it's something else, like a database connection or file handle or drawing context or whatever. None of this made any sense. Yes having a h8ghef level view of data and lifetime is useful. But that has nothing to do with error handling or RAII those are dll complete separate problems.

@LeutnantJoker I was talking about ZII, meaning you make the default/initial value zero, and having that be either useful or not an error. I don't see the connection you're making with ZII vs crashing early. These aren't mutually exclusive. Edit: I think I see the confusion, so let me clear that up. In ZII, you make the zero value useful / nor an error, an example of this would be that variables are always initialized to zero, and you write your code in such a way that zero is expected and the default. (Yes you can have some cases where you need to initialize a variable to something other than zero, bla bla bla, you can always have exceptions, the idea behind ZII is to _try_ to make zero the default, not that is _always has to_) Or say you have a struct with a bunch of variables, if you write your code in such a way that zero is the initial value and that's expected, then you don't have to do any initialization code, because the OS already zeros out memory for you when you request memory. Yes I'm aware that Malloc doesn't necessarily zero out memory before reusing old chunks, but you should be using custom allocators anyway. In practice, zeroing out memory is practically free, the OS already does it before serving out memory to you for security reasons. Only place you have to do so yourself manually is in your custom allocator, when reusing old memory. So what about crashing early? This seems to have caused some confusion. So lets say you have a procedure that returns a pointer to a struct. In ZII, all of the bytes within the struct will be zero, as to keep all variables zero when initialized. And since your code expects and treats zero correctly, there's no issue, cost or problems. But lets say you cannot allocate a struct from your custom allocator - you can still crash from this if you so please. See, there's nothing contradictory with ZII and crashing early, you can do both. If not being able to get a struct is an unrecoverable state in your program, then sure, crash... But you can still treat zero as the initialization value... AKA, ZII: Zero Is Initialization. I hope this helps clearing up the confusion.

@@xDahl I know what Zii is, thank you. My point stands

@@LeutnantJoker Well, so does mine. We were talking about ZII and crashing early, and as I stated, they're not mutually exclusive. Am I to assume the issue you're having is not with ZII itself but with stubs?

That's the first level. The more accurate annalogy would be using a monotonic buffer resource for all vectors with shared lifetime (for example parsing stage, json document, render pass, or game tick)

use array when possible, and use compile time initialization when possible

Not a good analogy. Vectors are usually still small (and many) parts in your program, if you have multiple vectors then you have to worry about freeing all of them and you are right back to stage N. Preferably you want to have your vector make use of a custom allocator such as a pool. But to make vectors use a custom allocator you have to write a bunch of bothersome template shenanigans. I tend to write my own dynamic array classes (strike that, structs) that work better with my own allocators, it's really not that hard, and it's nice to not need stdlib in your projects because the whole thing is written in the stage N mindset.

@@saniancreations That's why I use Zig, in Zig custom allocators are first class citizens, every data structures in the std expect an allocator, and they usually provide a Managed/Unmanaged variant in case you don't want your data structure to hold a useless reference to your allocator, they also provide a lot of different allocators and making them is quite easy. The neat thing is that because they have so many allocators, you can swap them based on the situation, for example during compilation if I'm in a debug build I'll use comptime to see if I'm in a debug build and instead of an arena or an heap allocator, I will pass a debug allocator, to prevent double free, use after free, and memory leaks with the General Purpose allocator, but when I compile in Release I use comptime to switch to a more suitable allocator.

He is writing c++

You can lose track of memory allocated from a block depending on your custom allocator, so it's not a given. And losing track of a piece of memory in a block can be fine depending on the circumstances. It really is a shame that Casey can talk about how these things _don't_ _just_ improve performance, but increases security, code readability and maintainability, generally simplifies the program, makes bugs less likely and can remove entire classes of bugs and error-handling - and a lot of people just go "games programming is different, this doesn't apply to _anything_ outside of games, and performance isn't everything". Also "drop as much as possible to gain a few cycles"; he just doesn't use unnecessary tools, unnecessarily large libraries and inappropriate methods to get a job done. You can do this in any field of programming, not introducing unneeded complexity is a good thing.

@@xDahl I agree that keeping things minimal in general is a very good thing, and I do this myself, but so much of what Casey says is simply his opinion or relevant to his situation. Try to tell a bank not to use smart pointers, and see what happens to their software quality. Listening to Casey is a lot like listening to Jonathan Blow, both very intelligent, and both make a lot of unconventional decision, which happen to work _in their situation_, and then preach as if it is always applicable, which it is not. It is pointless to discuss these kinds of things in KZfaq comments, this isn't the right place.

@@xDahl By the way, I debugged a common out of memory problem we were having in a major software renderer used by Hollywood in movies like Matrix 2 & 3, Constantine, Cat Woman, etc., and discovered that we had plenty of available memory, but it was all horribly fragmented. I instituted a flushing BSP, wrote the reader-writer locks for Windows, Linux and Irix, and added a block allocation memory subsystem, and after that, we could render much larger scenes again, with almost no thrashing, so I am very familiar with the kinds of technologies that Casey talks about, but he just talks as if his arguments are always valid, but in fact every system and every situation has different constraints, and game programming is off on the far edge of what is needed, as is computer graphics in general. There are many kinds of systems where totally different solutions are needed. Think space, medical devices, distributed systems, international banks, military, and so on. All have completely different constraints than the one-guy game programming studio.

"but so much of what Casey says is simply his opinion or relevant to his situation [..] and both make a lot of unconventional decision, which happen to work _in their situation_"... It's a shame that the points I brought up in my initial reply has been entirely ignored, in favor of still going "games programming is different, this doesn't apply anywhere else". Also, "... happen to work in their situation...", happen to work? What are you on about? None of what's being said here is limited to only his situation, this isn't just a game dev thing, people have been doing these things for decades outside of games. Look, when you pass around an allocator, you're also explicitly saying something about the data you're working with, you're encoding their lifetime and relatedness as a value in code, and you're saying something about their intended usage. "Happens to work"? This isn't some random system they came up with that happens to work, this is an extremely valuable tool that's been around for decades that replaces the need for smart-pointers in a lot of cases. Does that mean all? No, but that was never the argument. If you truly have some data with an undetermined life-time where the relatedness of things is hard to pin down, yeah you can use smart-pointers, but that is a specific case, and even there you don't have to. Generalized tools like smart-pointers bring with them a lot assumptions and problems that could in _many_ cases be avoided if you just structured things differently. You should use the tools that are appropriate for the task, instead a lot of people just slap smart-pointers over a poorly architecture program and call it a day, that's what Casey is arguing against.

@@xDahl I am not arguing for slapping smart pointers in places they don't belong, but Casey, Jon and others often talk as if what they say is universally relevant, sometimes quite explicitly so, and it just gets my goat. "You should use the tools that are appropriate for the task" - fully agree, let's leave it at that.

You can try to use fixed-size strings instead (much like a database would) or have a collection of all strings that is more centralized and then use ids to reference them instead.

What about them?

@@julkiewicz It's unclear to me what you mean by "a fixed size string". Do you mean, string_view (in C++) and str (in Rust, which size must be known at compile time) or do you mean constants? This isn't _always_ possible, due to the lifetime issues and a general use-case of that string. For instance, in Rust, you must allocate memory for string literals, if the string size isn't known at compile time, same goes with C++. "A collection of all strings", sorry, but this is a terrible idea. It might be useful for trivial programs, but when something complex as (for example Chromium), it's just not possible to centralize everything or portions of everything. HashMap (if we not create a custom data structure) is close to what you've explained, but in a meaningful way, they can't be centralized. Also, a lot of std functions, returns a string or a collection of string (usually in a vector). For that, you can't do much, because you still have to use those anyway, so you can't just abandon the idea of allocating each smart pointers individually. A better solution might be creating a string pool, storing everything in there, and accessing them as we go along, but this idea is complex already, which requires doing some possible hacks with smart pointer and not worthwhile for trivial programs.

Just use smallstring-style container. Stack allocated, but if it goes above max size, it goes to heap. Of course you can substitute heap with an allocator.

@@sofiaknyazeva How would the size of a string literal _not_ be known at compile time? This makes zero sense. There are _zero_ cases where a string _must_ be dynamically allocated; people just do it because it's what's taught and in some cases easier to reason about. But it's absolutely not necessary.

The stack is effectively the same thing as the simplest linear allocator, but with some limitations. You can implement your own stack allocator in very few lines of code, but it sounds to me like you're almost at n+1. You only need to realize that the stack and heap are abstractions that are rarely useful. They all use the same memory. The stack is effectively pre-allocated memory for your application that you're pushing and popping data to and from. A simple allocator works basically 1:1 with that and instead of writing my_struct Data = {}; you write my_struct Data = PushStruct(Arena, my_struct); where PushStruct is a macro: #define PushStruct(Arena, type) (type *)PushSize(Arena, sizeof(type)) and PushSize is a function: static void *PushSize(memory_arena *Arena, u64 Size) As for your last point, it seems like the missing realization of n+1 is that delaying allocation and freeing of individual objects to the exact moment that they need to be used/discarded is extremely complicated and wasteful. It is much simpler to simply allocate a large allocation at once, and grow that memory if necessary, and then dispose of it all once that entire lifecycle is done. Having concerns about whether individual elements are no longer needed (or not needed until a few lines later) is unnecessary busywork, and you might also need to change the order of those mallocs/frees a lot when refactoring or adapting to new functionality, which again is unnecessary busywork.

Fair if you don't like him. Keep in mind that this is an excerpt from a stream of his, you can check out his videos on his channel where he presents himself a fair bit differently. But whatever floats your boat :)

Correct me if I'm wrong, but memory from the OS is indeed zeroed-out by default. Linux, FreeBSD, Mac and Windows does this for security reasons. However Malloc (the allocator) doesn't necessarily do it before reusing old memory that it fetched from the OS, but that's not the OS fault, the OS gave malloc zeroed-out memory.

@@xDahl when malloc used mmap it will get zeroed out pages from the OS, but for small allocations it uses sbrk and arenas which just refuses the same memory region without zeroing it out

Oh I see what's meant here. See, malloc is a general purpose allocator from the standard C library, but malloc isn't the OS, so you cannot depend on malloc always giving you zero'ed out memory, but what Casey is advocating for is using custom allocators instead of malloc. When your custom allocator asks for new memory, it is zero'ed out by the OS and you don't have to do anything, and any time you need to reuse old parts, your custom allocator just zeros it out first. The cost of doing so is negligible considering the OS already does it for fresh memory. Unless you have truly unknown lifetimes and relations between allocations, you should be using custom allocators instead of malloc, thus you can rely no memory being zero when allocated. Malloc being a generalized allocator means it has to be _very_ inflexible in the assumptions it makes, thus it is also a poor fit for a lot of situations.

I think that way that Casey uses and garbage collection differs is that garbage collectors usually need to perform some form of checks when freeing memory, but you don't need any checks when clearing an arena and can just do it at the end of it's lifetime.

No. Here's the differences: With garbage collection you don't think about allocating and freeing memory, and it lets you think of everything in your program as small individual objects. But a garbage collector does some non-trivial analysis on your program to keep track of when you are no longer using each individual object, which is slow. Without garbage collection you DO have to think about allocating and freeing, so if you continue to think of everything as small objects, you now have to perform the job of the garbage collector, making sure each individual object is freed when it is no longer used. This is faster than letting a separate system do it because you have better knowledge of the structure of your program, but so many objects are hard to keep track of, so it's easy to make mistakes, and it is also still not optimal. What Casey is suggesting is this: You still think about memory allocation, it is not automatic, but you think of it in large blocks and model them after the tasks your program has to perform. Not local teaspoons, large chunks. This allows you to 1) not worry about managing every tiny object, and 2) make the memory management of your program much much faster. It is basically preferable to the above in every sense.

@@saniancreations perfectly said

Building on @saniancreations great reply, it is like allocating memory for the entire tea party once, and then you can just do whatever at the party, including changing it up midway, and once the party is over, you just have one line that frees the entire party, instead of having to manage all the elements. And if you have a party every weekend, then you don't even truly free it to the OS, you simply zero all the data in that party/pool once every party is over, and reuse it. And for smaller short-lived things, you can simple use a linear allocator where you simply keep pushing new things on it when you need something, and then every once in a while, you erase everything on it. E.g. once per frame, or a similar predictable end of a main loop iteration. It makes it about as easy to work with as a GC'ed language is, without paying the costs of GC.

I don't think that was his uncertainty, more that he isn't sure if it's possible to skip the N+0 stage all together and instead jump straight to N+1. The N+0 stage is after-all such a basic way of thinking, an comes very natural to everything that preceded it.

mvc doesn't have anything to do with this?

@@paulclarke8237 separating data model from the logic is exactly what he is describing there, except he uses the analogy of grouped vs ungrouped data, which might but not has to always be the most efficient data model

@@angrymurloc7626 MVC doesn't necessarily imply you allocate/deallocate in larger collections all at once, your model can just be an OOP class hierarchy with lots of small heap allocated objects that get created/destroyed gradually as described by Casey.

@@frydac and if that is a sensible data model for your program then the bug frequency is gonna be low ( even though I don't believe in OOP in general, and a data model having method inheritance baked into it is really silly since you're never supposed to use it)

What Casey is advocating for is a lot easier than the stuff you do at stage N, custom allocators don't just give you a performance boost, it greatly simplifies your code, removes a lot or error-handling, makes your code less buggy, makes your code more secure etc. Grouping elements together means you have less mental overhead, and passing custom allocators around tells you a lot about how the data is going to be used and its lifetime, you're encoding intent, lifetime and relatedness as a value in code; that is greatly beneficial. People don't just do this for "performance", there's a lot of benefits to structuring your code this way.

Wow, I'm telling your mom!

@@xDahl She's been dead for a long time, so I'm not sure that's going to yield the response you'd hoped for. However, if she had still been around though, she probably would have chastised me for my choice of language. However, I've found in my 35+yrs of coding, people that use terms like RAII, SFINAE and others, usually write pretty shit code. Now you may very well be an exception to the rule, but I doubt it.

@@thewelder3538 1) The guy in the video is Casey Muratori. @xDahl just clipped one of his videos. 2) Did you even watch the video? Casey is literally arguing against RAII.

@@BestGameDesigner I've really got no idea what he was actually trying to communicate in the word salad anyway. To be fair, I've not heard of him and I've been coding games at a well known software house for like the last 15yrs. Moreover, if the video was clipped from John Carmack or Peter Molyneux, I'd still have the same opinion. I know what RAII is, do I care about it? No. Never even crosses my mind. About the only discernable meaning I got from watching this was it's a good idea to allocate and prepare as many resources as possible in one hit to remove as many possible error conditions you have to check for. To be fair, I'd have thought any coder worth their salt would be doing this anyway. However, the reality is that it's not always practicable to do, as then you end up passing around a load of stuff. Anyway, it's just my opinion on what I sat through.

So what are you agnry at? I don't get it.