¿Qué constituye el uso correcto de los hilos en la programación?

13

Estoy cansado de escuchar que la gente recomienda que use solo un subproceso por procesador, ¡mientras que muchos programas usan hasta 100 por proceso! Tomemos, por ejemplo, algunos programas comunes

vb.net ide uses about 25 thread when not debugging
System uses about 100
chrome uses about 19
Avira uses more than about 50

Cada vez que publico una pregunta relacionada con un subproceso, casi siempre me recuerdan que no debo usar más de un subproceso por procesador, y todos los programas que menciono anteriormente están arruinando mi sistema con un solo procesador.

    
pregunta Smith 29.06.2011 - 21:03

7 respuestas

22
  

debes usar solo un hilo por   procesador,

Posiblemente en HPC, donde quieres la máxima eficiencia, pero por lo demás, ¡es la cosa más estúpida que he escuchado hoy!

Debes usar la cantidad de subprocesos que sean apropiados para el diseño del programa y aún así dar un rendimiento aceptable.

Para un servidor web, podría ser razonable disparar un subproceso para cada conexión entrante (aunque hay mejores formas para servidores muy cargados).

Para un ide, cada herramienta que se ejecuta en su propio hilo no es irrazonable. Sospecho que muchos de los subprocesos informados para el IDE .Net son cosas como el registro y las tareas de E / S que se inician en sus propios subprocesos para que puedan continuar desbloqueados.

    
respondido por el Martin Beckett 29.06.2011 - 21:08
2

El consejo de un subproceso por núcleo se aplica cuando el propósito es la velocidad a través de la ejecución paralela.

Una razón completamente diferente e igualmente válida es la simplicidad del código cuando tiene que responder a eventos impredecibles. Entonces, si un programa tiene que escuchar en 100 sockets, y parece que le da toda su atención a cada uno, ese es un uso perfecto para subprocesos. Otro ejemplo es una interfaz de usuario, donde un subproceso controla los eventos de la interfaz de usuario, mientras que otro realiza el procesamiento en segundo plano.

    
respondido por el Mike Dunlavey 29.06.2011 - 21:17
2

Desea un hilo para cada cálculo que pueda proceder a velocidades diferentes a las de otros cálculos.

Para la computación paralela vinculada a la CPU, que viene en grandes bloques de trabajo, generalmente se desea un subproceso por CPU, porque una vez que todos están ocupados, más subprocesos no ayudan y solo crean la sobrecarga del programador. Si los bloques de trabajo tienen tamaños irregulares en el tiempo, o se generan dinámicamente en el tiempo de ejecución (a menudo sucede cuando tiene grandes estructuras de datos complejas para procesar), es posible que desee adjuntar esos bloques a muchos subprocesos, por lo que un programador siempre tiene una gran configurado para elegir cuando se complete algún bloque de trabajo, para mantener a todas las CPU ocupadas.

Para el cálculo de E / S enlazado, generalmente desea un subproceso para cada "canal" de E / S independiente, ya que se comunican a diferentes velocidades, y los subprocesos bloqueados en el canal no evitan que otros subprocesos progresen.

    
respondido por el Ira Baxter 29.06.2011 - 21:18
1

La regla de oro para los subprocesos es que desea que al menos un subproceso de trabajador "activo" (capaz de ejecutar sus comandos inmediatamente en el tiempo de CPU) para cada "unidad de ejecución" disponible en la computadora. Una "unidad de ejecución" es un procesador de instrucciones lógicas, por lo que un servidor Xeon de cuatro núcleos y de cuatro núcleos con hipervínculos tendría 32 EU (4 chips, 4 núcleos por chip, cada uno de ellos con hipervínculos). Tu Core i7 promedio tendría 8.

Un subproceso por UE es el mayor uso de la potencia de la CPU, siempre que los subprocesos siempre estén en estado de ejecución; este casi nunca es el caso, ya que los subprocesos necesitan acceso a la memoria no almacenada en caché, al disco duro, a los puertos de red, etc., que deben esperar y que no requieren atención activa de la CPU. Por lo tanto, puede aumentar aún más la eficiencia general con más subprocesos en cola y con muchas ganas de ir. Esto tiene un costo; cuando una CPU cambia un subproceso, debe almacenar en caché los registros del subproceso, el puntero de ejecución y otra información de estado que normalmente se guarda en el funcionamiento interno de una UE y se accede a él muy rápidamente, lo que permite que otras UE en el chip de la CPU lo detecten. También requiere hilos en el sistema operativo para decidir a qué hilo se debe cambiar. Por último, cuando una UE cambia los subprocesos, pierde las ganancias de rendimiento de la canalización que utilizan la mayoría de las arquitecturas de procesador; Tiene que limpiar la tubería antes de cambiar los hilos. Pero, como todo esto todavía lleva mucho menos tiempo en promedio que simplemente esperar a que el disco duro o incluso la RAM devuelvan información, vale la pena el costo.

