4 ms·

> This statement has been disproven repeatedly over the years with Hoard and jemalloc. It is counter-intuitive but the data backs it up. What data is that? I w

by ksk 10y ago

> This statement has been disproven repeatedly over the years with Hoard and jemalloc. It is counter-intuitive but the data backs it up. What data is that? I would honestly love to see it. TBH, it would not change my mind since I have practical experience of custom allocators working better for me over other general ones. But then again, I work in a severely memory constrained environment. >Custom per-data-structure allocators can fragment the global memory arena and cause more CPU cache misses as result of the extra code involved. Well, pretty much all modern allocators have techniques to avoid fragmentation. But that is besides the point. But your comment did not make sense to me. Perhaps it does to others. As the developer you know the general sizes of your data structures, their usage patterns, their lifetimes and the frequency/rate at which they are allocated (all of which a general allocator has to guess or use some sort of rudimentary strategy which adds needless metadata). That is where you can design your custom allocator to actually reduce fragmentation. It may well be that the gain from a custom allocator isn't worth it, but I don't quite understand how it can get _worse_ as you claim. >The latest/greatest malloc/free implementations use a myriad of optimizations to achieve speed improvements that a custom allocator implementation would rarely use. So what exactly stops you from writing in those optimizations in a custom allocator? Certain domains, like game programming for e.g. People have been doing this for decades with excellent results. >It's not an accident that jemalloc is so widely used in major applications - it works extremely well. Sorry, you have no possible way of knowing _why_ everybody else uses something. That itself is not an argument for anything.

mallaco 10y ago
Custom allocators have the disadvantage of not knowing how the rest of the heap is managed. They are at a disadvantage to a modern well designed memory allocator like hoard or jemalloc. Feel free to examine the many papers put out by Emery Berger on the subject of memory allocation as well as the design documents of jemalloc.
- ksk 10y ago
  >Custom allocators have the disadvantage of not knowing how the rest of the heap is managed. Sure, but they can work out of a fixed region statically allocated on startup. >Feel free to examine the many papers put out by Emery Berger on the subject of memory allocation as well as the design documents of jemalloc. https://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf https://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pd... Do you have links to more? I only found one paper from 14 years ago. It is interesting but it comes with a huge YMMV since they only examined specific projects which might not have a pattern that _requires_ a custom strategy anyway. A distribution of the objects along with time distribution would have been nice to include.
mallaco 10y ago
> But then again, I work in a severely memory constrained environment Then likely you're dealing with a single-threaded application where dlmalloc will work just fine. No multi-threaded contention for allocation/deallocation.
- ksk 10y ago
  There is a ton of YMMV with these things. dlmalloc works fine, and so do other general purpose allocators. My custom allocator is and will always be superior because it takes advantage of the fact that I only perform allocations from a very very small subset of known sizes, at very specific points. The allocator does next to nothing during dealloc, except at certain times when it can do things in bulk. I've modeled the allocator so it doesn't have to "be prepared" for anything else. I allocate a large chunk of memory which is never released to the OS so I don't ever have to worry about other threads messing up my memory region.

by ksk 10y ago

mallaco 10y ago

Custom allocators have the disadvantage of not knowing how the rest of the heap is managed. They are at a disadvantage to a modern well designed memory allocator like hoard or jemalloc. Feel free to examine the many papers put out by Emery Berger on the subject of memory allocation as well as the design documents of jemalloc.

ksk 10y ago
>Custom allocators have the disadvantage of not knowing how the rest of the heap is managed. Sure, but they can work out of a fixed region statically allocated on startup. >Feel free to examine the many papers put out by Emery Berger on the subject of memory allocation as well as the design documents of jemalloc. https://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf https://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pd... Do you have links to more? I only found one paper from 14 years ago. It is interesting but it comes with a huge YMMV since they only examined specific projects which might not have a pattern that _requires_ a custom strategy anyway. A distribution of the objects along with time distribution would have been nice to include.

mallaco 10y ago

> But then again, I work in a severely memory constrained environment Then likely you're dealing with a single-threaded application where dlmalloc will work just fine. No multi-threaded contention for allocation/deallocation.

ksk 10y ago
There is a ton of YMMV with these things. dlmalloc works fine, and so do other general purpose allocators. My custom allocator is and will always be superior because it takes advantage of the fact that I only perform allocations from a very very small subset of known sizes, at very specific points. The allocator does next to nothing during dealloc, except at certain times when it can do things in bulk. I've modeled the allocator so it doesn't have to "be prepared" for anything else. I allocate a large chunk of memory which is never released to the OS so I don't ever have to worry about other threads messing up my memory region.