Need above for massively parallel Monte Carlo simulation. Read loads
of papers and other materials discussing it, and still am not able to
decide for the best option. So - any suggestion?

Thanks.

On 2008-05-02 17:13:57 -0300, Crni Gorac <cgo...@gmail.com> said:

Need above for massively parallel Monte Carlo simulation.  Read loads
of papers and other materials discussing it, and still am not able to
decide for the best option.  So - any suggestion?

Thanks.

Do you need to be able to rerun exactly the same RNs?

How much computation will you do on each RN? Is the speed of
the PRNG important in the overall computation? Much of the
discussion of RN speed seems to assume that the other computation
is free! It matters to folks doing RN testing but one wonders
why it matters for others.

You might think of just having a RN server that does not have
to be parallel itself.

Nvidia have source code for the MT on their CUDA web-page.  I guess
that might be fast enough for you.
The CUDA enabled graphics cards allow you to do super-computing in
your own home, you can use the GPU for general purpose computing.

On May 3, 12:36 pm, Thiophene <bitterlemo... at (no spam) yahoo.ie> wrote:

Nvidia have source code for the MT on their CUDA web-page. I guess
that might be fast enough for you.
The CUDA enabled graphics cards allow you to do super-computing in
your own home, you can use the GPU for general purpose computing.

It is CUDA calculation in question, and MT is not satisfactory here -
too much of the state is needed, that is limiting with regard to the
CUDA optimizations...

On May 3, 11:54 pm, Crni Gorac <cgo... at (no spam) gmail.com> wrote:
On May 3, 12:36 pm, Thiophene <bitterlemo... at (no spam) yahoo.ie> wrote:

Nvidia have source code for the MT on their CUDA web-page. I guess
that might be fast enough for you.
The CUDA enabled graphics cards allow you to do super-computing in
your own home, you can use the GPU for general purpose computing.

It is CUDA calculation in question, and MT is not satisfactory here -
too much of the state is needed, that is limiting with regard to the
CUDA optimizations...

I am not a salesperson for that graphics card company but you could
buy another, though I guess memory bandwidth...
I have tried many different RNG's for doing random permutations, and
you know what they are all really bad, even the so called best.

Better to call them Somewhat Disordered Number Generators. You know
about linear congruent generators, you know about Fibonacci
generators. Perhaps a 3-term Fibonacci generator would suffice. I can
understand your quandary, there are no good answers.
If you can quantify exactly how disordered the numbers need to be for
your application, maybe you will find that an LC might actually do.
That is what I do in relation to random permutations. I ask the
question how many different permutation, and how different are they
from each other.

OK, let me try to be somewhat more specific: Particular needs for this
simulation are alike, I guess, to needs of most of MC based
simulations to be implemented on CUDA, which means the demands from
RNG are: to generate many large sequences of random numbers in
parallel, to have these sequences manifesting low correlation between
each other and being generally "good" in other statistical regards,
then to have small state (Mersenne Twister need 624 numbers of state,
this is way too big) in order to be able to keep it in CUDA shared
memory (otherwise the performance will suffer heavily). Seems like
good choice may be to use some of RNGs with small state for each
thread of execution, but initialized with different seeds (generated
by another RNG). But again - there are way too much options available
for both "main" and "seeding" RNG, so the question is: which ones to
choose, and how to measure the quality of the results?

If it has a small state then it will have a short cycle. If you want
large sequences then you seem to want a long cycle. Having several
points active on a short cycle is not compatible with independence
of long sequences. You seem to keep asking for self contradictory or
mutually incompatible properties.

OK, let me try to be somewhat more specific: Particular needs for this
simulation are alike, I guess, to needs of most of MC based
simulations to be implemented on CUDA, which means the demands from
RNG are: to generate many large sequences of random numbers in
parallel, to have these sequences manifesting low correlation between
each other and being generally "good" in other statistical regards,
then to have small state (Mersenne Twister need 624 numbers of state,
this is way too big) in order to be able to keep it in CUDA shared
memory (otherwise the performance will suffer heavily). Seems like
good choice may be to use some of RNGs with small state for each
thread of execution, but initialized with different seeds (generated
by another RNG). But again - there are way too much options available
for both "main" and "seeding" RNG, so the question is: which ones to
choose, and how to measure the quality of the results?