2011-01-28 19 views
16

Un comentario en another of my questions dice que solo puedo ejecutar "demasiados" hilos de manera concurrente, una noción que he visto en otra parte.¿Cuántos subprocesos puedo ejecutar al mismo tiempo?

Como novato en roscado, ¿cómo puedo determinar el número máximo de hilos para usar? ¿O se trata de un "cuánto tiempo es una pieza de cadena" pregunta? ¿De qué depende? Configuración de hardware o qué?

(VB en MS Visual Studio .Net con 3.5, si lo que importa)


Actualización: es cualquier persona al tanto de cualquier s/w herramienta que podría sugerir un número de hilos (o tareas), o ¿Debería codificar el mío que sigue probando diferentes números hasta que caiga el rendimiento?


[Upperdate] Casi siete años después & ahora tenemos a software recommendations site, así que asked si hay una herramienta para ayudar con esto.

+2

¿Qué están haciendo los hilos? –

+1

+1 buena pregunta. Cada uno de ellos realiza una llamada SOAP para transmitir datos soem y espera a que vuelva – Mawg

+1

Excepto, por supuesto, que el "retorno" es asincrónico, por lo que realmente no están esperando. Otros hilos pueden ejecutarse tan pronto como la solicitud SOAP (llamada de confirmación) se envíe a través de HTTP – Mawg

Respuesta

9

Depende del hardware, ya que (probablemente) no está utilizando una computadora teórica sino una de hardware físico, por lo que tiene recursos limitados.

Leer: Does Windows have a limit of 2000 threads per process?

Además, incluso si usted podría funcionar 5000+ hilos, dependiendo de su hardware, que podría funcionar mucho más lento que un programa equivalente 10 hilo. Creo que deberías echarle un vistazo al thread pooling.

+1

+1 Gracias. Eso me da algo que mirar y comenzar a tratar de entender. ¿Conoce alguna herramienta s/w que pueda sugerir varios hilos? – Mawg

+2

Supongo que el uso de un hilo por núcleo de CPU es una elección sensata, pero realmente depende del problema que está tratando de resolver. – Trinidad

+1

+1 Con uno por núcleo será difícil simular cientos de dispositivos – Mawg

2

Depende mucho de la máquina: la CPU y la memoria son los principales factores limitantes (aunque los límites del sistema operativo pueden entrar en ella).

Con respecto a .NET, la configuración thread pool también entra en juego.

+0

+1 Gracias por los comentarios – Mawg

8

Normalmente, el número de subprocesos que se ejecutan de manera verdaderamente simultánea viene determinado por la cantidad de CPU y núcleos de CPU (incluido el subprocesamiento) que tiene. Es decir que en un momento dado, el número de subprocesos en ejecución (en el sistema operativo) es igual al número de "núcleos".

El número de subprocesos que puede ejecutar simultáneamente en su aplicación depende de una gran cantidad de factores. El mejor número (del profano) sería el número de núcleos en la máquina, pero por supuesto eso es como pretender que no existe nadie (ninguna otra aplicación) :).

Francamente, yo diría que estudiar mucho más sobre multi-threading en .NET/Windows porque uno tiende a hacer más "daño" que bien cuando uno no tiene una comprensión realmente sólida. .NET tiene el concepto de un grupo de subprocesos y necesita saber cómo funciona eso además de Windows.

En .NET 3.5/4.0 debería estar buscando en Tareas (Task Parallel Library) ya que la biblioteca hace un trabajo mucho mejor para determinar cuántos hilos (si es que lo hace) para engendrar. Con el TPL, el threadpool obtiene una revisión importante y es mucho más inteligente sobre los hilos de desove y el robo de tareas, etc. Pero normalmente se trabaja con tareas y no con subprocesos.

Este es un área compleja y como resultado, .NET framework introdujo Tareas para abstraer programadores de subprocesos y por lo tanto permitir que el tiempo de ejecución sea inteligente al respecto mientras el programador simplemente dice lo que quiere y no tanto acerca de cómo hacerlo.

+1

+1 Sí, temo que podría hacer más daño que bien. También veré las tareas, gracias – Mawg

+2

. Es útil, me parece, distinguir entre los términos "simultaneidad" y "paralelismo" (es decir, lo que usted denominó "verdaderamente concurrente"). – skaffman

+0

+1 buen punto, gracias – Mawg

7

Cada hilo consume más memoria (pila de kernel, bloque de entorno de hilo, thread-local, pila ....).AFAIK no hay límite explícito en Windows, por lo tanto, la restricción será memoria (probablemente la pila para cada hilo).

