This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GLIBC][PATCH] Remove strcmp inlines



On 12/12/2016 11:31, Zack Weinberg wrote:
> On Mon, Dec 12, 2016 at 7:48 AM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 12/12/2016 10:40, Zack Weinberg wrote:
>>> I'm inclined to say that the strcmp expansion should stick around
>>> until after it _is_ added to GCC.
>>
>> But I hardly see this as a performance hotstop for any significant workload,
>> but rather as a microptimization that has driven string2.h creation as a
>> whole.
>>
>> Also the idea is to avoid rely on specific libc implementation to actually
>> get these kind of optimization (if it is worth).
> 
> I'd agree with this if we were talking about a new addition to
> string2.h - those should be justified by something beyond just
> optimization.  (For instance, the explicit_bzero inline is a partial
> mitigation for the problem with variables whose address otherwise
> wouldn't be taken.)
> 
> With an _existing_ string2.h microoptimization though, I think we need
> to be able to argue that it is too infrequently used to be worth it
> (e.g. strdup) or that it's been subsumed by compiler optimizations.
> Long lists of short strcmp() operations are very common.
> 
> zw

I tend to agree with your rationale, however tying remove existing 
string2.h microoptimization with compiler support one can argue that
we still need to support old compiler and then it will require multiple 
releases to actually remove such code.

But my idea is these kind of optimization should not have been added
in glibc in first place: there are often misleading since user are not
really aware of its application unless he actually reads the headers
or check the pre-compiled code and mostly are actually only applied
for GNU compilers.

Also, I highly doubt this specific optimization was added with some
specific workload in mind and I think even if a real workload have
this specific snippet as hotspot it will highly have performance
issues with different compiler/libcs usage (which is another
side-effect I would like to minimize by removing all the string2.h
snippets).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]