From: "Robert G. Brown" <rgb@phy.duke.edu>
To: GSL Discussion list <gsl-discuss@sources.redhat.com>
Subject: 64 bit rng interface?
Date: Mon, 17 Mar 2008 14:31:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.0803171008180.7337@cain.rgb.private.net> (raw)
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
next reply other threads:[~2008-03-17 14:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-17 14:31 Robert G. Brown [this message]
2008-03-17 23:20 ` Brian Gough
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0803171008180.7337@cain.rgb.private.net \
--to=rgb@phy.duke.edu \
--cc=gsl-discuss@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).