+1.

On Fri, Feb 07, 2014 at 10:23:41PM +0000, Joshua Ladd wrote:
>    What: Add an internal random number generator to OPAL.
> 
>     
> 
>    Why: OMPI uses rand and srand all over the place. Because the middleware
>    is mucking with the RNG's global state, applications that use these
>    library routines will not achieve reproducible results with the same seed.
> 
>     
> 
>    How: I plan to put in an additive lagged Fibonacci generator seeded with a
>    Tausworthe generator that itself is seeded by the user's seed. The short
>    story here is that the ALFG has a toroidal state space, i.e. it can be
>    decomposed into non-overlapping cycles with maximal period. It's well
>    understood how to fully enumerate these cycles when, for a length k
>    register composed of m-bit words, we view this as a k X m binary matrix.
>    It was proven by Marsaglia et al. that this matrix has a canonical form
>    that is uniquely determined by the values k and l (the two numbers that
>    (almost) completely characterize an ALFG.) So, distinct seeds are
>    guaranteed to map to distinct, non-overlapping, long period streams that
>    have measurably very, very low inter- and intra-stream correlations.  We
>    used this for large scale Monte Carlo simulations back in my PhD days.
> 
>     
> 
>    Will define a new type:
> 
>     
> 
>    struct opal_rng_buffer_t {
> 
>     
> 
>    uint32_t  buff[127]; /* if people are going to pitch a fit over the size,
>    we can go smaller, down to 7, but, obviously, this affects the quality of
>    the streams */
> 
>    int tap1;
> 
>    int tap2;
> 
>     
> 
>    };
> 
>     
> 
>    and two functions:
> 
>     
> 
>    /* User is responsible for defining his/her own opal_rng_buffer_t
> 
>      * or malloc-ing and managing the resources themselves.   
> 
>     */
> 
>    int opal_srand(opal_rng_buffer_t *buff, uint32_t seed);
> 
>     
> 
>    /* Returns a 32-bit pseudo random integer */
> 
>    uint32_t opal_rand(opal_rng_buffer_t *buff);
> 
>     
> 
>     
> 
>    When: Should be in by the end of February.  Code is written, but
>    integration and testing always takes some time.
> 
>     
> 
>     
> 
>     
> 
>    Joshua S. Ladd, PhD
> 
>    HPC Algorithms Engineer
> 
>    Mellanox Technologies
> 
>     
> 
>    Email: josh...@mellanox.com
> 
>    Cell: +1 (865) 258 - 8898
> 
>     
> 
>     

> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Attachment: pgpAHKMTGtNwS.pgp
Description: PGP signature

Reply via email to