What's a Memory Allocator Anyway? - Benjamin Feng

From Zig SHOWTIME #5

0:00 Title
0:39 Talk
34:19 Interview

[ryantaylor]

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

[hbobenicio]

This was an awesome presentation! Really high quality stuff. Good work Benjamin and Zig Showtime!

[AtomToast]

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

[michaelscofield]

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.

[jordanmcconnon]

This is one of the best videos I have ever watched.

[statebased]

Brings back memories... A) a mark-and-sweep garbage collector is just one page of code and can be ok for non-real time, with much non-pointer data. B) combining allocation and memory mapping (to storage, to transport buffers) is a handy piece of toolkit to have, and not so much more work. Of course it restricts many options.
Thanks for the presentation!

[moonlightflightbeyondtheveil]

Amazingly well explained, thank you so much Benjamin!

[LoneTech]

4:05 alloca() isn't a Linux feature, but a compiler feature. Its implementation is simple; it just bumps the stack pointer like any other stack allocation, and on return it uses the base pointer, which alloca does not change. The compiler must not attempt to use top of stack things, like non-register arguments, across the alloca call, and must use a base pointer in routines that do call alloca (it's a common optimization to omit the base pointer). If alloca() were implemented as a library routine then it would be unusual, returning with an altered stack pointer, but that's not unique; longjmp also does.

Still, alloca() doesn't seem like a feature you'd typically need. It can be replaced with C99 variable length arrays, which people are similarly combative about, unless you need to dynamically make multiple allocations in one stack frame (e.g. building a temporary graph with an unknown length loop).

[_slier]

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

[tullochgorum]

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.

[ciCCapROSTi]

Zig is the language I started to like even though I'll never use it probably.

[flatdietsoda]

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.

[whiskeytuesday]

unimportant note: the code at 1:18 is broken

main.zig:6:19: error: use of undeclared identifier 'i' (exit status 1)

it should be result += curr

[adityavsx]

Pretty useful information and very dense. Loved it;

[linusandersen]

very well explained, thank you benjamin for that talk

[yanisfourel]

omg brilliant talk, long time I havn't felt such an Aha moment about low level programming

[MrFedX]

Amazing presentation! It answered a lot of questions I had about allocators.

[deckarep]

Fantastic talk Benjamin! The slides were to-the-point and you explained some key concepts well. Cheers!

[mononix]

You may want to add the Q&A part of the talk as a separate chapter

[edgeeffect]

This is an excellent talk even if you don't care so much about memory allocation. The software industry is full of people who "know the answer", have a "perfect" language, or "perfect" processes, or "the one true algorithm"... I love how Benjamin is working through all the available allocation options and saying "yeah, but, this sucks because..." or "it's still not ideal because...." or "this has costs though"... More science... less religion... delicious.