4 ms·

> One major limitation of malloc (and even the best implementations like jemalloc and dlmalloc) is that they try to use a single allocator for each data structu

by mallaco 10y ago

> One major limitation of malloc (and even the best implementations like jemalloc and dlmalloc) is that they try to use a single allocator for each data structure. This is a mistake: A huge performance gain can be had by using a separate allocator for each of your data structures — or rather, for each of your data usage patterns. I stopped reading the article at this point. This statement has been disproven repeatedly over the years with Hoard and jemalloc. It is counter-intuitive but the data backs it up. Custom per-data-structure allocators can fragment the global memory arena and cause more CPU cache misses as result of the extra code involved. The latest/greatest malloc/free implementations use a myriad of optimizations to achieve speed improvements that a custom allocator implementation would rarely use. It's not an accident that jemalloc is so widely used in major applications - it works extremely well. https://github.com/jemalloc/jemalloc/wiki/History https://github.com/jemalloc/jemalloc/wiki/History https://github.com/jemalloc/jemalloc/wiki/Adoption https://github.com/jemalloc/jemalloc/wiki/Adoption

gens 10y ago
How about fragmentation ? AFAIK jemalloc is horrible when it comes to memory usage.
- mallaco 10y ago
  My use of jemalloc in multithreaded servers shows the opposite to be true. Memory use is a little higher than the single mutex dlmalloc, but you'd expect this with a modern high performance thread aware malloc implementation. You think MariaDB would choose jemalloc if it wasn't efficient in memory use?
  - biocomputation 10y ago
    >> You think MariaDB would choose jemalloc if it wasn't efficient in memory use? I don't think this is a smart way of choosing an allocator.
- pcwalton 10y ago
  What makes you say that? jemalloc's fragmentation is very low [1]. [1]: https://blog.pavlov.net/2007/12/04/vlad-and-analysis-of-dtrace-was-used/ https://blog.pavlov.net/2007/12/04/vlad-and-analysis-of-dtra...
  - gens 10y ago
    The pictures there are missing (i get error 400 when i try to download them directly). After 10min of googleing i found this [0] (it shows swap), and this [1] from 2012. Nothing conclusive, especially considering that all the popular malloc-s can be tuned. [0] https://suniphrase.wordpress.com/2015/10/27/jemalloc-vs-tcmalloc-vs-dlmalloc/ https://suniphrase.wordpress.com/2015/10/27/jemalloc-vs-tcma... [1] https://juliank.wordpress.com/2012/05/31/memory-allocators/ https://juliank.wordpress.com/2012/05/31/memory-allocators/ As a bonus, i found a phrack article on jemalloc. http://phrack.org/issues/68/10.html#article http://phrack.org/issues/68/10.html#article
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.

by mallaco 10y ago

gens 10y ago

How about fragmentation ? AFAIK jemalloc is horrible when it comes to memory usage.

mallaco 10y ago
My use of jemalloc in multithreaded servers shows the opposite to be true. Memory use is a little higher than the single mutex dlmalloc, but you'd expect this with a modern high performance thread aware malloc implementation. You think MariaDB would choose jemalloc if it wasn't efficient in memory use?
- biocomputation 10y ago
  >> You think MariaDB would choose jemalloc if it wasn't efficient in memory use? I don't think this is a smart way of choosing an allocator.
pcwalton 10y ago
What makes you say that? jemalloc's fragmentation is very low [1]. [1]: https://blog.pavlov.net/2007/12/04/vlad-and-analysis-of-dtrace-was-used/ https://blog.pavlov.net/2007/12/04/vlad-and-analysis-of-dtra...
- gens 10y ago
  The pictures there are missing (i get error 400 when i try to download them directly). After 10min of googleing i found this [0] (it shows swap), and this [1] from 2012. Nothing conclusive, especially considering that all the popular malloc-s can be tuned. [0] https://suniphrase.wordpress.com/2015/10/27/jemalloc-vs-tcmalloc-vs-dlmalloc/ https://suniphrase.wordpress.com/2015/10/27/jemalloc-vs-tcma... [1] https://juliank.wordpress.com/2012/05/31/memory-allocators/ https://juliank.wordpress.com/2012/05/31/memory-allocators/ As a bonus, i found a phrack article on jemalloc. http://phrack.org/issues/68/10.html#article http://phrack.org/issues/68/10.html#article

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.