BIEN generaciones de números seudoaleatorios

Utilicé MT19937en un arnés de prueba para generar valores uniformes (sin signo) de 32 bits [0, - 1], basados en la implementación original mt19937.c de los Autores , para generar un suministro (esencialmente inagotable) de flujo estadísticamente aleatorio de bit-octetos. Esto es en lugar de un CSPRNG, que no es necesario para estas pruebas en particular. Sin embargo, recientemente he estado considerando los PRNG, no debido a las propiedades estadísticas como tales (ambos parecen más que adecuados para mis necesidades), sino que parecen sugerir una implementación más eficiente. $2^{32}$ WELL

Me falta el trasfondo matemático para los trabajos académicos, aunque al menos podría seguir la matriz de 'giro' y la transformación de templado para el primero. Sin embargo, gran parte del código proporcionado por los Autores de las WELL-nfunciones parece centrarse en la generación de punto flotante, con algunas constantes mágicas de punto flotante (p 2.32830643653869628906e-10. Ej .). ¿Se pueden omitir los pasos del WELLcódigo para proporcionar una distribución uniforme de 32 bits? ¿O el algoritmo está diseñado / sesgado específicamente para distribuciones de punto flotante?

¿O estoy equivocado al pensar que WELLproducirá una ganancia de rendimiento para la generación de vectores uint32 'masiva', al tiempo que satisface mis requisitos?

performance c random-number-generation

— Brett Hale
fuente

Si esto es solo curiosidad, está bien, pero el rendimiento real siempre depende de lo que esté sucediendo. Si generar números aleatorios consume el 10% del tiempo total, y puede reducirlo a la mitad, eso le da una aceleración del 5%, lo que podría no valer la pena.

— Mike Dunlavey

Quizás fuera de tema, pero también vale la pena considerar generadores de modo contador como deshawresearch.com/resources_random123.html , que requieren mucha, mucha menos memoria y paralelización trivialmente.

— Geoffrey Irving

Como actualización, ahora me estoy inclinando hacia los PCGRNG. Son mucho más rápidos, pueden suministrar períodos muy largos (así como múltiples flujos) con propiedades estadísticamente excelentes, y parecen recuperarse muy rápidamente de IVs pobres.

— Brett Hale

Me imagino que la mayoría de los usuarios de generadores de números aleatorios están interesados en última instancia en los valores de coma flotante. Esta es la razón por la cual existe el Twister Mersenne Twister (dSFMT) orientado a SIMD de doble precisión . Sin embargo, hay un código C más nuevo para WELL RNG que devuelve unsigned longvalores. Al observar el código, parece que la versión anterior se estaba transmitiendo, unsigned longpor doublelo que es posible que pueda descubrir qué estaban haciendo comparando los dos.

Si te importa principalmente la velocidad, no creo que este sea el PRNG para ti. La velocidad / rendimiento a que se refieren los autores no es qué tan rápido el algoritmo genera variaciones aleatorias, sino qué tan rápido se recupera de una inicialización deficiente . Esto mejora las propiedades estadísticas del generador WELL. Consulte la sección 6 de la tesis de maestría de Mutsuo Saito (PDF) para obtener detalles sobre lo que esto significa. Dichas pruebas se realizan con estados iniciales artificiales del peor de los casos, por lo que no me queda claro cuál es el efecto de uso general.

La generación de números aleatorios puede ser bastante costosa, a menudo a pesar de la intuición, y es un muy buen candidato para la optimización, siempre que su código pase una cantidad razonable de tiempo produciendo valores aleatorios. En mis propias pruebas de rendimiento simples (Retina MacBook Pro, OS X 10.9) descubrí que el WELL RNG es aproximadamente un tercio más rápido que el actual Mersenne Twister (SFMT) orientado a SIMD basado en enteros actuales cuando produce uint32valores. SFMTtambién tiene soporte para uint64. También encontré que el mt19937ar.ccódigo clásico es aproximadamente la mitad de rápido que SFMT.

— horchler
fuente