Hyperthreading de doble núcleo: ¿Debo usar 4 hilos o 3 o 2?

Question

Si está generando varios hilos (o procesos) al mismo tiempo, ¿es mejor generar tantos procesadores físicos o el número de procesadores lógicos, suponiendo que la tarea está vinculada a la CPU? ¿O es mejor hacer algo intermedio (por ejemplo, 3 hilos)?

se compara el desempeño dependerá del tipo de instrucciones que están siendo ejecutado (por ejemplo, tendría acceso a memoria no local será muy diferente de aciertos de caché)? Si es así, ¿en qué casos es mejor aprovechar el hyperthreading?

---

Actualización:

La razón por la que estoy pidiendo es, recuerdo haber leído en alguna parte que si tiene tantas tareas como el número de procesadores virtuales, tareas en el mismo núcleo físico a veces pueden morir de hambre cierta CPU recursos y evitar que los demás obtengan tantos recursos como sea necesario, posiblemente disminuyendo el rendimiento. Es por eso que me pregunto si tener tantos hilos como núcleos virtuales es una buena idea.

Answer 1

El el rendimiento depende de una gran variedad de factores. La mayoría de las tareas no están estrictamente unidas a la CPU, ya que incluso si todos los datos están en la memoria, generalmente no están integrados en la caché del procesador. He visto ejemplos (como this one) donde los patrones de acceso a la memoria pueden cambiar drásticamente el perfil de rendimiento de un proceso "paralelo" dado.

En resumen, no existe un número perfecto para todas las situaciones.

Answer 2

Recuerdo información que hyperthreading le puede dar hasta un 30% de aumento de rendimiento. en general, será mejor tratarlos como 4 núcleos diferentes. por supuesto, en algunas circunstancias específicas (por ejemplo, tener la misma tarea de larga data con destino a cada núcleo) se puede dividir su procesamiento mejor teniendo en cuenta que algunos núcleos son los simplemente lógicas

más información sobre hyperthreading sí here

Answer 3

ocasiones son bastante buenas que usted verá una mejora el rendimiento de carrera 2 hilos por núcleo con HyperThreading habilitado. Los trabajos que parecen por ser totalmente dependientes de la CPU generalmente no lo son, y HyperThreading puede extraer algunos ciclos "extra" de la interrupción ocasional o el cambio de contexto.

Por otra parte, con un procesador de núcleo iX que tiene Turbo Boost, que en realidad podría hacerlo mejor ejecución 1 hilo por núcleo para fomentar la CPU para el overclocking de sí mismo.

En el trabajo, de manera rutinaria ejecutar servidores de múltiples núcleos en la CPU completa haciendo varias clases de cálculo de días a la vez. Hace un tiempo medimos la diferencia de rendimiento con y sin HT. Descubrimos que, en promedio, con HyperThreading y que ejecutamos el doble de trabajos a la vez, podríamos completar la misma cantidad de trabajos un 10% más rápido que sin HyperThreading.

Supongamos que 2 × núcleos es un buen lugar para comenzar, pero la conclusión es: ¡medida!

Answer 4

Al utilizar Hyperthreading para ejecutar dos hilos en el mismo núcleo, cuando ambos hilos tienen patrones de acceso de memoria similares pero acceden a estructuras de datos disjuntas, sería más o menos equivalente a ejecutarlos en dos núcleos separados, cada uno con la mitad del caché. Si los patrones de acceso a la memoria son tales que la mitad de la memoria caché sería suficiente para evitar la manipulación, el rendimiento puede ser bueno.Si los patrones de acceso a la memoria son tales que reducir a la mitad la caché induce una sacudida, puede haber un golpe de rendimiento de diez veces (lo que implicaría que uno habría estado mucho mejor sin un hyperthreading).

Por otro lado, hay algunas situaciones donde hyperthreading puede ser una gran victoria. Si muchos subprocesos leerán y escribirán los mismos datos compartidos utilizando estructuras de datos sin bloqueos, y todos los subprocesos deben ver una vista coherente de los datos, intentar ejecutar subprocesos en un procesador disjunto puede causar agitación ya que solo un procesador a la vez puede tener acceso de lectura-escritura a cualquier línea de caché dada; ejecutar dichos hilos en dos núcleos puede llevar más tiempo que ejecutar solo uno a la vez. Sin embargo, dicho arbitraje de caché no es necesario cuando se accede a un fragmento de datos mediante varios hilos en un solo núcleo. En esos casos, hyperthreading puede ser una gran victoria.

Desafortunadamente, no conozco ninguna manera de darle al programador "pistas" para sugerir que algunos subprocesos deben compartir un núcleo cuando sea posible, mientras que otros deberían ejecutarse por separado cuando sea posible.

Answer 5

Todas las otras respuestas ya dan mucha información excelente. Pero, un punto más a considerar es que la unidad SIMD se comparte entre núcleos lógicos en el mismo dado. Entonces, si está ejecutando subprocesos con código SSE, ¿los ejecuta en los 4 núcleos lógicos, o simplemente engendra 2 subprocesos (suponiendo que tenga dos chips)? Para este extraño caso, lo mejor es perfilar con su aplicación.

Answer 6

HT permite un aumento de aproximadamente un 10-30% para la mayoría tareas vinculadas a la CPU que utilizan los núcleos virtuales adicionales. Aunque estas tareas pueden parecer vinculadas a la CPU, a menos que sean ensambladas por encargo, generalmente sufrirán esperas de IO entre la memoria RAM y la memoria caché local. Esto permite que un subproceso que se ejecuta en un núcleo habilitado para HT físico funcione mientras el otro subproceso está esperando el IO. Sin embargo, esto tiene una desventaja, ya que dos subprocesos comparten el mismo caché/bus, lo que dará lugar a menos recursos, lo que puede hacer que ambos subprocesos pausen mientras esperan el IO. En el último caso, ejecutar un solo hilo disminuirá la potencia máxima de procesamiento teórico simultáneo (en un 10-30%) a favor de ejecutar un solo hilo sin la ralentización de la caché que puede ser muy significativa en algunas aplicaciones.

Elegir qué núcleos usar es tan importante como elegir cuántos hilos ejecutar. Si cada subproceso está vinculado a la CPU durante aproximadamente la misma duración, es mejor establecer la afinidad de modo que los subprocesos que utilizan recursos principalmente diferentes se encuentren en diferentes núcleos físicos y los subprocesos que utilizan recursos comunes se agrupen en los mismos núcleos físicos (núcleo virtual diferente) para que los recursos comunes se pueden usar desde la misma memoria caché sin esperar IO adicional.

Dado que cada programa tiene diferentes características de uso de CPU y la cache puede ser o no una desaceleración importante (normalmente lo es), es imposible determinar cuál debería ser el número ideal de subprocesos sin crear primero perfiles. Una última cosa a tener en cuenta es que el sistema operativo/kernel también requerirá algo de espacio de CPU y caché. Por lo general, es ideal para mantener un único núcleo (físico) reservado para el SO si se requiere latencia en tiempo real en los subprocesos vinculados a la CPU para evitar el intercambio de recursos de caché/cpu. Si los subprocesos a menudo están esperando IO y el almacenamiento en caché no es un problema, o si se está ejecutando un sistema operativo en tiempo real específicamente diseñado para la aplicación, puede omitir este último paso.

http://en.wikipedia.org/wiki/Thrashing_(computer_science) http://en.wikipedia.org/wiki/Processor_affinity