Problema

Tengo la intención de escribir una aplicación C ++ 11 para Linux que realice una simulación numérica (no de criptografía) basada en aproximadamente un millón de números de 32 bits pseudoaleatorios. Para acelerar las cosas, me gustaría realizar la simulación en subprocesos paralelos utilizando todos los núcleos de una CPU de escritorio. Me gustaría usar el Mersenne Twistermt19937 proporcionado por boost como el PRNG, y supongo que por razones de rendimiento debería tener uno de esos PRNG por subproceso. Ahora no estoy seguro de cómo sembrarlos para evitar generar la misma subsecuencia de números aleatorios en varios subprocesos.

Alternativas

Aquí están las alternativas que he pensado hasta ahora:

Siembra el PRNG para cada hilo independientemente de/dev/urandom.

Estoy un poco preocupado por el caso cuando el grupo de entropía del sistema se agota, ya que no sé cómo funciona el PRNG interno del sistema. ¿Podría suceder que accidentalmente obtenga semillas consecutivas que identifiquen exactamente los estados consecutivos de Mersenne Twister, debido al hecho de que/dev/urandom ¿Está utilizando un Mersenne Twister en sí? Probablemente fuertemente relacionado con mis preocupaciones para el siguiente punto.

Sembrar un PRNG de/dev/urandom y los otros de ese primero.

Básicamente, la misma preocupación también: ¿es bueno o malo usar un PRNG para sembrar otro que use el mismo algoritmo? O, en otras palabras, la lectura de 625 enteros de 32 bits de unamt19937 Corresponden directamente al estado interno de lamt19937 ¿Generador en cualquier punto durante esta generación?

Siembre a otros desde el principio con información que no sea de Mersenne.

Al utilizar el mismo algoritmo para generar números aleatorios y para generar la semilla inicial parece que podría ser una mala idea, pensé en introducir algún elemento que no dependiera del algoritmo Twister de Mersenne. Por ejemplo, podría XORAR el ID de hilo en cada elemento del vector semilla inicial. ¿Eso hace las cosas mejor?

Comparte un PRNG entre los hilos.

Esto aseguraría que solo haya una secuencia, con todas las propiedades deseables y conocidas del Mersenne Twister. Pero la sobrecarga de bloqueo requerida para controlar el acceso a ese generador me preocupa un poco. Como no he encontrado evidencia de lo contrario, asumo que yo, como usuario de la biblioteca, sería responsable de evitar el acceso simultáneo al PRNG.

Pre-generar todos los números al azar.

Esto tendría un subproceso que generara todos los números aleatorios de 1M requeridos por adelantado, para que los distintos subprocesos los usaran más adelante. El requisito de memoria de 4M sería pequeño comparado con el de la aplicación general. Lo que más me preocupa de este enfoque es que la generación de números aleatorios en sí misma no es concurrente. Todo este enfoque tampoco se escala demasiado bien.

Preguntas

¿Cuál de estos enfoques sugeriría y por qué? ¿O tienes una sugerencia diferente?

¿Sabe cuáles de mis preocupaciones están justificadas y cuáles se deben simplemente a mi falta de comprensión de cómo funcionan las cosas?