Sin embargo, en general, una vez que supera el doble del número de subprocesos "activos" que los de la UE, el sistema operativo comienza a gastar más de los subprocesos de programación de tiempo de la UE, y los de la UE pasan más tiempo cambiando entre ellos, que realmente se gastan Ejecutando subprocesos activos de programas. Este es el punto de las deseconomías de escala; en realidad, tomará más tiempo para que se ejecute un algoritmo de subprocesos múltiples si tuviera que agregar un hilo adicional en este momento.

Por lo tanto, en general, desea mantener al menos tantos subprocesos en su programa como tener EU en la computadora, pero desea evitar tener más del doble de ese número que no está esperando o durmiendo.

    
respondido por el KeithS 29.06.2011 - 21:55
1

Deberías usar un hilo para:

Cada procesador que necesitas para mantenerte ocupado.

Cada E / S puede ser útil a la vez que no puede realizar de forma no bloqueante. (Por ejemplo, lee desde un disco local).

Cada tarea que requiere un subproceso dedicado, por ejemplo, llamar a una biblioteca que no tiene interfaz sin bloqueo o donde las interfaces sin bloqueo no son apropiadas. Esto incluye tareas como monitorear el reloj del sistema, disparar temporizadores, etc.

Algunos extras para proteger contra bloqueos inesperados, como fallas de página.

Algunos extras para proteger contra el bloqueo esperado que no vale la pena optimizar, por ejemplo, en código no crítico. (Por ejemplo, si rara vez necesita hacer una solicitud de DNS, probablemente no valga la pena el esfuerzo de hacer solicitudes de DNS de forma asíncrona. Simplemente cree algunos hilos adicionales y haga su vida más fácil).

Si sigue la regla "un subproceso por procesador", entonces todo su código es crítico para el rendimiento. Cualquier código que bloquee por alguna razón significa que su proceso no puede usar ese procesador. Eso hace que la programación sea mucho más difícil sin una buena razón.

    
respondido por el David Schwartz 15.08.2011 - 04:49
0

Puede generar procesos y subprocesos para habilitar la utilización de un sistema multiprocesador / multiprocesador para un solo programa, en cuyo caso no obtendrá ningún beneficio (al menos para el único programa) de tener más subprocesos \ procesos y luego núcleos.

O puede tener rutinas que sondean un evento que normalmente bloquea una ejecución adicional. En lugar de atar la CPU con el sondeo, puede crear un subproceso que permanecerá en estado inactivo hasta que el evento adecuado lo despierte. Este método es muy comúnmente usado en servidores web y colas de eventos GUI. La mayoría de los programas desean tener algún tipo de almacén de datos central (incluso si es su código de ejecución del programa) al que puedan acceder todos los subprocesos, por lo que supongo que es por eso que usan subprocesos sobre procesos.

    
respondido por el Peter Smith 29.06.2011 - 21:12
0

Las aplicaciones que mencionas rara vez están ejecutando todas esas decenas de hilos simultáneamente. La mayoría de ellos simplemente se sientan allí porque están en un grupo de subprocesos . La aplicación envía varias tareas a una cola, que se elimina mediante subprocesos en el grupo de subprocesos.

¿Por qué el tamaño de la piscina es tan grande? Debido a que, con frecuencia, los subprocesos tienen que esperar para otros recursos como el disco, la red, el usuario, algún otro subproceso, etc. Mientras un subproceso está esperando, es apropiado ejecutar otros subprocesos para utilizar completamente el procesador. Sin embargo, el tamaño adecuado de la piscina es complicado. Muy pocos subprocesos, y perderá el rendimiento porque el procesador no se utiliza completamente mientras espera algo. Demasiados subprocesos, y perderá el rendimiento al cambiar entre ellos.

    
respondido por el Joonas Pulakka 15.08.2011 - 10:43

Lea otras preguntas en las etiquetas