64 bit rng interface?

64 bit rng interface?

[Robert G. Brown]

Hey all.

I'm getting close to a new release of dieharder with a bunch of bug
fixes and (I'm hoping) the gnu build tools all correctly implemented for
the handling of the library and to automate multiplatform/OS builds.  It
will also have a few more tests -- one of which should be a very, very
good one, that in principle will embrace all the overlapping monkey
tests out to 16 bit patterns but return a more precise statistic, and it
will have a small stack of additional RNGs both old and new all wrapped
up GSL style (some of which are probably worthy of addition to the GSL
itself) as people are starting to really contribute them and use
dieharder to test ones they are developing.  But that's not why I'm
writing as it isn't really ready yet for anything beyond some alpha/beta
testing of the fixes made so far.

What I'd like to know are the following two things:

    a) Are there plans for a 64-bit GSL RNG interface?  A number of my
correspondants are working on algorithms that can run equally well at 64
bits, and 64 bit unsigned ints invert to double precision uniform
deviates.

    b) Are there plans for a "vectorized" interface?  I'd envision this
as a user-selectable switch on the creation/initialization step that
builds (say) a page-sized buffer.  On the first call, this buffer would
be filled with random bits in a single step, keeping the generation code
on the CPU and cache and permitting certain pipelining optimizations.
Subsequent calls would simply walk a pointer through the buffer to the
end, where the "refill buffer" command would once again be called and
the pointer reset to the beginning before returning.

This would obviously be undesireable for people who only want to use a
handful of rands or for whom variable latency is a problem, but I'm
guestimating that it would speed up the AVERAGE rate of delivery of
rands by at least a factor of 2, maybe more.  For simulation people; the
average rate of rand production is often a significant bottleneck, and
on a long-running simulation a factor of two can be the difference
between six months and maybe four months.

    rgb

-- 
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977

Re: 64 bit rng interface?

[Brian Gough]

At Mon, 17 Mar 2008 10:27:57 -0400 (EDT),
Robert G. Brown wrote:
>     a) Are there plans for a 64-bit GSL RNG interface?  A number of my
> correspondants are working on algorithms that can run equally well at 64
> bits, and 64 bit unsigned ints invert to double precision uniform
> deviates.

Is it possible to do it using the existing interface in some way? If
it would need a duplicate 64-bit interface it's not really feasible.

>     b) Are there plans for a "vectorized" interface?  I'd envision this
> as a user-selectable switch on the creation/initialization step that
> builds (say) a page-sized buffer.  On the first call, this buffer would
> be filled with random bits in a single step, keeping the generation code
> on the CPU and cache and permitting certain pipelining optimizations.
> Subsequent calls would simply walk a pointer through the buffer to the
> end, where the "refill buffer" command would once again be called and
> the pointer reset to the beginning before returning.

The possibility is there to do that, or to provide a gsl_rng_get_array
function.  If there is a realistic benchmark that shows a large
performance improvement (>2x) then that would be a good motivation.
Currently it seems like motivation is the missing ingredient.

-- 
Brian Gough