[PATCH 2/2] Add single-threaded fast path to rand()

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Wed Mar 20 12:31:44 GMT 2024



On 19/03/24 12:44, Wilco Dijkstra wrote:
> Hi Cristian,
> 
>> So the generalized lock-omitting code in __libc_lock_lock didn't
>> flew..
> 
> There were some comments on it. One issue is that it would affect
> practically every lock in GLIBC, thus adding code and branches even for
> locks that don't benefit from single-threaded optimization.
> 
> Hence the idea of first sorting out rand() since it is a frequent performance
> complaint (unfortunately).

I don't have a strong opinion on this rand patch, if this idea is to
have it as an workbench for a possible single-thread lock optimization
it should be fine.  It is just that I don't see much gain in optimizing
such a bad interface (although we still lack a proper userland PRNG).

> 
>> what a new fast path macro function like (sorry I suck at
>> naming things) __libc_maybe_lock_lock that only locks if not single
>> thread ?
> 
> Yes despite the huge mess of locking macros in use, adding a new set of
> macros may be better overall. We could say that the critical section must not
> create a new thread itself. This means we can avoid checking the lock value
> and compile the lock macro like:
> 
> #define __libc_fast_lock(NAME) if (SINGLE_THREAD_P || !__libc_lock_lock (NAME)) {

This sounds reasonable, maybe we use a static inline instead to enforce the
lock type (not sure if this really required).


More information about the Libc-alpha mailing list