Escribí librdrand. Es un conjunto básico de rutinas para usar la instrucción RdRand para llenar los buffers con números aleatorios.
Los datos de rendimiento que mostramos en IDF provienen del software de prueba que escribí y que genera varios hilos usando pthreads en Linux. Cada extracción de hilo llena un búfer de memoria con números aleatorios usando RdRand. El programa mide la velocidad promedio y puede iterar variando el número de subprocesos.
Dado que hay una latencia de comunicaciones de ida y vuelta desde cada núcleo hasta el DRNG compartido y la parte posterior es mayor que el tiempo necesario para generar un número aleatorio en el DRNG, el rendimiento promedio obviamente aumenta al agregar hilos, hasta que se alcanza el rendimiento máximo. El rendimiento máximo físico del DRNG en IVB es de 800 MB/s. Un IVB de 4 núcleos con 8 hilos maneja algo del orden de 780Mbytes/s. Con menos hilos y núcleos, se alcanzan números más bajos. El número de 500MB/s es algo conservador, pero cuando intenta hacer afirmaciones de rendimiento honesto, tiene que serlo.
Dado que el DRNG funciona a una frecuencia fija (800MHz) mientras que las frecuencias del núcleo pueden variar, el número de ciclos del reloj central por RdRand varía dependiendo de la frecuencia del núcleo y el número de otros núcleos que acceden simultáneamente al DRNG. Las curvas dadas en la presentación de IDF son una representación realista de qué esperar. El rendimiento total se ve afectado un poco por la frecuencia del reloj central, pero no mucho. El número de hilos es lo que domina.
Se debe tener cuidado al medir el rendimiento RdRand para 'usar' realmente el resultado RdRand. Si no lo hace, I.E. usted hizo esto ... RdRand R6, RdRand R6, ....., RdRand R6 repetidos muchas veces, el rendimiento sería artificialmente alto. Como los datos no se utilizan antes de que se sobrescriban, la interconexión de la CPU no espera a que los datos vuelvan del DRNG antes de emitir la siguiente instrucción. Las pruebas que escribimos escriben los datos resultantes en la memoria que estará en la memoria caché en el chip para que la tubería se detenga en espera de los datos. Esa es también la razón por la que hyperthreading es mucho más efectivo con RdRand que con otros tipos de código.
Los detalles de la plataforma específica, la velocidad del reloj, la versión de Linux y la versión GCC se dieron en las diapositivas IDF.No recuerdo los números en la parte superior de mi cabeza. Hay chips disponibles que son más lentos y chips disponibles que son más rápidos. El número que dimos para < 200 ciclos por instrucción se basa en mediciones de aproximadamente 150 ciclos de núcleo por instrucción.
Los chips están disponibles ahora, por lo que cualquier persona versada en el uso de rdtsc puede hacer el mismo tipo de prueba.
No sé la respuesta, sin ejecutar un punto de referencia, pero como parte interesada puedo preguntar "¿Qué tan rápido quieres que sea?" Es decir. ¿Qué aplicaciones necesitan muchos RDRANDs? Por cierto, hay dos preguntas separadas aquí: (a) qué tan rápida es la instrucción, en términos de latencia y rendimiento, pero también (b) ¿puede leerse más rápido de lo que se acumula el pool de entropía? Es decir. ¿puedes agotar el grupo de entropía, y simplemente estar ejecutando números pseudoaleatorios? –
La única razón por la que puedo pensar por qué a alguien le importaría es decidir si se usa 'RDRAND' directamente oa través de un PRNG. Obtendrá el mismo comportamiento observable en ambos casos, pero uno podría ser significativamente más rápido que el otro, y no es inmediatamente evidente cuál sería. (KrazyGlew: Tu 'b' es algo irrelevante. Es como preguntar cuánta agua bendita obtienes antes de que cambie al agua. No hay diferencia detectable entre los dos, y la distinción es esencialmente insignificante en este contexto) –
@KrazyGlew Un caso de uso genera números aleatorios para el muestreo estadístico en una GPU. – user239558