[Bench!][Mir] +54%..+185% performance boost for Mersenne Twister.

Joseph Rushton Wakeling via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 13 16:18:06 PST 2016


On Tuesday, 13 December 2016 at 23:18:26 UTC, Ilya Yaroshenko 
wrote:
>>   * @Ilya, is this implementation your own design, or do you 
>> have a reference
>>     for the rationale behind this revised implementation of MT?
>
> My own.

Congratulations, then -- I think this is a very interesting 
rewrite of the algorithm and I would encourage you to write up a 
paper on your choice of optimizations, if that is of interest to 
you.

>>   * Is there a particular reason why the `index` variable is a 
>> `Uint` (i.e.
>>     the word type of the generator) rather than a `size_t`?  I 
>> presume there's
>>     a motivation, since the casting back and forth in `opCall` 
>> would otherwise
>>     seem inconvenient.
>
> If I remember correctly it is used with Uint, so I use the same 
> type.

Not anywhere that I can find.  `n`, the template parameter from 
which `this.index` is initialized, is a `size_t`, while the value 
used inside `opCall` is a `sizediff_t`.

TBH I assumed it was related to the bit-packing of the struct, 
rather than any question of usage.

>>   * Is there a motivation for the reverse iteration through 
>> the RNG state array?
>
> Yes, it composes add/sub with cmp operations.

Cool.  Last question: IIUC you use the private `_z` parameter as 
a cache for the most recent `data[index]` value (and AFAICT 
that's the only use it has).  Is there a good reason for doing 
this, rather than just setting `z = data[index]` inside `opCall` 
(where `z` is the local parameter inside the method)?

I ask because it doesn't seem to make any practical difference to 
the benchmarking outcomes, and you have to look up `data[index]` 
anyway when you write it, so it's not obvious to me that it 
really saves anything in practice.  (I confess I haven't looked 
at the assembly, so I might be missing something.)

Thanks for the answers, and apologies for my slow follow-up on 
some of the things we discussed earlier related to mir.random -- 
it's been a bit of a busy patch ... :-\


More information about the Digitalmars-d mailing list