Hot, damn. This was so helpful and it got recommended to me at just the right time. Absolutely amazing introduction. I would definitely love some more talks like these about fundamentals of systems programming and how they are done in zig
this should be in the documentation..as someone coming from gc language, i dont understand allocator at all..i do understand about pointer and stuff, but nothing about allocator
Amazing talk! I've seen it like 5 times already in the span of around a year, and always come back when dealing with memory to find out I slowly understand more.
The arena allocator is what the go developers are trying to do now, the zig has made it very simple to control the allocaations but in go it requires wrapping the make function.
awesome and amazing presentation. its fun to watch and I learn a lot from this presentation. zig seems to be more interesting to me now. but so far I only program in c#, python & go (c&c++ for long long time ago). Not sure about how zig will be easy to program or not. but I really wanted to try a language without gc.
24:27 I thought cache pressure would be subsumed under memory fragmentation as a problem. Is there some other consequence of fragmentation that I'm missing?
What is the bug/s in alloca() that keep it from being implemented in Zig? Dynamic allocation on the stack is incredibly useful and it's accepted by most compilers now.
@@VojtaJavora replying quite a bit late, but consider for example C code like this: for (size_t i = argc; i --> 0;) { size_t len = strlen (argv [i]); char *buff = alloca (len); /* snip */ } this has two major problems: - the memory is allocated every iteration, and only freed on function exit, meaning memory usage is linear in argc, where a VLA or malloc/free would have memory usage constant in argc - whereas malloc returns NULL on allocation failure, with alloca (and VLAs too) the behaviour is undefined (and the stack is usually much smaller than the heap) of course that can be largely mitigated with better API design, providing realloca and checking for stack overflow (that would be very hard if you use a form of shadow stack, green thread or whatever though)
i like the i think quake style bump allocator. has 2 stacks that grow towards the center and allows setting marks to free to mark. it's not expandable, but you typically know how much memory you want in an arena allocator. what meta-data would you be concerned with in a slab allocator?
First that comes to mind is which blocks are free/taken. You could use single bits and flip it from 0 to 1 to tag block as "in use". The smaller blocks you have and more, the more metadata (bytes) you need to store which one are used and free. Because you know size of each block in slab, you just check for first zero position in metadata and multply that by size to find a pointer in memory. It's really fast, and each byte can store information about 8 blocks in slab.
@@wiktorwektor123 this would be the ideal method. it would be pretty quick finding the first empty block just by comparing 64 bits (or more) at a time to zero.
@@androth1502 You can also store number of free blocks in slab, if slab have a lot of small blocks or just for every slab. You can use it to tell allocator to reserve next slab if you have none of free left or some number free left or by percentage free left. It would be useful then to reserve new slab full of free blocks and have it just in case, because it's slow operation and if this is game then allocating memory in the middle of frame for paricles isn't good idea.
But if someone is really okey with using malloc/free allocator for everything? It is kinda ugly to pass one single allocator all around. Maybe for situations like this we could have a module level constant or something, so we could set the allocator ones and compiler will pass it around for us?
You can define a constant like that in your own code, no problem. You'll still have to pass it into the standard library constructs yourself though. Having special support for that in the compiler isn't necessary, as you can just write some shims around the standard library that do that for you (or someone could write a Zig package on top of the standard library that does so). The compiler itself doesn't know about allocators at all.
Are you *really* okay with using malloc? Are you always checking to ensure that malloc successfully allocated memory? Are you always handling its failure case? Are you also architecturally guaranteeing that your code not only lacks dangling pointers now, but also will never experience a regression from largely unrelated code that retroactively creates dangling pointers? If your code cannot be formally proven to be memory safe, it probably isn't.
Why does people always lay abstractions on already existing abstractions then give it a name and called it the new nuances? There is only one way to allocate memory on the heap and it's by asking the OS plus even the the OS doesn't give you direct access it's a virtual memory No program I said it again no program has direct memory access that is why the OS is the manager and all you get is a virtual memory which will then be translate to actual memory/variable during compilation and linking. This is why cross compiler exist and this is why platform compiled program can only run on the architecture and OS that it's compiled on. The problem is not C the problem is the safety and resource management which is why we need OS in the first place and to make it harder ISA is different per architecture ARM is different from intel and so on. I'm very sure everyone bashing C would do the same if there is no way routine provided to allocate memory on the heap. Please if you're among the basher just stick to writing software with higher level language and not high level language like C. No programming language is perfect this is why no software or application will be perfect , in fact nothing in life is perfect not human being nor animal, nor infrastructure, nor any natural phenomenon but the imperfection is what makes a lot unique it's the imperfection that differentiate lot of things in our universe without that we all going to look the same. There is a reason why the OS manage the resources , especially "Memory" This is done so that memory is protected from other process and also from hackers if you run a program 5 times you going to get different memory location for the data and codes this can be check with xdump and running your program in debug mode, every process has an illusion of having infinite memory and being the only process running at any given time. So then my question is what do you do differently if there's only one source of truth to allocate memory meaning you are still doing the same thing any programmer would have done. This is what python done, this is what javascript done and ......... The difference with higher level languages is GC(garbage collector) so that you don't have to worry about freeing the memory once your program/object is out of scope or process ends.Thee array in javascript, the list in python all resize automatically which is abstracted from the programmer it increase the capacity i.e double the the initial memory allocation every time you maxed out the allocated one by adding items in the list or array. People always bash C the mother of all languages that has remain top 3 for decades in the midst of all languages which is the foundation of all modern languages with Zig included, then if C is so bad and have issues why not write zig in Assembly full fledged, why wrapping around a so called bad language and then waving hands as if you have save C. Linux kernel has thousands of lines of codes which are all written in C with device drivers, embeded software, micro controllers, IOT, all run on C and yet C is so faulty and bad but nothing come closer to the ubiquity of C not C++ not Rust or any outliers language that want to shame C. If you have issue with writing elegant code, freeing your allocated memory when you suppose to please tell me how that is the problem of C, that is on you the programmer and maybe you should never code in low level/high level language and stick with higher level languages like Python, C#, javascript and .... One thing I know is that no way you're going to be faster than C no way!! , then what is your new nuances ? memory management? LMFAO NO! all you did is build a mini GC(garbage collector) with some fancy syntax all wrapped around C, nothing new, you never solve the problem you just covered it up and provided a blanket and extended the blanket to gullible programmer who think this is the savior. This is why none of this language ever getting in Linux Kernel or going to ever be use for any embeded devices. Stop shaming C and making mess by explaining not so called concepts that lead nowhere. The MMU is an hardware device and it's so important that even the ISA needed it to be an hardware and need a driver by the OS to control it so even when you make a system call to allocate memory you're don't actually have the actual memory what you have is a virtual memory and when you lend something you should always return it so you can be granted another day 😂 else you hoarding it and taking away from others that might need it. If kernel developers, device drivers developer uses C safely so can you and so should you.
Every time you ask for eight bytes, you really get a 4 kilobyte page? What planet are you from dude? Are you calling brk or sbrk system calls directly? Pretty sure most runtime standard libs have a reasonable layer above that...
@@kristoff-it I really don't think repeated calls to malloc gets a new full 4K pages each time it's called for a few bytes... That is of course you're using a sane standard library.
@@kristoff-it I wrote an allocator for a realtime embedded application. Its fast, deterministic, supports freeing memory... I might create a hook into that allocator to support secure segmentation with a hardware memory protection unit. A full MMU is usually not available in embedded platforms.
Yeah, you're talking about something like "malloc" or "new", which is not the "operating system". When he talks about getting memory from the operating system, he is referring to system calls. Specifically, he talks about "mmap". This talk is exactly about how these "reasonble layers above that" are implemented, and how you may implement some yourself if you have such low-level requirements (which, some do).
@@kayakMike1000 That's because "malloc" isn't a thing as far as the operating system is concerned. Malloc doesn't give you "new" memory, it's just an abstraction on top of memory you already have. Only the operating system can give or take away memory. Malloc doesn't actually "get" anything unless you reach the heap limit.
This was an awesome presentation! Really high quality stuff. Good work Benjamin and Zig Showtime!
Hot, damn. This was so helpful and it got recommended to me at just the right time. Absolutely amazing introduction.
I would definitely love some more talks like these about fundamentals of systems programming and how they are done in zig
this should be in the documentation..as someone coming from gc language, i dont understand allocator at all..i do understand about pointer and stuff, but nothing about allocator
That is beyond the scope of a single language. These are general computer science techniques
allocations are a thing in gc languages though....
unless your language is also dynamic in which case everything is heap allocated
@@v0xlprobably JavaScript which is heap allocated afaik
I don't even program in Zig (yet) and thought this talk was packed with tons of useful information that would be useful for all programmers to know
Zig is the language I started to like even though I'll never use it probably.
Amazing talk! I've seen it like 5 times already in the span of around a year, and always come back when dealing with memory to find out I slowly understand more.
Amazingly well explained, thank you so much Benjamin!
You may want to add the Q&A part of the talk as a separate chapter
If anyone was wondering why Zig can benchmark faster than C, here's your answer. In skilled hands, this is going to be an awesome tool.
The arena allocator is what the go developers are trying to do now, the zig has made it very simple to control the allocaations but in go it requires wrapping the make function.
This was incredibly helpful, thanks!
This is one of the best videos I have ever watched.
Amazing presentation! It answered a lot of questions I had about allocators.
Thank you Benjamin Feng!
Fantastic talk Benjamin! The slides were to-the-point and you explained some key concepts well. Cheers!
very well explained, thank you benjamin for that talk
Penomenal talk. Very informative!
great talk thank you
great talk. learned a lot.
Great video
awesome and amazing presentation. its fun to watch and I learn a lot from this presentation. zig seems to be more interesting to me now. but so far I only program in c#, python & go (c&c++ for long long time ago). Not sure about how zig will be easy to program or not. but I really wanted to try a language without gc.
Great presentation as always . Anyways what is the name of the font
ZIG is awesome 🚀🚀🚀
24:27 I thought cache pressure would be subsumed under memory fragmentation as a problem. Is there some other consequence of fragmentation that I'm missing?
What is the bug/s in alloca() that keep it from being implemented in Zig? Dynamic allocation on the stack is incredibly useful and it's accepted by most compilers now.
Alloca() doesn't work with scopes. It "frees" its memory at the end of the function, every time. It's a shame because it hurts its usefulness a lot.
@Pierre Brassart isn't that intended? The memory is on stack so of course it gets freed when the stack frame gets dropped.
@@VojtaJavora replying quite a bit late, but consider for example C code like this:
for (size_t i = argc; i --> 0;)
{
size_t len = strlen (argv [i]);
char *buff = alloca (len);
/* snip */
}
this has two major problems:
- the memory is allocated every iteration, and only freed on function exit, meaning memory usage is linear in argc, where a VLA or malloc/free would have memory usage constant in argc
- whereas malloc returns NULL on allocation failure, with alloca (and VLAs too) the behaviour is undefined (and the stack is usually much smaller than the heap)
of course that can be largely mitigated with better API design, providing realloca and checking for stack overflow (that would be very hard if you use a form of shadow stack, green thread or whatever though)
i like the i think quake style bump allocator. has 2 stacks that grow towards the center and allows setting marks to free to mark. it's not expandable, but you typically know how much memory you want in an arena allocator.
what meta-data would you be concerned with in a slab allocator?
First that comes to mind is which blocks are free/taken. You could use single bits and flip it from 0 to 1 to tag block as "in use". The smaller blocks you have and more, the more metadata (bytes) you need to store which one are used and free. Because you know size of each block in slab, you just check for first zero position in metadata and multply that by size to find a pointer in memory. It's really fast, and each byte can store information about 8 blocks in slab.
@@wiktorwektor123 this would be the ideal method. it would be pretty quick finding the first empty block just by comparing 64 bits (or more) at a time to zero.
@@androth1502 You can also store number of free blocks in slab, if slab have a lot of small blocks or just for every slab. You can use it to tell allocator to reserve next slab if you have none of free left or some number free left or by percentage free left. It would be useful then to reserve new slab full of free blocks and have it just in case, because it's slow operation and if this is game then allocating memory in the middle of frame for paricles isn't good idea.
nice :)
Memory is such a bear
But if someone is really okey with using malloc/free allocator for everything? It is kinda ugly to pass one single allocator all around. Maybe for situations like this we could have a module level constant or something, so we could set the allocator ones and compiler will pass it around for us?
You can define a constant like that in your own code, no problem. You'll still have to pass it into the standard library constructs yourself though. Having special support for that in the compiler isn't necessary, as you can just write some shims around the standard library that do that for you (or someone could write a Zig package on top of the standard library that does so). The compiler itself doesn't know about allocators at all.
Are you *really* okay with using malloc? Are you always checking to ensure that malloc successfully allocated memory? Are you always handling its failure case? Are you also architecturally guaranteeing that your code not only lacks dangling pointers now, but also will never experience a regression from largely unrelated code that retroactively creates dangling pointers? If your code cannot be formally proven to be memory safe, it probably isn't.
@@Cons-Cat I'm okey with using malloc.
@@Cons-Cat - Without a formal proof that your assertion is sound, it probably isn't :)
@@davidste60 ohhhh snap...
Why does people always lay abstractions on already existing abstractions then give it a name and called it the new nuances? There is only one way to allocate memory on the heap and it's by asking the OS plus even the the OS doesn't give you direct access it's a virtual memory No program I said it again no program has direct memory access that is why the OS is the manager and all you get is a virtual memory which will then be translate to actual memory/variable during compilation and linking. This is why cross compiler exist and this is why platform compiled program can only run on the architecture and OS that it's compiled on. The problem is not C the problem is the safety and resource management which is why we need OS in the first place and to make it harder ISA is different per architecture ARM is different from intel and so on. I'm very sure everyone bashing C would do the same if there is no way routine provided to allocate memory on the heap. Please if you're among the basher just stick to writing software with higher level language and not high level language like C.
No programming language is perfect this is why no software or application will be perfect , in fact nothing in life is perfect not human being nor animal, nor infrastructure, nor any natural phenomenon but the imperfection is what makes a lot unique it's the imperfection that differentiate lot of things in our universe without that we all going to look the same.
There is a reason why the OS manage the resources , especially "Memory" This is done so that memory is protected from other process and also from hackers if you run a program 5 times you going to get different memory location for the data and codes this can be check with xdump and running your program in debug mode, every process has an illusion of having infinite memory and being the only process running at any given time.
So then my question is what do you do differently if there's only one source of truth to allocate memory meaning you are still doing the same thing any programmer would have done. This is what python done, this is what javascript done and ......... The difference with higher level languages is GC(garbage collector) so that you don't have to worry about freeing the memory once your program/object is out of scope or process ends.Thee array in javascript, the list in python all resize automatically which is abstracted from the programmer it increase the capacity i.e double the the initial memory allocation every time you maxed out the allocated one by adding items in the list or array.
People always bash C the mother of all languages that has remain top 3 for decades in the midst of all languages which is the foundation of all modern languages with Zig included, then if C is so bad and have issues why not write zig in Assembly full fledged, why wrapping around a so called bad language and then waving hands as if you have save C.
Linux kernel has thousands of lines of codes which are all written in C with device drivers, embeded software, micro controllers, IOT, all run on C and yet C is so faulty and bad but nothing come closer to the ubiquity of C not C++ not Rust or any outliers language that want to shame C. If you have issue with writing elegant code, freeing your allocated memory when you suppose to please tell me how that is the problem of C, that is on you the programmer and maybe you should never code in low level/high level language and stick with higher level languages like Python, C#, javascript and ....
One thing I know is that no way you're going to be faster than C no way!! , then what is your new nuances ? memory management? LMFAO NO! all you did is build a mini GC(garbage collector) with some fancy syntax all wrapped around C, nothing new, you never solve the problem you just covered it up and provided a blanket and extended the blanket to gullible programmer who think this is the savior. This is why none of this language ever getting in Linux Kernel or going to ever be use for any embeded devices. Stop shaming C and making mess by explaining not so called concepts that lead nowhere. The MMU is an hardware device and it's so important that even the ISA needed it to be an hardware and need a driver by the OS to control it so even when you make a system call to allocate memory you're don't actually have the actual memory what you have is a virtual memory and when you lend something you should always return it so you can be granted another day 😂 else you hoarding it and taking away from others that might need it. If kernel developers, device drivers developer uses C safely so can you and so should you.
Every time you ask for eight bytes, you really get a 4 kilobyte page? What planet are you from dude? Are you calling brk or sbrk system calls directly? Pretty sure most runtime standard libs have a reasonable layer above that...
Yes those things in "most runtime standard libs" are called allocators and are the topic of this talk.
@@kristoff-it I really don't think repeated calls to malloc gets a new full 4K pages each time it's called for a few bytes... That is of course you're using a sane standard library.
@@kristoff-it I wrote an allocator for a realtime embedded application. Its fast, deterministic, supports freeing memory... I might create a hook into that allocator to support secure segmentation with a hardware memory protection unit. A full MMU is usually not available in embedded platforms.
Yeah, you're talking about something like "malloc" or "new", which is not the "operating system". When he talks about getting memory from the operating system, he is referring to system calls. Specifically, he talks about "mmap". This talk is exactly about how these "reasonble layers above that" are implemented, and how you may implement some yourself if you have such low-level requirements (which, some do).
@@kayakMike1000 That's because "malloc" isn't a thing as far as the operating system is concerned. Malloc doesn't give you "new" memory, it's just an abstraction on top of memory you already have. Only the operating system can give or take away memory. Malloc doesn't actually "get" anything unless you reach the heap limit.
refactored some of my old projects that used (malloc/free) directly
and i got a performance increase