[Numpy-discussion] Purpose for bit-wise and'ing the initial mersenne twister key?
Michael S. Gilbert
Thu Feb 12 14:17:17 CST 2009
On Thu, 12 Feb 2009 13:18:26 -0600 Robert Kern wrote:
> > I did some testing with this 64-bit implementation (mt19937-64). I've
> > found that it is actually slower than the 32-bit reference (mt19937ar)
> > on 64-bit systems (2.15s vs 2.25s to generate 100000000 ints). This is
> > likely because it generates 64-bit long long ints instead of 32-bit
> > long ints. However, it should be possible to break up each 64-bit int
> > into two 32-bit ints, then the runtime would appear to be almost twice
> > as fast.
> Why do you think that?
You could also think of it the other way (in terms of generating 64-bit
ints). Instead of generating two 32-bit rints and concatenating them
for a 64-bit int, you can just directly generate the 64-bit int. Since
the 64-bit int requires only slightly more time to generate than either
of the 32-bit ints individually, an almost 2x speedup is achieved.
> > One other consideration to keep in mind is that the 64-bit
> > version is not stream-compatible with the 32-bit implementation (you
> > will get different sequences for the same input seed).
> > Would it be worth it to implement this in numpy in order to get an
> > almost 2x speedup on 64-bit machines?
> The incompatibility is a showstopper to replacing the PRNG on any platform.
Why is stream-compatibility such a stringent requirement? It seems
like this contstraint majorly limits your ability to adopt new/better
technologies and reduces your flexibility to make changes to your code
as needed. What end-use applications require stream-compatibility? The
only thing I can think of is verification/regression testing for numpy,
but those test cases could be updated to account for the break in
compatibility (and specifically using the reference implementation's
expected output). Wouldn't sufficient documentation of the change in
behavior be sufficient?
More information about the Numpy-discussion