Re: [9front] [PATCH] libc: replace lrand's algorithm

[Ori Bernstein <ori@eigenstate.org>]

On Wed, 03 Apr 2024 11:07:22 +0200
qwx@sciops.net wrote:

> I think at this point it would be better to look at a patch, with the
> changes mentioned after the first post, and a sweep through the other
> implementations.  There are some odd occurrences as you found; libc's
> frand() is also somewhat suspect but will likely need to change if
> lrand() does.  We need a 16bit, 32bit, floating point, and possibly
> 64bit variant; this will clean up some code and remove some
> redundancies which is always nice.  Perhaps take the extreme route and
> do *all* of the changes you'd like to see, so we could more easily
> discuss each case.  We then need to check if there's a performance
> impact on non-amd64 arches.  For xoroshiro128+ vs.  pcg I'd be
> interested to know if there's any significant difference between the
> two in statistical properties and performance; if we make a change,
> it'd be nice to pick the best alternative and make it once and for
> all.  Code size and simplicity also counts.  Is there any other
> variant that should be assessed?

Performance for this RNG is, tbh, pretty uninteresting, at
least for any of the options under consideration. All of them
are good.

Better statistical properties, smaller and cleaner code, are
both good reasons to change this, and I'd be happy to take
a correct patch to improve that.

It's not an urgent need -- anything that strongly depends
on the statistical properties of a random stream should
possibly consider a CSPRNG -- but it's nice to have.

Another question here: Would it be sensible to just ditch
all of this tomfoolery with "good enough" randomness, and
just move to a seedable CSPRNG?