Problem

Zamierzam napisać aplikację C ++ 11 dla Linuksa, która wykonuje pewną symulację numeryczną (nie kryptograficzną) w oparciu o około milion pseudolosowych liczb 32-bitowych. Aby przyspieszyć proces, chciałbym przeprowadzić symulację w równoległych wątkach, używając wszystkich rdzeni procesora desktopowego. Chciałbym użyć Twister Mersennemt19937 zapewnione przez boost jako PRNG i sądzę, że ze względu na wydajność powinienem mieć jeden taki PRNG na wątek. Teraz nie jestem pewien, jak je posiać, aby uniknąć generowania tego samego podciągu liczb losowych w wielu wątkach.

Alternatywy

Oto alternatywy, o których dotychczas myślałem:

Ziarno PRNG dla każdego wątku niezależnie od/dev/urandom.

Jestem trochę zaniepokojony przypadkiem wyczerpania puli entropii systemowej, ponieważ nie wiem, jak działa wewnętrzny system PRNG. Czy może się zdarzyć, że przypadkowo otrzymam kolejne nasiona, które dokładnie identyfikują kolejne stany Twistera Mersenne'a, ze względu na fakt, że/dev/urandom używa samego Mersenne Twister? Prawdopodobnie mocno związany z moimi obawami o następny punkt.

Ziarno jednego PRNG z/dev/urandom i inni z tego pierwszego.

Zasadniczo to samo: czy dobrze lub źle używać jednego PRNG do rozsiewania innego, który używa tego samego algorytmu? Innymi słowy, odczyt 625 32-bitowych liczb całkowitych z amt19937 odpowiadają bezpośrednio wewnętrznemu stanowimt19937 generator w dowolnym momencie podczas tego pokolenia?

Posiewaj innych od pierwszych z informacjami nie mersenne.

Ponieważ używanie tego samego algorytmu do generowania liczb losowych i generowania początkowych nasion wydaje się być złym pomysłem, pomyślałem o wprowadzeniu jakiegoś elementu, który nie jest zależny od algorytmu Mersenne Twister. Na przykład mogłem XOR identyfikować wątek w każdym elemencie początkowego wektora początkowego. Czy to wszystko poprawia?

Udostępnij jeden wątek PRNG.

Zapewniłoby to, że istnieje tylko jedna sekwencja, ze wszystkimi znanymi i pożądanymi właściwościami Twister Mersenne. Ale blokowanie narzutów wymaganych do kontrolowania dostępu do tego generatora niepokoi mnie nieco. Ponieważ nie znalazłem żadnych dowodów przeciwnych, zakładam, że ja jako użytkownik biblioteki byłbym odpowiedzialny za zapobieganie równoczesnemu dostępowi do PRNG.

Wstępnie generuj wszystkie liczby losowe.

To miałoby jeden wątek generujący wszystkie wymagane losowe liczby 1M z góry, które będą później używane przez różne wątki. Zapotrzebowanie pamięci na 4M byłoby niewielkie w porównaniu z ogólną aplikacją. Najbardziej martwi mnie to, że samo generowanie liczb losowych nie jest równoległe. To całe podejście również nie jest zbyt skalowalne.

pytania

Które z tych podejść sugerowałbyś i dlaczego? A może masz inną sugestię?

Czy wiesz, które z moich obaw są uzasadnione i które wynikają po prostu z mojego braku wglądu w to, jak rzeczy rzeczywiście działają?