This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][malloc] Avoid atomics in have_fastchunks
On 2017.09.19 at 17:30 -0400, DJ Delorie wrote:
>
> Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
> > An alternative would be to move all the fastbin handling into the
> > t-cache - but then I bet it's much easier just to write a fast modern
> > allocator...
>
> tcache is a type of fastbin already. I tested removing fastbins since
> tcache did something similar, but it turns out that doing both tcache
> and fastbins is still faster than doing just either.
>
> Many have said "just replace glibc's malloc with a fast modern
> allocator" but glibc's malloc is about as fast as a modern allocator
> now, and what we're lacking is a way to *prove* a new malloc is faster
> for all the use cases glibc needs to cater to. I posted a note about
> the trace-enabled glibc hoping that folks would start collecting the
> workloads we want to benchmark. Having a large library of
> benchmark-able things is somewhat of a prerequisite before we worry
> about "which malloc is faster for glibc's audience".
The reason why nobody uses your trace/simulation patches is because they
generate way too much data and are just too complex/invasive for most
users. And someone would have to analyze all this data.
So it is natural to look for other metrics like code complexity instead.
--
Markus