Número óptimo de roscas por núcleo

Estoy de acuerdo con la respuesta de @Gonzalo. Tengo un proceso que no hace E / S, y esto es lo que he encontrado:

Tenga en cuenta que todos los subprocesos funcionan en una matriz pero diferentes rangos (dos subprocesos no acceden al mismo índice), por lo que los resultados pueden diferir si han trabajado en diferentes matrices.

La máquina 1.86 es un macbook air con un SSD. El otro mac es un iMac con un disco duro normal (creo que es de 7200 rpm). La máquina Windows también tiene un disco duro de 7200 rpm.

En este prueba, el número óptimo era igual al número de núcleos en la máquina.

Sé que esta pregunta es bastante antigua, pero las cosas han evolucionado desde 2009.

Hay dos cosas a tener en cuenta ahora: el número de núcleos y el número de subprocesos que pueden ejecutarse dentro de cada núcleo.

Con los procesadores Intel, el número de subprocesos se define por el Hyperthreading que es solo 2 (cuando esté disponible). Pero Hyperthreading reduce el tiempo de ejecución en dos, incluso cuando no se utilizan 2 hilos! (es decir, 1 tubería compartida entre dos procesos this esto es bueno cuando se tiene más procesos, no tan buenos de lo contrario. ¡Más núcleos son definitivamente mejores!)

En otros procesadores puede tener 2, 4 o incluso 8 hilos. Así que si tienes 8 núcleos cada uno de los cuales soporta 8 hilos, podrías tener 64 procesos corriendo en paralelo sin cambiar de contexto.

"Sin cambio de contexto" obviamente no es cierto si se ejecuta con un sistema operativo estándar que hará cambio de contexto para todo tipo de otras cosas fuera de su control. Pero esa es la idea principal. Algunos OS dejan usted asigna procesadores para que solo su aplicación tiene acceso / uso de dicho procesador!

Desde mi propia experiencia, si tienes una gran cantidad de E/S, múltiples hilos es bueno. Si tienes un trabajo intensivo de memoria muy pesado (leer fuente 1, leer fuente 2, computación rápida, escribir), entonces tener más subprocesos no ayuda. Nuevamente, esto depende de la cantidad de datos que lea/escriba simultáneamente (es decir, si usa SSE 4.2 y lee valores de 256 bits, eso detiene todos los subprocesos en su paso... en otras palabras, 1 hilo es probablemente mucho más fácil de implementar y probablemente casi tan rápido si no realmente más rápido. Esto dependerá de su arquitectura de proceso y memoria, algunos servidores avanzados administran rangos de memoria separados para núcleos separados, por lo que los subprocesos separados serán más rápidos suponiendo que sus datos se archiven correctamente... es por eso que, en algunas arquitecturas, 4 procesos se ejecutarán más rápido que 1 proceso con 4 subprocesos.)

El rendimiento real dependerá de cuánto rendimiento voluntario hará cada hilo. Por ejemplo, si los subprocesos no hacen E/S en absoluto y no utilizan servicios del sistema (es decir, están 100% vinculados a la cpu), entonces 1 subproceso por núcleo es el óptimo. Si los hilos hacen algo que requiera espera, entonces tendrás que experimentar para determinar el número óptimo de hilos. 4000 hilos incurrirían en una sobrecarga de programación significativa, por lo que probablemente tampoco sea óptima.

La respuesta depende de la complejidad de los algoritmos utilizados en el programa. Se me ocurrió un método para calcular el número óptimo de hilos haciendo dos mediciones de los tiempos de procesamiento Tn y Tm para dos número arbitrario de hilos 'n' y 'm'. Lineal algoritmos, el número óptimo de threads será N = sqrt ( (mn(Tm*(n-1) – Tn*(m-1)))/(nTn-mTm) ) .

Por favor, lea mi artículo sobre los cálculos del número óptimo para varios algoritmos: pavelkazenin.wordpress.com

4000 hilos a la vez es bastante alto.

La respuesta es sí y no. Si estás haciendo muchas E/S de bloqueo en cada subproceso, entonces sí, podrías mostrar aceleraciones significativas haciendo hasta probablemente 3 o 4 subprocesos por núcleo lógico.

Sin embargo, si no está haciendo un montón de cosas de bloqueo, entonces la sobrecarga adicional con threading solo lo hará más lento. Así que use un perfilador y vea dónde están los cuellos de botella en cada pieza posiblemente paralela. Si usted está haciendo cálculos pesados, entonces más de 1 hilo por CPU no ayudará. Si está haciendo una gran cantidad de transferencia de memoria, tampoco ayudará. Si está haciendo una gran cantidad de E/S, como para el acceso al disco o el acceso a Internet, entonces sí, múltiples hilos ayudarán hasta cierto punto, o al menos harán que la aplicación sea más sensible.

Pensé en añadir otra perspectiva aquí. La respuesta depende de si la pregunta está asumiendo una escala débil o fuerte.

De Wikipedia:

Escala débil: cómo el tiempo de solución varía con el número de procesadores para un tamaño de problema fijo por procesador.

Escalado fuerte: cómo el tiempo de solución varía con el número de procesadores para un tamaño de problema total fijo.

