¿Cuántos subprocesos simultáneos en una aplicación son muchos?

Question

5, 100, 1000?

Supongo que "depende", pero ¿en qué?

¿Qué es común en las aplicaciones que se ejecutan como daemons/servicios de servidor?

¿Qué son los límites duros?

Dado que la máquina puede manejar la carga de trabajo general, ¿cómo determino en cuántos subprocesos la sobrecarga comienza a tener un impacto en el rendimiento?

¿Cuáles son las diferencias importantes entre los sistemas operativos?

¿Qué más se debe considerar?

Pregunto porque me gustaría utilizar hilos en una aplicación para organizar subcomponentes de mi aplicación que no comparten datos y están diseñados para hacer su trabajo en paralelo. Como la aplicación también usaría grupos de hilos para paralelizar algunas tareas, me preguntaba en qué punto debería comenzar a pensar sobre la cantidad de hilos que se ejecutarán en total.

Conozco la regla n + 1 como una guía para determinar el número de subprocesos que trabajan simultáneamente en la misma tarea para obtener rendimiento. Sin embargo, quiero usar hilos como uno podría usar procesos en un alcance mayor, i. mi. para organizar tareas independientes que no deberían interferir entre sí.

En this related question, algunas personas recomiendan minimizar el número de subprocesos debido a la complejidad añadida. Para mí, parece que los hilos también pueden ayudar a mantener las cosas ordenadas de forma más ordenada y reducir la interferencia. ¿No es eso correcto?

Answer 1

No puedo responder a su pregunta sobre "cuánto es mucho" pero acepto que no debe usar subprocesos para cada tarea posible.

óptimo cantidad de subprocesos para el rendimiento de la aplicación es (n + 1), donde n es la cantidad de procesadores/núcleos tiene su computadora/claster.

Cuanto más difiera la cantidad real de subprocesos de n + 1, menos óptima se vuelve y se desperdician los recursos de su sistema en los cálculos de subprocesos.

Por lo general, usted usa 1 hilo para la interfaz de usuario, 1 hilo para algunas tareas genéricas y (n + 1) hilos para algunas tareas de cálculo enorme.

Answer 2

La clase ThreadPool de Microsoft lo limita a 25 hilos por procesador. El límite se basa en context switching entre subprocesos y el memory consumed por cada subproceso. Entonces, esa es una buena guía si estás en la plataforma de Windows.

Answer 3

Actualmente Ajmastrean está un poco desactualizado. Citando de su propia piscina link

El hilo tiene un tamaño predeterminado de 250 subprocesos de trabajo por procesador disponible , y 1000 I/O de terminación hilos. El número de subprocesos en el grupo de subprocesos se puede cambiar utilizando el método SetMaxThreads.

Pero en general creo que 25 es realmente donde comienza a entrar en vigor la ley de los rendimientos decrecientes (y la capacidad de los programadores para realizar un seguimiento de lo que está sucediendo). Aunque Max tiene razón, mientras todos los hilos estén realizando cálculos no bloqueantes, n + 1 es el número óptimo, en el mundo real la mayoría de las tareas de subprocesamiento que realizo tienden a realizarse en cosas con algún tipo de IO.

Answer 4

También depende de su arquitectura. P.ej. en NVIDIA GPGPU lib CUDA puedes poner un hilo multiprocesador de 5 hilos 512 simultamente. Puede preguntar por qué asignar a cada uno de los procesadores escalares 64 hilos? La respuesta es fácil: si el cálculo no está vinculado a la computación sino a la IO de memoria encuadernado, puede ocultar las latencias de la memoria ejecutando otras discusiones. Similar se aplica a las CPU normales. Recuerdo que una recomendación para la opción paralela para make "-j" es usar aproximadamente 1.5 veces la cantidad de núcleos que obtuviste. Muchas de las tareas de compilación son pesadas carga IO y si una tarea tiene que esperar disco duro, mem ... lo que sea, CPU podría trabajar en un hilo diferente.

siguiente que tiene que tener en cuenta, lo caro que un cambio de tarea/hilo es. P.ej. es gratis, mientras que la CPU tiene que realizar algún trabajo para un cambio de contexto. Entonces, en general, debe estimar si la penalización para dos conmutadores de tarea es más larga que el tiempo que el subproceso bloquearía (lo cual depende en gran medida de sus aplicaciones).