Memory – Part 4: Intersec’s custom allocators
techtalk.intersec.com
Memory – Part 4: Intersec’s custom allocators
1–10 of 62 posts
Re: Memory – Part 4: Intersec’s custom allocators
#2Very interesting article, especially the t_scope allocator - I never knew you could get GCC to perform that cleanup automagically. One minor grammar point: isn't a lock under contention a contended lock, not a contented lock?
Re: Memory – Part 4: Intersec’s custom allocators
#3Very interesting article, especially the t_scope allocator - I never knew you could get GCC to perform that cleanup automagically. One minor grammar point: isn't a lock under contention a contended lock, not a contented lock?
Wording issue fixed.
Re: Memory – Part 4: Intersec’s custom allocators
#4It should be obvious that a lot of 8 byte mallocs will give bad performance and horrible memory use. This article and in particular the benchmarks in it would be a lot more informative if the test case was more realistic.
Please add at least 32 or 64 bytes of payload to the linked list structure and re-run the benchmarks. Even that is a very small allocation block, but is on the lower end of realistic allocation sizes although not a good practice.
Re: Memory – Part 4: Intersec’s custom allocators
#5It should be obvious that a lot of 8 byte mallocs will give bad performance and horrible memory use. This article and in particular the benchmarks in it would be a lot more informative if the test case was more realistic. Please add at least 32 or 64 bytes of payload to the linked list structure and re-run the benchmarks. Even that is a very small allocation block, but is on the lower end of realistic allocation size…
8-byte mallocs are expensive because most mallocs have per-allocation memory overhead to track things. This is exactly why you may want to use a different allocator.
IOW, you're angle is that instead of finding a solution to the problem, instead choose a different problem. You don't always have that luxury.
My background on this problem is compilers. Compilers allocate lots of little structures that represent tree nodes, values, tokens, etc. Forcing them all to be a minimum of 32 or 64 bytes in size on the basis that would justify using malloc for them, would be more than a little bizarre. Arena allocation - both per module (for structures that need to persist for the whole compilation) and stack based (for structures that are discarded after e.g. evaluation or codegen) - makes far more sense than contorting the problem so that malloc makes sense.
Re: Memory – Part 4: Intersec’s custom allocators
#6Very interesting article, especially the t_scope allocator - I never knew you could get GCC to perform that cleanup automagically. One minor grammar point: isn't a lock under contention a contended lock, not a contented lock?
Wording issue fixed.
Is the source for the allocators freely available? Would love to study those.
Re: Memory – Part 4: Intersec’s custom allocators
#7It should be obvious that a lot of 8 byte mallocs will give bad performance and horrible memory use. This article and in particular the benchmarks in it would be a lot more informative if the test case was more realistic. Please add at least 32 or 64 bytes of payload to the linked list structure and re-run the benchmarks. Even that is a very small allocation block, but is on the lower end of realistic allocation size…
8-byte mallocs are expensive because most mallocs have per-allocation memory overhead to track things. This is exactly why you may want to use a different allocator. IOW, you're angle is that instead of finding a solution to the problem, instead choose a different problem. You don't always have that luxury. My background on this problem is compilers. Compilers allocate lots of little structures that represent tree no…
> 8-byte mallocs are expensive because most mallocs have per-allocation memory overhead to track things. This is exactly why you may want to use a different allocator.
I guess if the objective of the article is to point out the obvious fact that mallocing 8 bytes at a time is a bad idea, then showing up some actual numbers from actual malloc implementations is a good idea. However, even small objects in practical problems are usually bigger than 8 bytes, so making the allocation size a bit bigger would give more realistic figures.
Overall I think the article was informative and well written but more realistic test case would better point out when to write a custom allocator and what allocator to choose for a particular usage pattern.
Re: Memory – Part 4: Intersec’s custom allocators
#8It should be obvious that a lot of 8 byte mallocs will give bad performance and horrible memory use. This article and in particular the benchmarks in it would be a lot more informative if the test case was more realistic. Please add at least 32 or 64 bytes of payload to the linked list structure and re-run the benchmarks. Even that is a very small allocation block, but is on the lower end of realistic allocation size…
I ran the test with a payload of 32 bytes. Here are the results:
Non-Contented test:
* ptmalloc: alloc 39M/s, free 49M/s
* tcmalloc: alloc 42M/s, free 40M/s
* jemalloc: alloc 21M/s, free 21M/s
* t_stack: alloc 110M/s
Contended test:
* ptmalloc: alloc 6.1M/s, free 6.4M/s
* tcmalloc: alloc 25M/s, free 11M/s
* jemalloc: alloc 18M/s, free 6.5M/s
Note that the results are less accurate that those provided in the article since the number of allocations per batch is smaller (due to the limited amount of RAM available on my desktop).
That's said, the article does not pretend benching realistic patterns.
Re: Memory – Part 4: Intersec’s custom allocators
#9Re: Memory – Part 4: Intersec’s custom allocators
#10The fact that returning memory to the Kernel is hard is supported by the circumstance, that most allocators will use brk/sbrk to resize the data segment of the executing process to allocate memory, at least if they shall allocate few memory.
The other fact, that allocators have to lock global data structures is also not true. Most modern operating systems supports thread-local storage and therefore you don't need locking because you can keep much per-threads allocators, and only if you want to release memory of a foreign thread you have to lock (but that's also bad practice in most cases).
Therefore, this article is great if your horizon end at the default allocators tcmalloc, ptmalloc and jemalloc, but the reality is much more complex. The fact that such a thing doesn't exists isn't founded in the fact that it's hard to implement, it's founded in the fact that there is no need for such an allocator, because most well-written software will allocate large chunks of memory.