Hey,

32-bit Mt19937 random number Generator is default in Phobos.
It is default in Mir too, except that 64-bit targets use 64-bit Mt19937 instead.

The last Mir Random beta improves performance for Mt19937.

The goal was to:

1. Improve RNG generation performance by making code more friendly for CPU pipelining. Tempering (finalization) operations was mixed with internal payload update operations.

2. Reduce number of required comparison operations using unification with add/sub operations. The order of payload iteration was reversed (the engine generates the same numbers as before).

3. Reduce memory access twice both for generation (required for 1) and initialization. This will make the algorithm more cache-friendly for real world applications. Ditto (1)

Bench results:
----
mir.random 32-bit Mt19937:
    6.80851 Gb/s

mir.random 64-bit Mt19937:
   12.5984 Gb/s

std.random 32-bit Mt19937:
   4.41989 Gb/s

std.random 64-bit Mt19937:
    wrong initialization and tempering (finalization)
----
54%: 1.54 = 6.80851 / 4.41989
185%: 2.85 = 12.5984 / 4.41989

The benchmark can be found here:
https://github.com/libmir/mir-random/blob/master/bench/Mt19937_bench.d

Ads:
We are looking for new contributors and partners! Star and contribute!

https://github.com/libmir :

 - mir - Generic numeric library
 - dcv - D Computer Vision library
 - mir-glas - Linear Algebra Subprograms (written in D)
 - mir-random - random numbers generators, includes non-uniform distributions.
 - mir-cpuid - CPU identification

Future:
 - mir-runtime - lightweight always inlined `nothrow @nogc` Dlang Runtime
 - mir-neural - neural network library [WIP]
 - mir-fft - Fast and multidimensional FFT
 - mir-svm - support vector machines

Cheers,
Ilya & Mir Team

On 11/26/16 11:31 AM, Ilya Yaroshenko wrote:
> Hey,
>
> 32-bit Mt19937 random number Generator is default in Phobos.
> It is default in Mir too, except that 64-bit targets use 64-bit Mt19937
> instead.
>
> The last Mir Random beta improves performance for Mt19937.
>
> The goal was to:

Congrats! Also thanks for using the Boost license which would allow backporting the improvements to Phobos. Who'd be up for it?

Also I'm thinking of removing std.random's dependency on druntime, e.g. by removing the uses of enforce. Thoughts?

Andrei

On Saturday, 26 November 2016 at 20:13:36 UTC, Andrei Alexandrescu wrote:
> On 11/26/16 11:31 AM, Ilya Yaroshenko wrote:
>> Hey,
>>
>> 32-bit Mt19937 random number Generator is default in Phobos.
>> It is default in Mir too, except that 64-bit targets use 64-bit Mt19937
>> instead.
>>
>> The last Mir Random beta improves performance for Mt19937.
>>
>> The goal was to:
>
> Congrats! Also thanks for using the Boost license which would allow backporting the improvements to Phobos. Who'd be up for it?

Yep, I am using Phobos parts and we can do backports. In other hand it is requires efforts (I have experience with ndslice, and I will be happy to remove ndslice from Mir after LDC 1.2.0 release).

> Also I'm thinking of removing std.random's dependency on druntime, e.g. by removing the uses of enforce. Thoughts?
>
> Andrei

Another one DRuntime dependency is core time.

BTW, I would be happy to have core.time + std.datetime as unified nothrow @nogc library without DRuntime dependency (ahah, it is BetterC propaganda!)

Ilya

On Saturday, 26 November 2016 at 20:13:36 UTC, Andrei Alexandrescu wrote:
> Also I'm thinking of removing std.random's dependency on druntime, e.g. by removing the uses of enforce. Thoughts?

There's no strong reason for those checks to be done via `enforce` except for a design decision that user input should be treated as external input.  The user is in complete control of those parameters, there's no reason they can't be `assert` checks.

On Saturday, 26 November 2016 at 16:31:40 UTC, Ilya Yaroshenko wrote:
>
> https://github.com/libmir :
>
>  - mir - Generic numeric library
>  - dcv - D Computer Vision library
>  - mir-glas - Linear Algebra Subprograms (written in D)
>  - mir-random - random numbers generators, includes non-uniform distributions.
>  - mir-cpuid - CPU identification
>
> Future:
>  - mir-runtime - lightweight always inlined `nothrow @nogc` Dlang Runtime
>  - mir-neural - neural network library [WIP]
>  - mir-fft - Fast and multidimensional FFT
>  - mir-svm - support vector machines
>
> Cheers,
> Ilya & Mir Team

