Pregunta Número óptimo de hilos mientras se realizan múltiples tareas


Sé que se han hecho preguntas similares, pero creo que mi caso es un poco diferente.

Digamos que tengo una computadora con 8 núcleos y memoria infinita con un sistema operativo Linux.

Tengo un software de cálculo llamado Gaussian que puede aprovechar el multihilo. Así que configuré su número de hilos en 8 para un solo cálculo para la velocidad máxima. Sin embargo, realmente no puedo decidir qué hacer cuando necesito ejecutar cálculos de instancia 8 simultáneamente. En ese caso, ¿debo establecer el número de hilos en 1 (8 hilos en total generados en 8 procesos) o mantenerlos en 8 (64 hilos en total generados en 8 procesos) para cada trabajo? ¿Realmente importa mucho? Una pregunta relacionada es, ¿el sistema operativo hace automáticamente el estacionamiento central a diferentes núcleos para cada hilo?

EDITAR: Sé que la evaluación comparativa es la mejor manera de saberlo. El caso es que las computadoras pertenecen a mi universidad, así que están ocupadas todo el tiempo. En otras palabras, su carga de trabajo varía de manera incontrolable para mí porque otras personas también están usando estas computadoras para sus cálculos, lo que hace que la experimentación sea imposible. Además, el software es muy caro (1500 $ o algo así) y tiene licencia para cada computadora, por lo que no puedo simplemente ejecutar un punto de referencia en mi computadora personal ...


4


origen


Respetando las respuestas (correctas y precisas) dadas, no hay garantía de que el programa funcione mejor con un número máximo de hilos que con uno solo (es decir, podría estar mejor programado para un solo hilo, algún hilo podría ralentizar el proceso) en general, etc.), aunque si está programado, debería. Como lo muestra el consenso general, lo mejor que se puede hacer es comparar cada configuración con un conjunto de pruebas limitado. - Doktoro Reichard
Deberías solo medirlo. - Der Hochstapler


Respuestas:


Idealmente, el recuento total de hilos para todos los trabajos debería ser el número de núcleos del sistema, excepto en los sistemas que admiten el subprocesamiento múltiple, en el que debería ser el doble del número de núcleos. Entonces, si el sistema no tiene hyper-threading, hay 8 cálculos en ejecución, cada uno debe ejecutarse en un hilo.

Muchos procesadores Intel vienen con hyper-threading, por lo que cada núcleo puede admitir dos hilos. Por ejemplo, un sistema de 8 núcleos que admite hyper-threading debe tener 16 hilos para utilizar el sistema por completo.


5





La respuesta depende de lo que hace el proceso y cómo se programó su multi-threading, lo que significa que tendrá que experimentar.

Si el proceso usa semáforos y otros mecanismos de exclusión para contención entre los hilos en los recursos comunes (como la memoria), entonces menos es el número de hilos en el proceso, menor será el número de conflictos que causarán esperas.

Durante una espera, el hilo no hace nada, por lo que la espera tendrá un efecto negativo en el rendimiento. En este caso, más procesos y menos subprocesos por proceso mejorarán el rendimiento, entonces 8x8 tendrá un mejor rendimiento que 1x64.

Por otro lado, si cada hilo está totalmente aislado y no hay un campo común compartido recursos, entonces el sistema operativo programará los hilos sin distinción entre los dos casos de 8x8 o 1x64. En este caso, solo el número total de subprocesos es importante para el rendimiento total, por lo que ambos casos son de igual rendimiento.


3



Como su actualización dice que las computadoras están muy ocupadas, entonces demasiados hilos tendrán el efecto opuesto de ralentizar la computadora. Cambiar la CPU entre hilos es una operación costosa. - harrymc


El número correcto depende de cuánto tiempo pasan los procesos bloqueados en IO.

El libro "Concurrencia de programación en la JVM" contiene buena información al respecto:

