Live data from Hacker News

Memory – Part 4: Intersec’s custom allocators

techtalk.intersec.com

61–62 of 62 posts

Re: Memory – Part 4: Intersec’s custom allocators

#61
post #59
post #42

Earlier quoted context omitted.

That's essentially what I do in much of my C code: implement pool allocators. And that's essentially what the post we're commenting on is talking about. Incidentally, good common case for 8-byte allocations that is actually common in real-world C code: 32 bit linked list nodes (4 bytes nextptr, 4 bytes dataptr).

Hmm, are you sure that this (linked lists with small elements) is a good example which you should tell people about? Linked lists are bad because they have big overhead (8 bytes for every element in your case - which dominates by a large margin if you store an int in each node for example) and they are really bad for CPU caches (they have very little spatial locality), thus slowing down your code. I much rather prefe…

Yeah, but they have some unique characteristics related to inserting/deleting from the middle or beginning of the list. They're actually used in a few places in the linux kernel, for performance reasons, in spite of cache locality issues.

Re: Memory – Part 4: Intersec’s custom allocators

#62
post #55

Earlier quoted context omitted.

I admit that test stress some corner cases (at least some cases that the allocator designer consider as corner cases). That said, malloc has no choice but supporting that use case. A use case for such pattern is a message-posting with workers: you queue some messages that are later unqueued and processed by a different thread. This is an increasingly common pattern in modern programs. In that pattern the message is a…

You're not wrong that malloc-based message passing causes that load on malloc, but if performance of the message-passing code is important, you'd want to use a ring buffer anyway - cross-CPU or not, malloc is pretty slow.

Clearly, we go back to the initial statement: for specific use cases, we need specific allocators.
Post reply on HN