public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
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

             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).