¿Impacto de hyperthreading en el rendimiento del compilador?

Digamos que queremos compilar un proyecto grande (digamos GCC o el kernel de Linux) lo más rápido posible. ¿Una CPU con capacidad de hyperthreading (digamos, un Intel Core i7) ejecuta el compilador más rápido con hyperthreading habilitado o deshabilitado? ¿Hay algún punto de referencia publicado que pruebe esto?¿Impacto de hyperthreading en el rendimiento del compilador?

Mi comprensión de hyperthreading es que cada núcleo puede seleccionar instrucciones de dos (o más procesos). Esto generalmente hace que el núcleo sea más eficiente ya que es menos probable que las unidades funcionales estén inactivas. Sin embargo, existe la posibilidad de una penalización en el rendimiento, ya que los procesos que se ejecutan en el mismo núcleo comparten recursos como el caché y pueden interferir entre sí. Si el rendimiento realmente aumenta o no depende de la carga de trabajo.

Entonces, para una carga de trabajo del compilador, ¿aumenta el rendimiento? Si es así, por cuánto?

Fuente

2010-01-06 Jay Conrod

No tengo experiencia reciente con esto, pero la compilación no tiende a ser de E/S? – Ken

Juega con "make -j N" y mide los recursos del sistema para diferentes N? –

@Nikolai, lo haría si tuviera una CPU de Hyperthreading para jugar. Pregunto esto para saber si vale la pena comprar uno. –

Compilación coreutils-8.4 en Ubuntu 8.04 x86

Intel Atom de 1,6 GHz con HT activado:

~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make > /dev/null 

real 2m33.375s 
user 2m22.873s 
sys  0m10.541s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make -j2 > /dev/null 

real 1m54.707s 
user 3m26.121s 
sys  0m13.821s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make > /dev/null 

real 2m33.372s 
user 2m22.753s 
sys  0m10.657s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make -j2 > /dev/null 

real 1m54.851s 
user 3m26.145s 
sys  0m13.685s 
~/coreutils-8.4$

Así Hyper-Threading reduce el tiempo de ejecución de 75%, lo que equivale a 33% más poder de procesamiento. (Me encontré dos veces para asegurarse de que todo está en la memoria caché.)

Y aquí es un experimento de control para mostrar que solo make -j2 no mejora la velocidad de compilar coreutils-8.4 en Ubuntu 8.04 x86

individual -core Core 2 Quad 2.5 GHz VM (sin HT):

~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make > /dev/null 

real 0m44.453s 
user 0m38.870s 
sys  0m5.500s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make -j2 > /dev/null 

real 0m45.131s 
user 0m40.450s 
sys  0m4.580s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make > /dev/null 

real 0m44.621s 
user 0m39.090s 
sys  0m5.340s 
~/coreutils-8.4$ make clean > /dev/null 
~/coreutils-8.4$ time make -j2 > /dev/null 

real 0m45.165s 
user 0m40.390s 
sys  0m4.610s 
~/coreutils-8.4$

Fuente

2010-04-01 23:41:51 netvope

Esto es genial. El experimento de control muestra que esto realmente hace la diferencia. Gracias. –

Me hubiera gustado ver las mediciones repetidas en el Atom con HT deshabilitado, asumiendo que es posible lograrlo. Además, una nota sobre el uso de memoria sería agradable, ya que el átomo podría comenzar a intercambiar o eliminar cachés, particularmente en el caso -j2. – Eroen

Atom en orden es peor para explotar el paralelismo a nivel de instrucción que una CPU Nehalem o Sandybridge-family, o AMD Ryzen. HT podría ayudar más en Atom que en una CPU convencional.O podría ayudar menos, porque las CPU convencionales tienen cachés más grandes y más recursos de ejecución (y penalizaciones más altas de errores de ramificación, y HT permite que el otro subproceso use la CPU mientras uno se recupera de una mala especulación). Entonces, probablemente HT también ayude significativamente a las CPU convencionales, pero la relación puede ser bastante diferente. –

Todo depende de si el compilador está escrito para ser multiproceso o no. Si es así, entonces definitivamente hyperthreading acelera un poco las cosas, ya que el sistema operativo puede programar diferentes partes de los hilos del compilador en diferentes núcleos. Estoy de acuerdo con Ken en que las compilaciones en general son más vinculadas a E/S que intensivas en el procesamiento, por lo que tener un disco duro veloz sería más una necesidad que un procesador rápido con 100 núcleos.

Fuente

2010-01-06 18:15:55 ajawad987

¿Qué tal si se invoca el compilador con make -j N (N es la cantidad de procesadores lógicos)? Me preocupa que, dado que los distintos procesos de compilación no comparten datos, en realidad reducen el rendimiento. –

1) La compilación (en Linux de todos modos) siempre se puede hacer sin límite, siempre que haya suficiente memoria física presente. 2) Los sistemas de compilación populares pueden invocar muchos procesos de compilación en paralelo, haciendo que los compiladores multiproceso no sean un problema. (menos para los vinculadores, sin embargo) – Eroen

¿Impacto de hyperthreading en el rendimiento del compilador?

Respuesta

Cuestiones relacionadas