Si la pregunta está asumiendo una escala débil, entonces La respuesta de @Gonzalo es suficiente. Sin embargo, si la pregunta está asumiendo una escala fuerte, hay algo más que agregar. En strong scaling, asumes un tamaño de carga de trabajo fijo, por lo que si aumentas el número de subprocesos, el tamaño de los datos en los que cada subproceso necesita trabajar disminuye. En las CPU modernas, los accesos a la memoria son caros y sería preferible mantener la localidad manteniendo los datos en cachés. Por lo tanto, se puede encontrar el número óptimo probable de hilos cuando el conjunto de datos de cada el hilo encaja en la caché de cada núcleo (No voy a entrar en los detalles de discutir si se trata de caché L1/L2/L3 (s) del sistema).

Esto es cierto incluso cuando el número de hilos excede el número de núcleos. Por ejemplo, supongamos que hay 8 unidades arbitrarias (o AU) de trabajo en el programa que se ejecutará en una máquina de 4 núcleos.

Caso 1: ejecutar con cuatro hilos donde cada hilo necesita completar 2AU. Cada hilo tarda 10 segundos en completarse (con un montón de errores de caché). Con cuatro núcleos la cantidad total de tiempo será de 10s ( 10s * 4 hilos / 4 núcleos).

Caso 2: ejecutar con ocho hilos donde cada hilo necesita completar 1AU. Cada hilo toma solo 2s (en lugar de 5s debido a la reducción de la cantidad de errores de caché). Con ocho núcleos, la cantidad total de tiempo será de 4s ( 2s * 8 hilos / 4 núcleos).

He simplificado el problema e ignorado los gastos generales mencionados en otras respuestas (por ejemplo, contexto switches), pero espero que llegue el punto de que podría ser beneficioso tener más número de hilos que el número disponible de núcleos, dependiendo del tamaño de los datos que está tratando.

Benchmark.

Comenzaría a aumentar el número de subprocesos para una aplicación, comenzando en 1, y luego iría a algo así como 100, ejecutaría tres o cinco pruebas para cada número de subprocesos, y construiría un gráfico de velocidad de operación vs.número de subprocesos.

Debe que el caso de cuatro subprocesos sea óptimo, con ligeros aumentos en el tiempo de ejecución después de eso, pero tal vez no. Puede ser que su aplicación tenga un ancho de banda limitado, es decir, el conjunto de datos que está cargando en la memoria es enorme, muchos errores de caché, etc., de modo que 2 hilos son óptimos.

No puedes saberlo hasta que lo pruebes.

Encontrará cuántos hilos puede ejecutar en su máquina ejecutando el comando htop o ps que devuelve el número de procesos en su máquina.

Puede usar la página man sobre el comando 'ps'.

man ps

Si desea calcular el número de todos los procesos de usuarios, puede usar uno de estos comandos:

1. ps -aux| wc -l
2. ps -eLf | wc -l

Calculando el número de un proceso de usuario:

1. ps --User root | wc -l

También, puede utilizar "htop" [Referencia]:

Instalación en Ubuntu o Debian:

sudo apt-get install htop

Instalación en Redhat o CentOS:

yum install htop
dnf install htop      [On Fedora 22+ releases]

Si desea compilar htop a partir del código fuente, lo encontrará aquí.

Lo ideal es 1 hilo por núcleo, siempre y cuando ninguno de los hilos se bloquee.

Un caso en el que esto puede no ser cierto: hay otros subprocesos que se ejecutan en el núcleo, en cuyo caso más subprocesos pueden dar a su programa una porción más grande del tiempo de ejecución.

Un ejemplo de muchos subprocesos ("thread pool") frente a uno por núcleo es el de implementar un servidor web en Linux o en Windows.

Dado que los sockets se sondean en Linux, muchos subprocesos pueden aumentar la probabilidad de que uno de ellos sondee el socket correcto en el momento adecuado, pero el costo total de procesamiento será muy alto.

En Windows, el servidor se implementará utilizando Puertos de finalización de E/S-IOCPs-que harán que la aplicación sea impulsada por eventos: si una E/S completa el sistema operativo lanza un hilo stand-by para procesarlo. Cuando el procesamiento se ha completado (generalmente con otra operación de E / S como en un par solicitud-respuesta), el subproceso regresa al puerto IOCP (cola) para esperar la siguiente finalización.

Si no se ha completado ninguna E/S, no se realizará ningún procesamiento y no se iniciará ningún subproceso.

De hecho, Microsoft recomienda no más de un subproceso por núcleo en implementaciones de IOCP. Cualquier E / S puede adjuntarse al mecanismo del IOCP. IOCs también puede ser publicado por el aplicación, si es necesario.

Hablando desde el punto de vista de la computación y la memoria (computación científica) 4000 hilos harán que la aplicación se ejecute realmente lenta. Parte del problema es una sobrecarga muy alta de cambio de contexto y muy probablemente una localidad de memoria muy pobre.

Pero también depende de su arquitectura. Desde donde escuché que se supone que los procesadores Niagara son capaces de manejar múltiples hilos en un solo núcleo utilizando algún tipo de técnica avanzada de canalización. Sin embargo no tengo experiencia con esos procesador.

Espero que esto tenga sentido, Compruebe la utilización de la CPU y la memoria y ponga algún valor de umbral. Si se cruza el valor de umbral, no permita crear un nuevo hilo de lo contrario permitir...