Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116023
MIME-Version: 1.0
References: <CABTDVhBRpD=nWBk2xGLEmdcWwOzCeqGeqH5vLSugPFOeEN9Mog@mail.gmail.com>
 <CAF+90c-j84_gXvnChewQoJbHnGLWgcHfszp=GgFF8_sAaPahdA@mail.gmail.com>
In-Reply-To: <CAF+90c-j84_gXvnChewQoJbHnGLWgcHfszp=GgFF8_sAaPahdA@mail.gmail.com>
Date: Thu, 9 Sep 2021 13:30:58 +0900
Message-ID: <CABTDVhCuVCCpH5Agu6ozDEcuj8_z4=xB81VVtme+0CDXOxN10A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c9cd8105cb8877b5"
Subject: Re: [PHP-DEV] [RFC] Random Extension 3.0
From: zeriyoshi@gmail.com (Go Kudo)

--000000000000c9cd8105cb8877b5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Nikita, sorry for the late reply.

This is a difficult problem. For now, MT19937 is left for compatibility. In
other words, if you don't need compatibility, there is no benefit to using
it.

What about implementing both a new MT and a compatible MT? A compatible MT
would have the following signature

```php

use Random\NumberGenerator\Numbergenerator;

/* for legacy compatibility */
class MT19937 implements NumberGenerator
{
    public function __construct(int $mode =3D MT_RAND_MT19937, int $seed) {=
}
}

/* a new implementation */
class MersenneTwister implements NumberGenerator
{
    public function __construct(int $seed) {}
}
```

I had originally removed the MT_RAND_PHP implementation on the grounds that
legacy implementations should not be retained, but if the regular Mersenne
twister is to be retained for compatibility, I think it should be as well.

Also, maybe we should opt for a more SIMD friendly RNG.

Regards,
Go Kudo

2021=E5=B9=B49=E6=9C=887=E6=97=A5(=E7=81=AB) 17:28 Nikita Popov <nikita.ppv=
@gmail.com>:

> On Thu, Sep 2, 2021 at 5:10 PM Go Kudo <zeriyoshi@gmail.com> wrote:
>
>> Hi Internals.
>>
>> Expanded from the previous RFC and changed it to an RFC that organizes t=
he
>> whole PHP random number generator. Also, the target version has been
>> changed to 8.2.
>>
>> https://wiki.php.net/rfc/rng_extension
>> https://github.com/php/php-src/pull/7453
>>
>> Hopefully you will get some good responses.
>>
>
> This RFC currently tries to keep some semblance of compatibility with the
> existing mt_rand() algorithm by retaining the same implementation for
> mapping the raw random number stream into a range. However, the algorithm
> we use for that is not exactly state of the art and requires two full-wid=
th
> divisions at minimum. There are more efficient scaling algorithms based o=
n
> fixed-point multiplication, which are "nearly divisionless" (
> https://arxiv.org/pdf/1805.10941.pdf). The variant at
> https://github.com/apple/swift/pull/39143 is entirely divisionless.
>
> Doing this would improve performance (though I'm not sure by how much --
> maybe once we add up our call overhead, it isn't important anymore?) but =
it
> would provide a different sequence than mt_rand(). Something we might wan=
t
> to consider.
>
> Regards,
> Nikita
>

--000000000000c9cd8105cb8877b5--