[PATCH v3 0/5] malloc: tcache improvements

[Cupertino Miranda]

Hi Wilco,

Thank you for those numbers.
This is sort of surprising to me. I need to execute this myself.

I know the basics for executing the benchtests, like calling:
   make bench BENCHSET="malloc-thread"
But am not so familiar on how to collect the data for multiple runs and 
further comparisons.
I had a quick read through the README file, but does not mention how to 
get result comparisons.

Maybe you can point me out to some page with documentation, or some 
basic commands that would collect the data.

Thanks once again for the results.

Regards,
Cupertino

On 05-03-2025 19:00, Wilco Dijkstra wrote:
> Hi Cupertino,
> 
> As I've been looking at various malloc patches, I decided to benchmark this as well.
> 
> The results are as follows for taking best of 3 runs on Neoverse V2 vs current trunk:
> 
> patches 1-3:
> 
> bench-malloc-thread 1:  6.0% slowdown
> bench-malloc-thread 32: 2.6% slowdown
> 
> bench-malloc-simple (ST case): 1.9% - 2.7% slowdown
> bench-malloc-simple (MT case): 1.8% speedup
> bench-malloc-simple (thread arena): 0.2% speedup
> 
> The slowdowns are due to the changes in pointer swizzling - it's not obvious why
> there is a speedup in the multithreaded path (I guess it uses tcache_get/put in a loop
> so that the if-statement cannot be optimized out unlike in the fast path), but the main
> slowdowns are in the critical tcache fast paths. Note the overhead of curent pointer
> swizzling is around 3%/1.6%/0.8% so it almost doubles the overhead in the ST case.
> 
>   
> patches 1-4:
> 
> bench-malloc-thread 1:  34.9% slowdown (!!!)
> bench-malloc-thread 32: 32.1% slowdown (!!!)
> 
> bench-malloc-simple (ST case): 10.9% - 12.5% slowdown
> bench-malloc-simple (MT case): 8.4% slowdown
> bench-malloc-simple (thread arena): 7.4% slowdown
> average slowdown 8.9%
> 
> As I suspected, the extra code has a significant negative effect on the tcache
> fast paths. A way forward might be to first split into small/large block sizes and
> only handling small sizes inline in the entry point of malloc and free.

> 
> Cheers,
> Wilco