Generatori di numeri pseudocasuali paralleli

Questa domanda è principalmente legata a un problema pratico di ingegneria del software, ma sarei curioso di sapere se i teorici potrebbero fornire maggiori informazioni in merito.

In parole povere, ho una simulazione Monte Carlo che utilizza un generatore di numeri pseudocasuali e vorrei parallelizzarlo in modo che ci siano 1000 computer che eseguono la stessa simulazione in parallelo. Pertanto ho bisogno di 1000 flussi indipendenti di numeri pseudocasuali.

Possiamo avere 1000 flussi paralleli con le seguenti proprietà? Qui $X$ dovrebbe essere un PRNG molto noto e ampiamente studiato con tutti i tipi di belle proprietà teoriche ed empiriche.

1. I flussi sono altrettanto buoni di quelli che otterrei se semplicemente usassi $X$ e divido il flusso generato da $X$ in 1000 flussi.

2. Generando il numero successivo in qualsiasi flusso è (quasi) veloce come generare il numero successivo con $X$ .

In altre parole: possiamo ottenere più flussi indipendenti "gratis"?

Naturalmente se usassimo semplicemente $X$ , scartando sempre 999 numeri e selezionando 1, avremmo sicuramente la proprietà 1, ma perderemmo il tempo di esecuzione per fattore 1000.

Una semplice idea sarebbe quella di usare 1000 copie di $X$ , con i semi 1, 2, ..., 1000. Questo sarebbe certamente veloce, ma non è ovvio se i flussi hanno buone proprietà statistiche.

Dopo alcuni googling, ho trovato, ad esempio, quanto segue:

• La libreria SPRNG sembra essere progettata esattamente per questo scopo e supporta più PRNG .

• Il twister di Mersenne sembra essere un PRNG popolare al giorno d'oggi, e ho trovato alcuni riferimenti a una variante che è in grado di produrre più flussi in parallelo.

Ma tutto ciò è così lontano dalle mie aree di ricerca, che non sono riuscito a capire quale sia realmente lo stato dell'arte e quali costruzioni funzionino bene non solo in teoria ma anche in pratica.

Alcuni chiarimenti: non ho bisogno di alcun tipo di proprietà crittografiche; questo è per il calcolo scientifico. Avrò bisogno di miliardi di numeri casuali, quindi possiamo dimenticare qualsiasi generatore con un periodo $< 2^{32}$ .

Modifica: non riesco a usare un vero RNG; Ho bisogno di un PRNG deterministico. In primo luogo, aiuta molto con il debug e rende tutto ripetibile. In secondo luogo, mi permette di fare, ad esempio, la ricerca mediana in modo molto efficiente sfruttando il fatto che posso usare il modello multi-pass (vedi questa domanda ).

Modifica 2: C'è una domanda strettamente correlata @ StackOverflow: generatore di numeri pseudo-casuali per l'ambiente cluster .

Puoi utilizzare un'evoluzione dell'algoritmo di Mersenne Twister sviluppato da Saito e Matsumoto:

Fast Mersenne Twister (SFMT) orientato al SIMD

SFMT è un generatore di Linear Feedbacked Shift Register (LFSR) che genera un intero pseudocasuale a 128 bit in un solo passaggio. SFMT è progettato con il recente parallelismo di CPU moderne, come pipeline multistadio e istruzioni SIMD (es. Intero a 128 bit). Supporta numeri interi a 32 e 64 bit, nonché in virgola mobile a precisione doppia come output. SFMT è molto più veloce di MT, nella maggior parte delle piattaforme. Non solo la velocità, ma anche le dimensioni delle equidistribuzioni con precisione v-bit sono migliorate. Inoltre, il recupero dallo stato iniziale in eccesso di 0 è molto più veloce. Vedi la tesi di Master di Mutsuo Saito per i dettagli .

Il periodo varia da a 2 216091 - 1 .$2^{607}-1$$2^{216091}-1$

L'uso di uno stesso generatore di numeri casuale per generare più flussi indipendenti modificando i valori iniziali può causare un problema (con probabilità trascurabilmente piccole). Per evitare il problema, è preferibile utilizzare parametri diversi per ogni generazione. Questa tecnica è chiamata creazione dinamica dei parametri MT.

Nel codice sorgente SFMT puoi trovare alcuni esempi di set di parametri (di periodi variabili) e uno script awk per convertire un file CSV in un set di parametri compilabile. Esiste anche uno strumento chiamato " Creazione dinamica di generatori Twister di Mersenne ".

Gli autori hanno recentemente sviluppato un'altra versione modificata di Mersenne Twister - Mersenne Twister per processori grafici - progettata per funzionare in GPU e sfruttare i thread di esecuzione paralleli nativi. La caratteristica chiave è la velocità: numeri interi casuali ogni 4.6ms su una GeForce GTX 260.$5 \times 10^7$

I periodi della sequenza generata sono , 2 23209 - 1 e 2 44497 - 1 per la versione a 32 bit e 2 23209 - 1 , 2 44497 - 1 , 2 110503 - 1 per la versione a 64 bit. Supporta 128 set di parametri per ogni periodo, in altre parole, può generare 128 sequenze di numeri pseudocasuali indipendenti per ogni periodo. Abbiamo sviluppato Dynamic Creator per MTGP, che genera più set di parametri$2^{11213}-1$$2^{23209}-1$$2^{44497}-1$$2^{23209}-1$$2^{44497}-1$$2^{110503}-1$

