This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

64 bit rng interface?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]