How does a mir-lapack fit in to the plan going forward?

On Sunday, 27 November 2016 at 02:28:06 UTC, jmh530 wrote:
> On Saturday, 26 November 2016 at 16:31:40 UTC, Ilya Yaroshenko wrote:
>>
>> https://github.com/libmir :
>>
>>  - mir - Generic numeric library
>>  - dcv - D Computer Vision library
>>  - mir-glas - Linear Algebra Subprograms (written in D)
>>  - mir-random - random numbers generators, includes non-uniform distributions.
>>  - mir-cpuid - CPU identification
>>
>> Future:
>>  - mir-runtime - lightweight always inlined `nothrow @nogc` Dlang Runtime
>>  - mir-neural - neural network library [WIP]
>>  - mir-fft - Fast and multidimensional FFT
>>  - mir-svm - support vector machines
>>
>> Cheers,
>> Ilya & Mir Team
>
> How does a mir-lapack fit in to the plan going forward?

LAPACK API will be a part of Mir GLAS
https://github.com/libmir/mir-glas --Ilya

On Saturday, 26 November 2016 at 20:13:36 UTC, Andrei Alexandrescu wrote:
>
> Congrats! Also thanks for using the Boost license which would allow backporting the improvements to Phobos. Who'd be up for it?
>
> Also I'm thinking of removing std.random's dependency on druntime, e.g. by removing the uses of enforce. Thoughts?
>
> Andrei

Without druntime, global ctor/dtor and TLS can't be used too.
Besides nothrow @nogc, std.random relies on a global ctor for creating the default RNG, which is used liberally.
A useful intermediate step is to have these "[shared] static this" ctor call a function instead, so that programs without druntime can call them too.

On 11/27/2016 08:28 AM, Guillaume Piolat wrote:
> On Saturday, 26 November 2016 at 20:13:36 UTC, Andrei Alexandrescu wrote:
>>
>> Congrats! Also thanks for using the Boost license which would allow
>> backporting the improvements to Phobos. Who'd be up for it?
>>
>> Also I'm thinking of removing std.random's dependency on druntime,
>> e.g. by removing the uses of enforce. Thoughts?
>>
>> Andrei
>
> Without druntime, global ctor/dtor and TLS can't be used too.
> Besides nothrow @nogc, std.random relies on a global ctor for creating
> the default RNG, which is used liberally.

I see, so TLS is a problem.

> A useful intermediate step is to have these "[shared] static this" ctor
> call a function instead, so that programs without druntime can call them
> too.

That would be progress.


Andrei

On Sunday, 27 November 2016 at 13:35:48 UTC, Andrei Alexandrescu wrote:
>
>> A useful intermediate step is to have these "[shared] static this" ctor
>> call a function instead, so that programs without druntime can call them
>> too.
>
> That would be progress.
>
>
> Andrei

Same story for core.cpuid which is initialized by a shared static constructor.
https://github.com/dlang/druntime/blob/master/src/core/cpuid.d

It seems the "shared static this" is allowed to break immutable but a function wouldn't. So maybe the variables here should be private __gshared?.

On Sunday, 27 November 2016 at 13:58:29 UTC, Guillaume Piolat wrote:
> On Sunday, 27 November 2016 at 13:35:48 UTC, Andrei Alexandrescu wrote:
>>
>>> A useful intermediate step is to have these "[shared] static this" ctor
>>> call a function instead, so that programs without druntime can call them
>>> too.
>>
>> That would be progress.
>>
>>
>> Andrei
>
> Same story for core.cpuid which is initialized by a shared static constructor.
> https://github.com/dlang/druntime/blob/master/src/core/cpuid.d
>
> It seems the "shared static this" is allowed to break immutable but a function wouldn't. So maybe the variables here should be private __gshared?.

They are in Mir CPUID, but methods are not pure.

https://github.com/libmir/mir-cpuid/blob/master/source/cpuid/x86_any.d