RNG, R, mclapply et cluster d'ordinateurs

10

J'exécute une simulation sur R et un cluster d'ordinateurs et j'ai le problème suivant. Sur chacun des ordinateurs X, je lance:

fxT2 <- function(i) runif(10)
nessay <- 100
c(mclapply(1:nessay, fxT2), recursive=TRUE)

Il y a 32 ordinateurs, chacun avec 16 cœurs. Cependant, environ 2% des nombres aléatoires sont identiques. Quelles stratégies adopteriez-vous pour éviter cela?

J'ai pu éviter ce problème pour fxT2 en définissant une latence (c'est-à-dire en retardant d'une seconde l'heure à laquelle chaque travail est envoyé à chacun des ordinateurs X). Mais cela semble très ad hoc pour fxt2.

Le problème est qu'en réalité fxT2 est une longue tâche impliquant des nombres pseudo aléatoires. À la fin du processus, je m'attends à obtenir une reproduction X * nessay de la même expérience statistique, et non des reproductions nessay. Comment s'assurer que tel est bien le cas et existe-t-il un moyen de vérifier cela?.

user603
la source
Bonne question. Jetez un oeil à cette question sur les nombres aléatoires et le package multicœur
csgillespie
@CSgillepsie:> merci pour le pointeur, mais je ne suis pas sûr que ce soit le même problème: la façon dont je comprends la question que vous avez pointée, tous les processus sont engendrés par mclapply. Ici, c'est un peu différent: sur chacune des machines, tous les processus sont générés par mclapply, mais ce n'est pas le cas sur toutes les machines.
user603

Réponses:

6

La neige a un support explicite pour initialiser le nombre donné de flux RNG dans un calcul de cluster.

Il peut utiliser l'une des deux implémentations RNG:

Sinon, vous devez faire la coordination à la main.

Dirk Eddelbuettel
la source
3

Vous devez utiliser un RNG spécialement conçu pour le calcul parallèle. Consultez la section «Calcul parallèle: nombres aléatoires» de la vue des tâches de calcul haute performance .

Joshua Ulrich
la source
Vous devez également coordonner les flux RNG. Snow le fait, le multicœur peut maintenant.
Dirk Eddelbuettel