Infatti forniscono uno strumento MTGPDC per creare fino a set di parametri (ovvero flussi indipendenti).$2^{32}$

L'algoritmo supera i principali test di casualità come Diehard e NIST.

Un articolo preliminare è disponibile anche su arXiv: una variante di Mersenne Twister adatta per processori grafici

Sembra che ci siano molti modi per affrontare questo problema, ma un modo semplice sarebbe usare il PRNG Blum Blum Shub . Questo PRNG è definito dalla relazione di ricorrenza , dove N è un semiprime. Per ottenere un bit casuale da questo, puoi semplicemente prendere la parità di bit di x i . La cosa bella di questo è che poiché x i + k = x 2 k i  mod  N = x 2 k  mod  λ ( N )$x_{i+1} = x_i^2 \mbox{ mod }N$$N$$x_i$ puoi calcolare direttamente qualsiasi costante di tempo in k (cioè O ( log ( N ) 3 ) o più veloce a seconda dell'algoritmo di moltiplicazione che usi per l'esponenziale modulare). Quindi haimacchine M , quindi per la macchina indicizzata da y puoi usare il generatore x i + 1 , y = x 2 M mod  λ ( N ) i  mod  N , dove x 0 , y = $x_{i+k} = x_i^{2^k}\mbox{ mod }N = x_i^{2^k \mbox{ mod } \lambda(N)}\mbox{mod }N$$k$$O(\log(N)^3)$$M$$y$$x_{i+1,y} = x_i^{2^M \mbox{mod }\lambda(N)}\mbox{ mod }N$, dovex0è il tuo seme. Convenientemente, questo genera esattamente lo stesso flusso di numeri come se si utilizzasse un singolo flusso e si distribuisse a sua volta l'output a ciascuna macchina.$x_{0,y} = x_0^{2^y \mbox{ mod }\lambda(N)}\mbox{ mod }N$$x_0$

Questo non è il più veloce dei PRNG, quindi sarà utile solo se il sovraccarico di qualsiasi cosa tu stia facendo nella simulazione è significativamente maggiore del costo del PRNG. Tuttavia, vale la pena sottolineare che sarà molto più veloce per alcune combinazioni di e N rispetto ad altre, in particolare se la rappresentazione binaria di 2 M  mod  λ ( N ) contiene pochi 1s o è piccola.$M$$N$$2^M \mbox{ mod }\lambda(N)$

Che ne dici di una fase di preelaborazione? Dato un seme casuale (di dimensione n ), esegui X per ottenere un flusso pseudocasuale di dimensione 1000 n . Indica questo flusso con s 1 , s 2 , … , s 1000 , dove per 1 ≤ i ≤ 1000 , s i è una porzione contigua del flusso di dimensione n .$s$$n$$X$$1000n$$s_1,s_2,\ldots,s_{1000}$$1\le i \le 1000$$s_i$$n$

Questa fase di preelaborazione può essere eseguita con un overhead molto basso, dato che è un PRNG efficiente (oggi abbiamo PRNG molto veloci).$X$

Ora, dare come il seme al I ° macchina, che utilizza X per generare il proprio flusso pseudo-casuale.$s_i$$i$$X$

Date le belle proprietà di , a meno che non sia noto, per ogni 1 ≤ i < j ≤ 1000 , i semi s i e s j sono indipendenti dal punto di vista computazionale. Inoltre, si ha solo per generare e salvare un piccolo seme (cioè s ); pertanto, questo approccio non richiede molta casualità o archiviazione.$X$$s$$1 \le i < j \le 1000$$s_i$$s_j$$s$

È possibile utilizzare una funzione pseudocasuale $f$come AES o ChaCha con una singola chiave casuale, crittografando un contatore. Assegna a ciascuno dei$M = 1000$ parallel elabora un valore iniziale univoco in $\{ 0, 1, \ldots, M - 1 \}$e quindi calcolare il $j$th blocco casuale di bit per processo $i$ come $f(i + jM)$, ovvero incrementare il contatore in ogni processo di $M$ per ogni successivo blocco di bit casuali.

Questo ti darà un RNG crittografico su ogni processo, ma non comporta necessariamente un costo in termini di prestazioni. AES è veloce se si dispone di hardware che lo supporta e ChaCha è veloce a prescindere. Naturalmente, ti consigliamo di misurarlo nella tua impostazione specifica per essere sicuro.

Entrambe le proprietà desiderate 1 e 2 ne sono direttamente soddisfatte. È inoltre conveniente che il comportamento dell'intero sistema di attività parallele sia controllato da un singolo "seme" (la chiave per$f$).

Ora c'è una funzione di salto per SFMT ( un'implementazione veloce di Mersenne Twister).

Ciò mi consente di inizializzare 1000 MT in modo che non vi siano sovrapposizioni di cicli. E SFMT dovrebbe essere più veloce di MTGP. Quasi perfetto per i miei scopi.

Puoi semplicemente usare 1000 istanze del Mersenne Twister inizializzato con diversi semi.

Puoi campionare i semi da un altro Mersenne Twister, o, per essere più sicuro della loro indipendenza, dal generatore di numeri pseudocasuale crittografico del sistema operativo (/ dev / urandom in Linux).

Il Mersenne Twister opera sempre sulla stessa sequenza ciclica, il seme controlla da dove inizi a generarlo. Con semi campionati indipendentemente, ciascun generatore si avvierà in punti diversi, in genere molto lontani, con una probabilità molto piccola di intersezione.