This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Single threaded stdio optimization
On 30/06/2017 10:16, Carlos O'Donell wrote:
> On 06/30/2017 08:15 AM, Szabolcs Nagy wrote:
>> i didn't dig into the root cause of the regression (or
>> why is static linking slower?), i would not be too
>> worried about it since the common case for hot stdio
>> loops is in single thread processes where even on x86
>> the patch gives >2x speedup.
>
> Regardless of the cause, the 15% regression on x86 MT performance
> is serious, and I see no reason to push this into glibc 2.26.
> We can add it any time in 2.27, or the distros can pick it up with
> a backport.
>
> I would like to see a better characterization of the regression before
> accepting this patch.
>
> While I agree that common case for hot stdio loops is non-MT, there
> are still MT cases, and 15% is a large double-digit loss.
>
> Have you looked at the assembly differences? What is the compiler
> doing differently?
>
> When our a user asks "Why is my MT stdio 15% slower?" We owe them an
> answer that is clear and concise.
>
Just a wild guess, but might some overhead due on x86_64 the internal
locks will now unnecessary check for single-thread case (the
__lll_lock_asm_start [1] snippet). Did you try by using the simple
variant, without the check for __libc_multiple_threads?
[1] ./sysdeps/unix/sysv/linux/x86_64/lowlevellock.h