[PATCH 2/2] Add single-threaded fast path to rand()
Florian Weimer
fweimer@redhat.com
Thu Mar 21 07:39:21 GMT 2024
* 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.
Thanks,
Florian
More information about the Libc-alpha
mailing list