8 ms·

Mimalloc – A compact general-purpose allocator

356 points by dmit 7y ago

deleted 7y ago
[deleted]
huhtenberg 7y ago
The tricky part with allocators is always the multi-threaded setups. Even something as simple as a bunch of threads doing malloc-free in a loop will drop performance of a lot of allocators to the floor, due to some sort of central locking or excessive cache thrashing. This is typically solved by adding per-thread block pools, free lists or some such. If you go further down the rabbit hole, there's a case when blocks are allocated in one thread and freed in another, your very typical producer-consumer setup. This too further complicates things with the pool/freelist setup and requires periodic rebalancing of freelists and pools. So once all this is accommodated, a well-tuned allocator inevitably converges to a model with central slabs/pools/freelists and per-thread caches of the same, which are periodically flushed into the former. Then it all comes down to routine code optimization to make fastpaths fast, through lock-free data structures, some clever tricks and what not. In other words, it's always nice to read through someone's allocator code, but in the end this is a very well-explored area and there's basically a single stable point once all common scenarios are considered.
- pjmlp 7y ago
  To the point you really need specialized knowledge. I remember DrDobbs and The C/C++ Users Journal having ads for companies whose sole product was a memory allocator for different kinds of deployment scenarios.
  - AndrewStephens 7y ago
    And those products really did help. Microsoft's implementation of malloc performed terribly for many workloads - dropping in a 3rd party allocator could speed up your software considerably. It wasn't until well into the 2000s until the standard allocators started to become good enough to make the 3rd party libraries less essential. Many of them you can still buy today and they probably still help with certain types of software.
