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

["Cristian Rodríguez" <cristian@rodriguez.im>]

On Thu, Mar 21, 2024 at 4:39 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Adhemerval Zanella Netto:
>
> > On 20/03/24 11:18, Cristian Rodríguez wrote:
> >> On Wed, Mar 20, 2024 at 9:31 AM Adhemerval Zanella Netto
> >> <adhemerval.zanella@linaro.org> wrote:
> >>
> >>
> >>> 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).
> >>
> >> Yeah, it should be no surprise this interfaces are bad,
> >> I thought this was common knowledge.
> >>
> >> we need something like https://github.com/C2SP/C2SP/blob/main/chacha8rand.md
> >> which prety much outperforms even non-CS algorithms in at least 64 bit x86.
> >> but the question of the state remains.global? TLS? how to discard it
> >> in all the appropriate occasions?
> >
> > And this is the arc4random in userspace discussion all over again.
>
> Agreed.  But what has changed that we know now that Linux won't provide
> us with vDSO acceleration for arc4random.  So I think it wouldn't be
> unreasonable to roll our own.  Right now, the switch to arc4random
> provided by glibc is a massive performance regression compared to other
> implementations.


Afaik the other path that hasn't been tried is rseq no ? could the
kernel provide a random state this way that it is cleared on the right
conditions..