Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118018
Message-ID: <64f0b7c5-6b51-2607-53cb-c292ab3a6dc7@bastelstu.be>
Date: Mon, 20 Jun 2022 17:40:06 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 Go Kudo <g-kudo@colopl.co.jp>
Cc: PHP Internals List <internals@lists.php.net>
References: <CAMs36HcGzvwwTTU+nUO+U_M6o4qpOAHES7RbHEJWm6iot+-9=Q@mail.gmail.com>
 <CAOWwgp=t93i6j=hOQ+z1swoRKDh7Ay5-ty=31pEv84y5rhbekg@mail.gmail.com>
In-Reply-To: <CAOWwgp=t93i6j=hOQ+z1swoRKDh7Ay5-ty=31pEv84y5rhbekg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension Improvement
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 6/20/22 16:57, Nicolas Grekas wrote:
> I'm wondering: does Random\SerializableEngine extend Random\Engine? Can
> this be mentioned in the RFC? If not, what about making it this way? Having
> this interface only contain __(un)serialize would look strange to me, aka
> too broad for the name and the purpose.

Yes, it does. All the other interfaces extend Random\Engine as well. See 
the stub at:

https://github.com/colopl/php-src/blob/upstream_rfc/scoped_rng_for_pr/ext/random/random.stub.php

> I'm also wondering: is CombinedLCG worth it? I must admit I don't know when
> I should use it instead of MT19937.

If the RFC passes you really should use neither:

- CombinedLCG: That's a horrible RNG, that is implemented for backwards 
compatibility with the existing functionality.
- MT19937: That one is not quite as horrible, but it comes with 2.5kB of 
state. It's also implemented for backwards compatibility with the 
existing RNGs (it's what backs rand() and mt_rand()).

Use 'Secure', you can't do anything wrong with that and that's why it's 
the default for the Randomizer.

If you need performance or if you need support for seeding then either 
use PCGOneseq128XslRr64 or Xoshiro256StarStar (depending on whether the 
latter makes it into the extension).

> Since the names are all super opaque to many of us, documentation should be
> very clear about the use case of each implementation... (if can reduce the
> number of implementations, that's even better :) )

Regarding the names: Yes, they are opaque, but will become a little less 
opaque if the extension RFC passes, because then the names will refer to 
a very specific implementation of standard RNGs, making them Googleable.

For Xoshiro256StarStar the upstream documentation is here:

https://prng.di.unimi.it/

For PCGOneseq128XslRr64 the upstream documentation is here:

https://www.pcg-random.org/

But I agree that the documentation should help the user make an educated 
choice.

Best regards
Tim Düsterhus