Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116213
MIME-Version: 1.0
References: <CABTDVhBRpD=nWBk2xGLEmdcWwOzCeqGeqH5vLSugPFOeEN9Mog@mail.gmail.com>
 <CAF+90c-j84_gXvnChewQoJbHnGLWgcHfszp=GgFF8_sAaPahdA@mail.gmail.com> <CABTDVhCuVCCpH5Agu6ozDEcuj8_z4=xB81VVtme+0CDXOxN10A@mail.gmail.com>
In-Reply-To: <CABTDVhCuVCCpH5Agu6ozDEcuj8_z4=xB81VVtme+0CDXOxN10A@mail.gmail.com>
Date: Mon, 4 Oct 2021 12:24:19 +0200
Message-ID: <CAF+90c99Z=J7Qwbd_B+VeyaM5p9RfqzxwBvCVJiEZDtcKhAmGg@mail.gmail.com>
To: Go Kudo <zeriyoshi@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d0585a05cd845113"
Subject: Re: [PHP-DEV] [RFC] Random Extension 3.0
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000d0585a05cd845113
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 9, 2021 at 6:31 AM Go Kudo <zeriyoshi@gmail.com> wrote:

> 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 M=
T
> 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 b=
e
> as well.
>
> Also, maybe we should opt for a more SIMD friendly RNG.
>

To clarify, what I had in mind here is not the MT generator itself, but the
scaling done in Random::getInt(). This scaling is independent of the used
source. So while the raw numbers generated by
Random\NumberGenerator\MT19937 would be the same as before, the result
produced by Random::getInt() with this source wouldn't be.

Regards,
Nikita


> 2021=E5=B9=B49=E6=9C=887=E6=97=A5(=E7=81=AB) 17:28 Nikita Popov <nikita.p=
pv@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
>>> the
>>> 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 th=
e
>> existing mt_rand() algorithm by retaining the same implementation for
>> mapping the raw random number stream into a range. However, the algorith=
m
>> we use for that is not exactly state of the art and requires two full-wi=
dth
>> divisions at minimum. There are more efficient scaling algorithms based =
on
>> 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 wa=
nt
>> to consider.
>>
>> Regards,
>> Nikita
>>
>

--000000000000d0585a05cd845113--