- fabrice_d 7y ago
  They claim to perform well on at least some multi-thread workloads (read https://github.com/microsoft/mimalloc#performance https://github.com/microsoft/mimalloc#performance): "The larson server workload allocates and frees objects between many threads. Larson and Krishnan [2] observe this behavior (which they call bleeding) in actual server applications, and the benchmark simulates this. Here, mimalloc is more than 2.5× faster than tcmalloc and jemalloc due to the object migration between different threads. This is a difficult benchmark for other allocators too where mimalloc is still 48% faster than the next fastest (snmalloc)."
- Veedrac 7y ago
  There are a lot of ways to write the same story; Mimalloc has a few innovations of its own, has good benchmarks to justify them, and the paper is a very good read. In particular, Mimalloc works to increase data locality, by using per-‘page’ (64kB memory blocks) free queues. All this with a codebase almost a tenth the size of jemalloc, and it's looking very promising.
- trianglesphere 7y ago
  It's a little hidden, but this is out of MS research, and seems to be initially designed for ref-counted scripting languages. I'm not really sure how much they focused on multi-threaded stuff. >We present mimalloc, a memory allocator that effectively balances these demands, shows significant performance advantages over existing allocators, and is tailored to support languages that rely on the memory allocator as a backend for reference counting. https://www.microsoft.com/en-us/research/publication/mimalloc-free-list-sharding-in-action/ https://www.microsoft.com/en-us/research/publication/mimallo...
  - Veedrac 7y ago
    That's not what the quote means, really. They have best-in-class performance on both single- and multi-threaded workloads. It is just saying that the allocator supports a deferred_free callback, which is zero-overhead in the fast path and negligible overhead in the slow path.
- bakery2k 7y ago
  What if I'm writing code that's strictly single-threaded? Presumably malloc could be simpler and/or faster in this special case? Is there a production-ready allocator that's optimized for single-threaded use?
  - gok 7y ago
    It's very hard to not accidentally pull in a dependency that makes your code multithreaded.
    - 01100011 7y ago
      You guys could argue this all day and both be right. Depending on what type of system you're working on, you are either very likely to pull in a multithreaded dependency or you are not. Systems programming is different from game programming is different from web client programming is different from kernel development. In most of my career, I would have never accidentally pulled in a multithreaded dependency, but I could see how that could be easy to do in some cases.
  - imtringued 7y ago
    It is already faster because there is no lock congestion.
  - rurban 7y ago
    For this use case a good copying collector would be best. Beats any malloc by miles.
- pizlonator 7y ago
  This allocator appears to have some genuinely interesting things in its multi thread support: - it looks like it avoids atomics on common cases of malloc and free. That’s a big deal and not all malloc a accomplish that. - it looks like it has cleverness specifically for the case that one thread frees an object into another thread’s heap. It seems like this case was given some special consideration - in particular avoiding the need for the thread that owns the heap to stop or synchronize at the moment that happens even though that thread is non-atomically allocating and freeing in that same heap. So, it’s always easy to sound smart by saying that a field is well explored - but it looks like this thing actually has some cool new ideas in it.
  - gpderetta 7y ago
    >it looks like it avoids atomics on common cases of malloc and free. That’s a big deal and not all malloc a accomplish that. Many mallocs implementations try to avoid one cache per thread because it can waste a huge amount of memory in applications with thousands of threads opting for per cpu pools or similar solutions. These solutions help with contention but still require atomics (unless using something like restartable sequences). It is a trade-off, but for applications that use one thread per cpu, completely private free lists can branch win of course.
    - emeryberger 7y ago
      All modern allocator implementations I am aware of (including Hoard and Mesh) use per-thread caches (of a limited size), and thus avoid the use of atomic operations in the common case while also avoiding blowup (wasted memory caused by using a memory allocator that "leaks" -- see the Hoard paper (ASPLOS 2000, https://people.cs.umass.edu/~emery/pubs/berger-asplos2000.pdf https://people.cs.umass.edu/~emery/pubs/berger-asplos2000.pd...) for a full discussion).
      - pizlonator 7y ago
        Does hoard avoid atomic ops on the common case of both malloc and free?
- Quekid5 7y ago
  Andrei Alexandrescu had a great talk[0] on allocators and this convinced me that if you really care about allocator performance[1] what you need is a tunable and composable system. The whole idea of how and when (runtime/compile-time) to choose the appropriate allocator is also interesting. [0] https://www.youtube.com/watch?v=LIb3L4vKZ7U https://www.youtube.com/watch?v=LIb3L4vKZ7U [1] I suppose there's a digression to be had here about allocation being trivial and RAII-style deallocation not really being deterministic, but...
- jasonwatkinspdx 7y ago
  You should actually read the technical report: https://www.microsoft.com/en-us/research/uploads/prod/2019/06/mimalloc-tr-v1.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... This has some quite clever and very carefully considered details around concurrency. > in the end this is a very well-explored area and there's basically a single stable point once all common scenarios are considered. I think it's absurd to call allocation a solved problem where there's one known optimal design.
- yason 7y ago
  but in the end this is a very well-explored area With a lot of interesting new generic allocators that beat the competition hands down popping up in the last 10 years, I'd dare to claim the area is not very well explored. It has indeed been explored a lot but it seems that there's still low-hanging fruit. Every few years someone writes an allocator that makes significant improvements over the previous generation implementations. I love to see such action on "solved problems".
- plietar 7y ago
  You may want to look at snmalloc, another allocator we did at Microsoft Research. It specifically targets these producer / consumer scenarios. https://github.com/microsoft/snmalloc https://github.com/microsoft/snmalloc And the paper, which I’ll be presenting tomorrow at ISMM: https://github.com/microsoft/snmalloc/blob/master/snmalloc.pdf https://github.com/microsoft/snmalloc/blob/master/snmalloc.p...
fwip 7y ago
The benchmarks are very impressive! I am excited to read through this code and think on it. Edit: They do mention they're all from AMD's EPYC chip, which is a little idiosyncratic. Speculation: perhaps page locality is more important on this architecture.
- the_duke 7y ago
  The benchmark repo contains results with a Intel Xeon. Looks roughly similar: https://github.com/daanx/mimalloc-bench https://github.com/daanx/mimalloc-bench
m0zg 7y ago
The important thing about all this is to measure perf on realistic workloads before and after. I don't really believe in allocators that have "excellent performance" on everything.
longcommonname 7y ago
Just a general question in regards to using memory allocators, in the consideration of a C only application. The problems I encounter with allocator and heap manager are almost never solved by these types of frameworks. These problems include: 1. Improper usage of the memory returned that contradict implementation. 2. Pool allocators that don't have separation between individual blocks (performance reasons). 3. Specifying the lifetime of the memory to a thread or until specific events happen. 4. Difficult to diagnose corruption, with any tool available. Here's a specific scenario I deal with very often: There are N persistent worker threads. These worker threads have their own pool of memory, and prior to getting work we know this pool is clean. After the work is finished and before more work is recieved the memory is cleaned. Any excess requested memory is returned to the global-pool, and any memory that is "unmanaged" is dealt with properly. This means that people can do whatever heap management call you use (void * obtainMemory(size_t);) in the scope of business logic without having to worry about infrastructure concerns. Having a faster malloc/calloc doesn't benefit me as much as making the usage of memory easier, and the understanding of what happens easier.
shereadsthenews 7y ago
I always find comparisons with tcmalloc hard to parse, since it has a million knobs and the defaults are terrible. If they are running with 16 threads I would normally advise increasing the thread cache size far above the default 3MiB. also interesting would be jemalloc in per-CPU mode. As always the thing to do is build and run your own workload and see the results.
brian_herman__ 7y ago
I should create memealloc which converts all memory allocations to base64 encoded gifs
- Iwan-Zotow 7y ago
  with cats and unicorns inside
c-smile 7y ago
Looks like the same idea as Konstantin Knizhnik's thread_alloc: http://www.garret.ru/threadalloc/readme.html http://www.garret.ru/threadalloc/readme.html At least the same architecture of allocated chunks management.
PieUser 7y ago
they should not have tested on AWS
john-aj 7y ago
I never like names that require a “pronounced like” note, but cool project regardless.
- simias 7y ago
  Given the rather unpredictable nature of English pronunciation that's basically required for any made up word.
  - jing 7y ago
    Particularly since it would not be unreasonable to assume that the "mi" in mimalloc is incorrectly pronounced like the "mi" in Microsoft.
- emmelaich 7y ago
  Cool fact - I'd bet that no one pronounces MySQL like its author does.
- imtringued 7y ago
  That's what happens when languages like English adopt the foreign pronunciation of words instead of the English pronunciation. Now everything is an edge case and you can't be sure of the pronunciation even if it's an English word.
danlark 7y ago
We tried mimalloc in ClickHouse and it is two times slower than jemalloc in our common use case https://github.com/microsoft/mimalloc/issues/11 https://github.com/microsoft/mimalloc/issues/11
- MaxBarraclough 7y ago
  To be clear, your program ran at half speed, right? That's far worse than doubling the time spent in memory-management functions.
  - danlark 7y ago
    Yes, our program ran at half speed.
  - vinay_ys 7y ago
    It is quite bad if changing the allocator made your program run at half speed. It doesn't matter if the library itself consumed more CPU or caused more wait (guessing that's the case here) due to concurrency or excessive syscalls.
- deleted 7y ago
  [deleted]
- danlark 7y ago
  The developer helped us a lot to improve the speed and now it is almost at the same level as jemalloc for us
nh2 7y ago
Are there functions available with which I can at run-time query how much OS memory is used, how much handed out in allocations, how many mmap()ed pools are used, and so on? I find that one of the most important features of a malloc library to debug memory usage. glibc has these functions (like malloc_info()) -- they are very bugged in that they return wrong results, but after patching them to be correct, they are super useful.
- jasonzemos 7y ago
  Any more info/link on how they are incorrect and the patches you need to fix them?
  - nh2 7y ago
    Sure, my patches are linked in the bugs I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=24026 https://sourceware.org/bugzilla/show_bug.cgi?id=24026 - "malloc_info() returns wrong numbers" https://sourceware.org/bugzilla/show_bug.cgi?id=21556 https://sourceware.org/bugzilla/show_bug.cgi?id=21556 - "malloc_stats printing size_t fields as unsigned int" If you're interested in this topic: After finding one bug after the other due to 32-bit integer overflow in malloc.c, I just searched for "unsigned int" in that file for fun, and 30 seconds later found what I consider a security vulnerability in realloc(): https://sourceware.org/bugzilla/show_bug.cgi?id=24027 https://sourceware.org/bugzilla/show_bug.cgi?id=24027 In certain situations, if you realloc() e.g. 32G + 5 bytes (reallocs this large can happen in large programs e.g. for data analysis), it'll copy only 5 bytes, and leave the rest as memory garbage. That experience taught me that open source code being old doesn't mean anybody ever read it.
    - rurban 7y ago
      pt2malloc is only maintained by glibc, but not really. Since they cannot maintain it, they want to get rid of it. The upstream maintainer released a better version pt3malloc, which glibc refused to adopt. It needs one more word per alloc.
- ndesaulniers 7y ago
civility 7y ago
Is anyone aware of a good/fast single threaded allocator for cases where you don't need/want to pay for thread safety?
- deleted 7y ago
  [deleted]
- kllrnohj 7y ago
  If you're single threaded then you'll never have mutex contention so they'll always be fast-path. I'd suggest you actually prove that the memory barriers are actually a problem for you via profiling, since it's somewhat unlikely it is.
  - adwn 7y ago
    > If you're single threaded then you'll never have mutex contention so they'll always be fast-path. Concurrent algorithms (to which multi-thread capable allocators belong) typically necessitate design and performance compromises which aren't nullified by creating only a single thread. > I'd suggest you actually prove that the memory barriers are actually a problem for you via profiling, since it's somewhat unlikely it is. civility's reply to your post is somewhat rude, but they're right. It's rather arrogant to assume that the poster doesn't know what they're doing, without knowing anything about their specific problem. Modern allocators are complex pieces of software, typically with a lot of knobs and dials, and it is entirely plausible that an allocator tuned for single-threaded programs is more performant for a specific use case than a generic multi-thread allocator.
    - civility 7y ago
      > civility's reply to your post is somewhat rude Not as rude as I wanted to be. I expect answers like that from Stack Overflow or Reddit - just another condescending ego play without actually addressing the question. Regardless, thank you for your reply. I don't suppose you know a good single-threaded (or share-nothing across threads) allocator worth looking at?
    - 7y ago
tuananh 7y ago
the redis benchmark is interesting! Maybe antirez can make sth out of it
ksec 7y ago
The Dev at Discourse also try it with Ruby, the result aren't as good as jemalloc. [1] [1] https://twitter.com/samsaffron/status/1143048590555697152 https://twitter.com/samsaffron/status/1143048590555697152

356 points by dmit 7y ago

deleted 7y ago

[deleted]

The tricky part with allocators is always the multi-threaded setups. Even something as simple as a bunch of threads doing malloc-free in a loop will drop performance of a lot of allocators to the floor, due to some sort of central locking or excessive cache thrashing. This is typically solved by adding per-thread block pools, free lists or some such. If you go further down the rabbit hole, there's a case when blocks are allocated in one thread and freed in another, your very typical producer-consumer setup. This too further complicates things with the pool/freelist setup and requires periodic rebalancing of freelists and pools. So once all this is accommodated, a well-tuned allocator inevitably converges to a model with central slabs/pools/freelists and per-thread caches of the same, which are periodically flushed into the former. Then it all comes down to routine code optimization to make fastpaths fast, through lock-free data structures, some clever tricks and what not. In other words, it's always nice to read through someone's allocator code, but in the end this is a very well-explored area and there's basically a single stable point once all common scenarios are considered.

pjmlp 7y ago
To the point you really need specialized knowledge. I remember DrDobbs and The C/C++ Users Journal having ads for companies whose sole product was a memory allocator for different kinds of deployment scenarios.
- AndrewStephens 7y ago
  And those products really did help. Microsoft's implementation of malloc performed terribly for many workloads - dropping in a 3rd party allocator could speed up your software considerably. It wasn't until well into the 2000s until the standard allocators started to become good enough to make the 3rd party libraries less essential. Many of them you can still buy today and they probably still help with certain types of software.
fabrice_d 7y ago
They claim to perform well on at least some multi-thread workloads (read https://github.com/microsoft/mimalloc#performance https://github.com/microsoft/mimalloc#performance): "The larson server workload allocates and frees objects between many threads. Larson and Krishnan [2] observe this behavior (which they call bleeding) in actual server applications, and the benchmark simulates this. Here, mimalloc is more than 2.5× faster than tcmalloc and jemalloc due to the object migration between different threads. This is a difficult benchmark for other allocators too where mimalloc is still 48% faster than the next fastest (snmalloc)."
Veedrac 7y ago
There are a lot of ways to write the same story; Mimalloc has a few innovations of its own, has good benchmarks to justify them, and the paper is a very good read. In particular, Mimalloc works to increase data locality, by using per-‘page’ (64kB memory blocks) free queues. All this with a codebase almost a tenth the size of jemalloc, and it's looking very promising.
trianglesphere 7y ago
It's a little hidden, but this is out of MS research, and seems to be initially designed for ref-counted scripting languages. I'm not really sure how much they focused on multi-threaded stuff. >We present mimalloc, a memory allocator that effectively balances these demands, shows significant performance advantages over existing allocators, and is tailored to support languages that rely on the memory allocator as a backend for reference counting. https://www.microsoft.com/en-us/research/publication/mimalloc-free-list-sharding-in-action/ https://www.microsoft.com/en-us/research/publication/mimallo...
- Veedrac 7y ago
  That's not what the quote means, really. They have best-in-class performance on both single- and multi-threaded workloads. It is just saying that the allocator supports a deferred_free callback, which is zero-overhead in the fast path and negligible overhead in the slow path.
bakery2k 7y ago
What if I'm writing code that's strictly single-threaded? Presumably malloc could be simpler and/or faster in this special case? Is there a production-ready allocator that's optimized for single-threaded use?
- gok 7y ago
  It's very hard to not accidentally pull in a dependency that makes your code multithreaded.
  - 01100011 7y ago
    You guys could argue this all day and both be right. Depending on what type of system you're working on, you are either very likely to pull in a multithreaded dependency or you are not. Systems programming is different from game programming is different from web client programming is different from kernel development. In most of my career, I would have never accidentally pulled in a multithreaded dependency, but I could see how that could be easy to do in some cases.
- imtringued 7y ago
  It is already faster because there is no lock congestion.
- rurban 7y ago
  For this use case a good copying collector would be best. Beats any malloc by miles.
pizlonator 7y ago
This allocator appears to have some genuinely interesting things in its multi thread support: - it looks like it avoids atomics on common cases of malloc and free. That’s a big deal and not all malloc a accomplish that. - it looks like it has cleverness specifically for the case that one thread frees an object into another thread’s heap. It seems like this case was given some special consideration - in particular avoiding the need for the thread that owns the heap to stop or synchronize at the moment that happens even though that thread is non-atomically allocating and freeing in that same heap. So, it’s always easy to sound smart by saying that a field is well explored - but it looks like this thing actually has some cool new ideas in it.
- gpderetta 7y ago
  >it looks like it avoids atomics on common cases of malloc and free. That’s a big deal and not all malloc a accomplish that. Many mallocs implementations try to avoid one cache per thread because it can waste a huge amount of memory in applications with thousands of threads opting for per cpu pools or similar solutions. These solutions help with contention but still require atomics (unless using something like restartable sequences). It is a trade-off, but for applications that use one thread per cpu, completely private free lists can branch win of course.
  - emeryberger 7y ago
    All modern allocator implementations I am aware of (including Hoard and Mesh) use per-thread caches (of a limited size), and thus avoid the use of atomic operations in the common case while also avoiding blowup (wasted memory caused by using a memory allocator that "leaks" -- see the Hoard paper (ASPLOS 2000, https://people.cs.umass.edu/~emery/pubs/berger-asplos2000.pdf https://people.cs.umass.edu/~emery/pubs/berger-asplos2000.pd...) for a full discussion).
    - pizlonator 7y ago
      Does hoard avoid atomic ops on the common case of both malloc and free?
Quekid5 7y ago
Andrei Alexandrescu had a great talk[0] on allocators and this convinced me that if you really care about allocator performance[1] what you need is a tunable and composable system. The whole idea of how and when (runtime/compile-time) to choose the appropriate allocator is also interesting. [0] https://www.youtube.com/watch?v=LIb3L4vKZ7U https://www.youtube.com/watch?v=LIb3L4vKZ7U [1] I suppose there's a digression to be had here about allocation being trivial and RAII-style deallocation not really being deterministic, but...
jasonwatkinspdx 7y ago
You should actually read the technical report: https://www.microsoft.com/en-us/research/uploads/prod/2019/06/mimalloc-tr-v1.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... This has some quite clever and very carefully considered details around concurrency. > in the end this is a very well-explored area and there's basically a single stable point once all common scenarios are considered. I think it's absurd to call allocation a solved problem where there's one known optimal design.
yason 7y ago
but in the end this is a very well-explored area With a lot of interesting new generic allocators that beat the competition hands down popping up in the last 10 years, I'd dare to claim the area is not very well explored. It has indeed been explored a lot but it seems that there's still low-hanging fruit. Every few years someone writes an allocator that makes significant improvements over the previous generation implementations. I love to see such action on "solved problems".
plietar 7y ago
You may want to look at snmalloc, another allocator we did at Microsoft Research. It specifically targets these producer / consumer scenarios. https://github.com/microsoft/snmalloc https://github.com/microsoft/snmalloc And the paper, which I’ll be presenting tomorrow at ISMM: https://github.com/microsoft/snmalloc/blob/master/snmalloc.pdf https://github.com/microsoft/snmalloc/blob/master/snmalloc.p...

fwip 7y ago

The benchmarks are very impressive! I am excited to read through this code and think on it. Edit: They do mention they're all from AMD's EPYC chip, which is a little idiosyncratic. Speculation: perhaps page locality is more important on this architecture.

the_duke 7y ago
The benchmark repo contains results with a Intel Xeon. Looks roughly similar: https://github.com/daanx/mimalloc-bench https://github.com/daanx/mimalloc-bench

m0zg 7y ago

The important thing about all this is to measure perf on realistic workloads before and after. I don't really believe in allocators that have "excellent performance" on everything.

longcommonname 7y ago

Just a general question in regards to using memory allocators, in the consideration of a C only application. The problems I encounter with allocator and heap manager are almost never solved by these types of frameworks. These problems include: 1. Improper usage of the memory returned that contradict implementation. 2. Pool allocators that don't have separation between individual blocks (performance reasons). 3. Specifying the lifetime of the memory to a thread or until specific events happen. 4. Difficult to diagnose corruption, with any tool available. Here's a specific scenario I deal with very often: There are N persistent worker threads. These worker threads have their own pool of memory, and prior to getting work we know this pool is clean. After the work is finished and before more work is recieved the memory is cleaned. Any excess requested memory is returned to the global-pool, and any memory that is "unmanaged" is dealt with properly. This means that people can do whatever heap management call you use (void * obtainMemory(size_t);) in the scope of business logic without having to worry about infrastructure concerns. Having a faster malloc/calloc doesn't benefit me as much as making the usage of memory easier, and the understanding of what happens easier.

shereadsthenews 7y ago

I always find comparisons with tcmalloc hard to parse, since it has a million knobs and the defaults are terrible. If they are running with 16 threads I would normally advise increasing the thread cache size far above the default 3MiB. also interesting would be jemalloc in per-CPU mode. As always the thing to do is build and run your own workload and see the results.

brian_herman__ 7y ago

I should create memealloc which converts all memory allocations to base64 encoded gifs

Iwan-Zotow 7y ago
with cats and unicorns inside

c-smile 7y ago

Looks like the same idea as Konstantin Knizhnik's thread_alloc: http://www.garret.ru/threadalloc/readme.html http://www.garret.ru/threadalloc/readme.html At least the same architecture of allocated chunks management.

PieUser 7y ago

they should not have tested on AWS

john-aj 7y ago

I never like names that require a “pronounced like” note, but cool project regardless.

simias 7y ago
Given the rather unpredictable nature of English pronunciation that's basically required for any made up word.
- jing 7y ago
  Particularly since it would not be unreasonable to assume that the "mi" in mimalloc is incorrectly pronounced like the "mi" in Microsoft.
emmelaich 7y ago
Cool fact - I'd bet that no one pronounces MySQL like its author does.
imtringued 7y ago
That's what happens when languages like English adopt the foreign pronunciation of words instead of the English pronunciation. Now everything is an edge case and you can't be sure of the pronunciation even if it's an English word.

danlark 7y ago

We tried mimalloc in ClickHouse and it is two times slower than jemalloc in our common use case https://github.com/microsoft/mimalloc/issues/11 https://github.com/microsoft/mimalloc/issues/11

MaxBarraclough 7y ago
To be clear, your program ran at half speed, right? That's far worse than doubling the time spent in memory-management functions.
- danlark 7y ago
  Yes, our program ran at half speed.
- vinay_ys 7y ago
  It is quite bad if changing the allocator made your program run at half speed. It doesn't matter if the library itself consumed more CPU or caused more wait (guessing that's the case here) due to concurrency or excessive syscalls.
deleted 7y ago
[deleted]
danlark 7y ago
The developer helped us a lot to improve the speed and now it is almost at the same level as jemalloc for us

nh2 7y ago

Are there functions available with which I can at run-time query how much OS memory is used, how much handed out in allocations, how many mmap()ed pools are used, and so on? I find that one of the most important features of a malloc library to debug memory usage. glibc has these functions (like malloc_info()) -- they are very bugged in that they return wrong results, but after patching them to be correct, they are super useful.

jasonzemos 7y ago
Any more info/link on how they are incorrect and the patches you need to fix them?
- nh2 7y ago
  Sure, my patches are linked in the bugs I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=24026 https://sourceware.org/bugzilla/show_bug.cgi?id=24026 - "malloc_info() returns wrong numbers" https://sourceware.org/bugzilla/show_bug.cgi?id=21556 https://sourceware.org/bugzilla/show_bug.cgi?id=21556 - "malloc_stats printing size_t fields as unsigned int" If you're interested in this topic: After finding one bug after the other due to 32-bit integer overflow in malloc.c, I just searched for "unsigned int" in that file for fun, and 30 seconds later found what I consider a security vulnerability in realloc(): https://sourceware.org/bugzilla/show_bug.cgi?id=24027 https://sourceware.org/bugzilla/show_bug.cgi?id=24027 In certain situations, if you realloc() e.g. 32G + 5 bytes (reallocs this large can happen in large programs e.g. for data analysis), it'll copy only 5 bytes, and leave the rest as memory garbage. That experience taught me that open source code being old doesn't mean anybody ever read it.
  - rurban 7y ago
    pt2malloc is only maintained by glibc, but not really. Since they cannot maintain it, they want to get rid of it. The upstream maintainer released a better version pt3malloc, which glibc refused to adopt. It needs one more word per alloc.
ndesaulniers 7y ago

civility 7y ago

Is anyone aware of a good/fast single threaded allocator for cases where you don't need/want to pay for thread safety?

deleted 7y ago
[deleted]
kllrnohj 7y ago
If you're single threaded then you'll never have mutex contention so they'll always be fast-path. I'd suggest you actually prove that the memory barriers are actually a problem for you via profiling, since it's somewhat unlikely it is.
- adwn 7y ago
  > If you're single threaded then you'll never have mutex contention so they'll always be fast-path. Concurrent algorithms (to which multi-thread capable allocators belong) typically necessitate design and performance compromises which aren't nullified by creating only a single thread. > I'd suggest you actually prove that the memory barriers are actually a problem for you via profiling, since it's somewhat unlikely it is. civility's reply to your post is somewhat rude, but they're right. It's rather arrogant to assume that the poster doesn't know what they're doing, without knowing anything about their specific problem. Modern allocators are complex pieces of software, typically with a lot of knobs and dials, and it is entirely plausible that an allocator tuned for single-threaded programs is more performant for a specific use case than a generic multi-thread allocator.
  - civility 7y ago
    > civility's reply to your post is somewhat rude Not as rude as I wanted to be. I expect answers like that from Stack Overflow or Reddit - just another condescending ego play without actually addressing the question. Regardless, thank you for your reply. I don't suppose you know a good single-threaded (or share-nothing across threads) allocator worth looking at?
  - 7y ago

tuananh 7y ago

the redis benchmark is interesting! Maybe antirez can make sth out of it

ksec 7y ago

The Dev at Discourse also try it with Ruby, the result aren't as good as jemalloc. [1] [1] https://twitter.com/samsaffron/status/1143048590555697152 https://twitter.com/samsaffron/status/1143048590555697152