"Determinar el número de hilos". Para un problema grande, nos gustaría tener al menos tantos hilos como la cantidad de núcleos disponibles. Esto asegurará que tantos núcleos como estén disponibles para el proceso se pongan a trabajar para resolver nuestro problema ...

Por lo tanto, la cantidad mínima de subprocesos es igual a la cantidad de núcleos disponibles. Si todas las tareas son intensivas en computación, esto es todo lo que necesitamos. Tener más hilos de hecho lastimará en este caso porque los núcleos cambiarían de contexto entre hilos cuando todavía hay trabajo por hacer. Si las tareas son intensivas en IO, entonces deberíamos tener más hilos.

Cuando una tarea realiza una operación IO, su hilo se bloquea. El procesador inmediatamente cambia de contexto para ejecutar otros hilos eligables. Si solo tuviéramos tantos hilos como la cantidad de núcleos disponibles, aunque tengamos tareas que realizar, no se podrán ejecutar porque no los hemos programado en hilos para que los procesadores los recojan.

Si las tareas pasan el 50 por ciento del tiempo bloqueadas, entonces la cantidad de hilos debería ser el doble de la cantidad de núcleos disponibles. Si pasan menos tiempo bloqueados, es decir, consumen gran cantidad de cómputo, entonces deberíamos tener menos hilos, pero no menos que la cantidad de núcleos. Si pasan más tiempo bloqueados, es decir, son IO intensivos, entonces deberíamos tener más hilos, específicamente, varios múltiplos del número de núcleos.

Entonces podemos calcular la cantidad total de hilos que necesitaríamos de la siguiente manera:

Número de subprocesos = Número de núcleos disponibles / (1 - Coeficiente de bloqueo)

Si necesita ejecutar múltiples cálculos simultáneamente, tal vez vea si es posible ejecutarlos dentro de un proceso con un grupo de subprocesos que tenga el tamaño adecuado.

De lo contrario, si tiene la cantidad óptima de hilos para un cálculo, pero luego ejecuta 8 a la vez, es posible que tenga demasiados.

La mejor solución es compararla experimentalmente.

No estoy exactamente seguro de lo que quiere decir con "core-parking", pero la CPU tenderá a seguir utilizando el mismo hilo en un núcleo dado por razones de caché, aunque también lo moverá a veces por diferentes razones de calor / energía. Puedes investigar esto usando una herramienta como htop.


2



El caso es que las computadoras pertenecen a mi universidad, así que están ocupadas todo el tiempo. En otras palabras, su carga de trabajo varía de manera incontrolable para mí porque otras personas también están usando esas computadoras para sus cálculos, lo que hace que la experimentación sea imposible. - theGD
I / O está lejos de ser el único recurso compartido entre subprocesos. - harrymc


Usted ha respondido la pregunta ustedes mismos. "las computadoras pertenecen a mi universidad, así que están ocupadas todo el tiempo"

De hecho, solo obtienes una porción de los procesadores. Para hacer el trabajo de la manera más eficiente, la sobrecarga de la tarea de conmutación y multiplexación, y los recursos en espera se deben minimizar. Por lo tanto, siempre se debe considerar hacer un solo hilo.

Multi-threading siempre menos eficiente cuando se calcula en función de "potencia de procesamiento" debido a la sobrecarga de conmutación de contexto. Solo acelera los problemas para utilizar todos los recursos desocupados "gratuitos". idea: use 8 computadoras para correr un problema probablemente 7,9 veces más rápido, que nunca puede ser más de 8.

Si todos estos están dedicados a usted, simplemente hágalo en paralelo para acelerar, si no, manténgalo solo y deje que otros usen el núcleo restante para otro trabajo.

por cierto, de una manera egoísta, hay una herramienta de sombrero rojo que llama a la cuadrícula que puede dividir su trabajo en todo el Linux sobre el campus. (> 200). Funcionará tan rápido, simplemente no te atrapen, ya que ralentizará a todos. o usa las herramientas antiguas, mathlab paralelo.


1