[PATCH v5 2/7] malloc: optimize initialization

[Cupertino Miranda]

Hi Wilco,

Obviously, disabling ASLR brought nothing useful.
I have collected the data this time with 50 runs per test.
Still continue to get some strange performance variations.
Tried to run the same tests on my Apple M1 in native linux, but 
mimalloc-bench is failing to build for ARM. :(

I adapted the mimalloc scripts to be able to plot the data from multiple 
runs and have collected it with the same tools as mimalloc-bench does.
It is capable to generate PNG, PDF and HTML charts.
Considering the number of tests PNG and PDF version seem useless, but 
the HTML is nice since it has some javascript to zoom and pan on the chart.

Now, the columns on the chart match the patches.
Hope this makes it easier to understand the results.

Cheers,
Cupertino

On 21-03-2025 16:56, Cupertino Miranda wrote:
> Hi Wilco,
> 
> This is one of the changes which might bring actually 0 effect since the 
> compiler could be already making the proper decision.
> In my chart it is the comparison between patch2 and patch3 columns.
> 
> I cannot believe on the variation between those runs. Please notice I 
> executed the benchmark with my machine in full idle, killed xorg, etc.
> 
> Now that I think about it, maybe I need to disable Address Space Layout 
> Randomization (ASLR) (setting /proc/sys/kernel/randomize_va_space to 0).
> This might justify the variation.
> 
> Will run all benchmark with it set to 0.
> 
> Cheers,
> Cupertino
> 
> 
> On 21-03-2025 15:59, Wilco Dijkstra wrote:
>> Hi Cupertino,
>>
>>> This patch adds __glibc_unlikely to all conditions related to the call
>>> to ptmalloc_init which check if __malloc_initialized variable is set.
>>
>>> -  if (!__malloc_initialized)
>>> +  if (__glibc_unlikely (!__malloc_initialized))
>>>       ptmalloc_init ();
>>
>> What difference did you see as a result (not sure whether it is in 
>> your graph)?
>> I benchmarked it against current trunk, and there is no difference in 
>> generated
>> code of all the key malloc/free functions. There are some improvements 
>> in less
>> frequently used functions, so it looks worthwhile, but I'd like to 
>> understand the
>> reasoning behind it.
>>
>> Note in my __libc_malloc patch I moved this initialization after the 
>> tcache code.
>> The same could be done in several other cases. Moving it gives large 
>> gains
>> since you avoid doing unnecessary work before the tcache code.
>>
>> Cheers,
>> Wilco
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250327/d94e2da2/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memory.png
Type: image/png
Size: 66689 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250327/d94e2da2/attachment-0002.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250327/d94e2da2/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: time.png
Type: image/png
Size: 84386 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250327/d94e2da2/attachment-0003.png>