¿Cuál es la latencia y el rendimiento de la instrucción RDRAND en Ivy Bridge?

Escribí librdrand. Es un conjunto muy básico de rutinas para usar la instrucción RdRand para llenar buffers con números aleatorios.

Los datos de rendimiento que mostramos en IDF son del software de prueba que escribí que genera una serie de subprocesos utilizando 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 media y puede iterar mientras varía el número de subprocesos.

Dado que hay una latencia de comunicaciones de ida y vuelta desde cada núcleo del DRNG compartido y viceversa que es más largo que el tiempo necesario para generar un número aleatorio en el DRNG, el rendimiento promedio obviamente aumenta a medida que agrega subprocesos, hasta que se alcanza el rendimiento máximo. El rendimiento máximo físico del DRNG en IVB es de 800MBytes/s. Un IVB de 4 núcleos con 8 hilos maneja algo del orden de 780Mbytes / s. Con menos hilos y núcleos, se logran números más bajos. El número de 500MB/s es algo conservador, pero cuando estás tratando de hacer tienes que ser honesto.

Dado que el DRNG se ejecuta a una frecuencia fija (800MHz) mientras que las frecuencias del núcleo pueden variar, el número de ciclos de reloj del núcleo 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 del IDF son una representación realista de lo que se puede 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 dominar.

Uno debe tener cuidado al medir el rendimiento de RdRand para realmente 'usar' el resultado de RdRand. Si no lo haces, es decir, tú hiciste esto.. RdRand R6, RdRand R6,....., RdRand R6 repetido muchas veces, el rendimiento se leería como artificialmente alto. Dado que los datos no se usan antes de que se sobrescriban, la tubería de CPU no espera a que los datos regresen del DRNG antes de emitir la siguiente instrucción. Las pruebas que escribimos escriben los datos resultantes en la memoria que estará en caché en el chip, por lo que la tubería se detiene a la espera de los datos. Es por eso 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 de GCC se dieron en las diapositivas de IDF. No recuerdo los números de la parte superior de mi cabeza. Hay fichas disponibles que son más lentos y fichas disponibles que son más rápidos. El número que dimos para

Los chips están disponibles ahora, por lo que cualquier persona bien versada en el uso de rdtsc puede hacer el mismo tipo de prueba.