[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