En las discusiones de Linux son más como procesos (con memoria compartida) y ya está limitada por:

cat /proc/sys/kernel/threads-max 
+0

+ tahnks por la información – Mawg

+0

Respuesta impresionante, +1 por la sugerencia de la línea de comando – ShellFish

0

yo era capaz de correr 4 hilos a la vez en mi CPU edad actual (2005) El uso de la CPU de EVGA Quemador antes de que mi zumbador de la CPU sonara apagado (Programado dentro del menú de la BIOS) Lo que significa que toco más de 90 * c. Tenga en cuenta que estamos hablando de hilos de datos trabajando todos a la vez. un buen ejemplo sería tener múltiples programas abiertos a la vez. Pero en general, realmente depende de cuán buena sea tu CPU con la multitarea. (En otras palabras, puede manejar muchos hilos activos) Una forma segura de probar es descargar "ocscanner (Por EVGA)" y "Termómetro de CPU" usar el quemador de la CPU dentro del OC Escáner Mientras prueba, asegúrese de que su temperatura no supere los 90 * c (o cualquier temperatura en la que se sienta seguro) y observe su número actual de hilos que ha ejecutado lanzó su CPU. comience en 2 hilos, espere 3-5 minutos mientras mira la temperatura de la CPU, agregue otro hilo, repita. (¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡NO INTENTE SI EL TERMÓMETRO DE LA CPU NO PUEDE DETECTAR SU TEMPERATURA !!!)

3

Una regla bastante buena para ejecutar tareas intensivas es ejecutar el mismo número que su núcleo físico contar.

Sí, puede ejecutar más tareas, pero esperarán recursos (o subprocesos en un grupo de subprocesos) y su casilla, independientemente de su tamaño, no puede asignar todos los recursos centrales de la CPU el 100% del tiempo a un hilo debido a procesos de fondo/otros. Por lo tanto, cuantas más tareas instaure, cuantos más hilos genere, a medida que superen los posibles hilos simultáneos posibles (1 por núcleo), más gestión de recursos, colas e intercambios ocurrirá.

Una prueba que hicimos donde trabajo ahora utilizando un patrón viral para iniciar tareas adicionales encontró que lo óptimo era bastante cercano al recuento de la CPU como límite. Las tareas iniciadas en una proporción de uno a uno con el recuento de núcleos físicos se ejecutaron en aproximadamente 1 minuto por tarea para completarse. Establecido en el doble del recuento de CPU, el tiempo de la tarea pasó de 1 minuto promedio a aproximadamente 5 minutos de tiempo promedio para completar. Se vuelve geométricamente más lento cuanto más tareas se inicien después del recuento de núcleos.

Así, por ejemplo, si tiene 8 núcleos físicos, 8 tareas (y usar TPL, esencialmente 8 subprocesos concurrentes en proceso activo) deberían ser las más rápidas. Existe el hilo o proceso principal que crea las otras tareas y otros procesos en segundo plano, pero si el cuadro está bastante aislado para el placer de la explotación de recursos, estos serán bastante mínimos.

La ventaja de programar su límite de tareas basado en el recuento de núcleos mientras mastica las tareas de una cola o lista para que cuando implemente la aplicación en cajas de diferentes tamaños, se ajuste automáticamente.

Para determinar esto mediante programación, utilizamos

var CoreCount = System.Environment.ProcessorCount/2;

Por qué dividir por dos, lo preguntas? Porque casi todos los procesadores modernos usan núcleos lógicos o hyperthreading. Con sus propias pruebas, debe encontrar que si usa el conteo lógico, su velocidad general por tarea y, por lo tanto, todo el proceso, disminuirá significativamente. Núcleos físicos es la clave. No pudimos ver una forma rápida de encontrar física vs lógica, pero una encuesta rápida de nuestras casillas encontró que esto era consistentemente cierto. YMMV, pero esto podría llegar bastante rápido.

1

Según mi propia experiencia, cuando se utilizan subprocesos, una buena regla general para un mayor rendimiento de los procesos vinculados a la CPU es utilizar un número igual de subprocesos como núcleos, excepto en el caso de un sistema hiperproceso, en cuyo caso uno debería use el doble de núcleos La otra regla de oro que se puede concluir es para procesos vinculados de E/S.Esta regla es cuadruplicar el número de subprocesos por núcleo, excepto en el caso de un sistema de hiperproceso, luego se puede cuadruplicar el número de subprocesos por núcleo.

+0

Lolx - cuando publiqué por primera vez, no existía una CPU multi-core :-) Gracias por el consejo +1 – Mawg

Cuestiones relacionadas