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 = 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年9月7日(火) 17:28 Nikita Popov <nikita....@gmail.com>:
> On Thu, Sep 2, 2021 at 5:10 PM Go Kudo <zeriyo...@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 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-width
> 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 want
> to consider.
>
> Regards,
> Nikita
>
