First cut of rand_rate...

[Robert G. Brown]

Just for folks interested in the gsl rngs (and so far ONLY the gsl rngs)
I'm announcing the first 0.1.0 cut of a rng benchmarking and testing
tool called "rand_rate" that is directly integrated with the gsl.

You can get a (linux "only", as it uses /dev/random to seed) tarball of
the source from

  http://www.phy.duke.edu/~rgb/rand_rate.tgz

which "should" just make on a linux box with the gsl installed.

It seeds from /dev/random, and will need to be hacked to support a
different seeding mechanism (like the one indicated in the gsl manual)
if you don't have a /dev/random device on your machine or use a
different OS.

This snapshot isn't documented anywhere but in this note and in the
source, so ignore the "man page" and output from -h.  All that works is:

If entered as

  rand_rate -v 2

it will list all the gsl random number generators (if your gsl revision
is far enough along that e.g. gsl_rng_name() etc. exists).

If entered as

  rand_rate -t gsl_num

(where gsl_num is the index number of one of the tests from the -v 2
listing)  it should run the benchmark, e.g.:

rgb at ganesh|T:454>rand_rate -t 12
#========================================================================
# Timing "Empty" Loop
# Samples = 100  Loop iterations per sample = 8388608
# Time(sec): 2.34589458e-09 +/- 9.09979502e-12
#========================================================================
# Timing test 12
# Time(sec): 4.33561719e-05 +/- 5.91981762e-08
# Samples = 100  Loop iterations per sample = 256
#========================================================================
# Benchmark of the gsl_rnd_int() for the mt19937 generator:
#    and vector size = 1000 (4000 bytes)
# Average Time:  43.35 nanoseconds
# BogomegaRate:  23.07 mt19937 megarands per second

Actually, one should still be able to use e.g. -s and -n options to vary
vector size and number of samples, but I don't think they'll be
important for this benchmark.

Note that the benchmark for /dev/random doesn't yet work, and I don't
yet have any homemade tests (ones not yet in the gsl) wrapped so ignore
the final /dev/random index.  I'm hoping to put a nice gsl wrapper in
this testing program so that anything from a hardware generator to a new
software generator can be wrapped up for testing (preferrably without
having to rebuild the entire gsl library:-) and then simply added to the
gsl if it is deemed worthy.

At this moment, rand_rate only times the tests and returns their
"bogomegarate" of a gsl rng -- a very respectable 23 million unsigned
long random integers per second, for the excellent mt19937 generator on
my 1300 MHz Athlon desktop, for example.

My next chore (after arranging for importing hw/sw generators
consistently in gsl wrappers) is going to be integrating this tool with
all the tests I can from both diehard and sts (and any additional ones
that come to mind or are suggested).  The same tool should eventually be
able to both benchmark a rng and automagically test its overall quality
against a decent sized set of well-known tests.  This would greatly
simplify rng selection and implementation, as well as act as an
"importing tool" for potential rng algorithms to facilitate their
addition to the gsl.

I also want to test the speedup that should result from filling a vector
(a quite long vector) of rands all at once WITHIN a single subroutine
call -- I'm betting that major factor in the speed of a gsl rng is the
subroutine call overhead and cache thrashing, as the actual arithmetic
required for most rng's suggests (according to e.g. stream benchmarks)
rates that should be perhaps twice this, if not more.  

If so, it might be a good idea to create a macro interface to a
"streaming" implementation that generally returns the next rand from a
vector of rands and increments a pointer and only calls gsl subroutine
to refill the entire vector all at once when the pointer reaches the end
of the vector.  Monte Carlo folks can consume a LOT of rands in a
computation, and a factor of e.g. even 10-20% speedup can make a major
difference in time of completion, and who knows, it might be even more.

Hope this helps somebody.  If nothing else, the rand_rate source makes
it very clear how easy it is to generate rands using the gsl and
provides at least one way of "reliably" seeding it (presuming that
/dev/random ultimately passes e.g. diehard and sts:-).  The timing and
quality results are certainly useful to me, anyway, which is why I'm
writing it.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu