2011-03-09 9 views
7

He estado jugando con el subprocesamiento, intentando llevar algunos límites al extremo, para mi propia diversión. Sé que el subproceso está predeterminado en 25 subprocesos y puede enviarse hasta 1000 (según MSDN). Sin embargo, ¿cuál es el límite práctico de hilos por núcleo de CPU? En algún punto, el cambio de contexto va a causar más de un cuello de botella que el de guardar. ¿Alguien tiene alguna de las mejores prácticas que cubre esto? ¿Estamos hablando de 100, 200, 500? ¿Depende de lo que están haciendo los hilos? Lo que determina, además de la arquitectura dictada por el marco, ¿cuántos subprocesos funcionan de manera óptima por núcleo de CPU?¿Cuál es el límite práctico de hilos por CPU?

+7

http://stackoverflow.com/questions/1718465/optimal-number-of-threads-per-core - esto podría responder algunas consultas mientras espera las respuestas aquí :) – dotalchemy

+0

@dotalchemy - gracias, información anecdótica es por lo general bastante útil; Hubo algunas buenas ideas allí. Será interesante ver si alguien obtiene información sobre las mejores prácticas. – BobTheBuilder

+0

42. Por supuesto ... –

Respuesta

8

Todo depende de lo que están haciendo los hilos, por supuesto. Si están vinculados a la CPU (por ejemplo, permanecer sentados en un bucle infinito), un hilo por núcleo será suficiente para saturar la CPU; más que eso (y ya tendrás más, de procesos en segundo plano, etc.) y comenzarás a obtener contienda.

En el otro extremo, si los hilos no son aptos para ejecutarse (por ejemplo, bloqueados en algún objeto de sincronización), entonces el límite de cuántos podría tener estaría dictado por factores distintos a la CPU (memoria para las pilas, Límites internos del sistema operativo, etc.).

7

Si su aplicación no está unida a la CPU (como la mayoría), los cambios de contexto no son un gran problema porque cada vez que su aplicación tiene que esperar, es necesario un cambio de contexto. El problema de tener demasiados hilos es sobre las estructuras de datos del sistema operativo y algunas anomalías de sincronización como la inanición, donde un hilo nunca (o muy raramente) tiene la oportunidad de ejecutarse debido a la aleatoriedad de los algoritmos de sincronización.

Si su aplicación está vinculada a la CPU (permanece 99% de tiempo trabajando en memoria, muy raramente hace E/S o espera algo más como entrada de usuario u otro hilo), entonces lo óptimo sería 1 hilo por núcleo lógico , porque en este caso no habrá cambio de contexto.

Tenga en cuenta que el sistema operativo interrumpe los hilos cada vez, incluso cuando solo hay un hilo para varias CPU. El sistema operativo interrumpe los hilos no solo para hacer cambios de tareas, sino también para fines de gestión de hilos (como actualizar contadores para mostrar en el Administrador de tareas o para permitir que un superusuario los mate).

+0

Digamos que está haciendo cosas habituales en la línea de negocios, como recibir datos de socket y transmitir a gran velocidad en una base de datos de alguna descripción, por ejemplo, SQL Server. Teóricamente, .NET no manejaría E/S en el verdadero sentido: podría estar volcando SqlBulkCopy en SQL Server. – BobTheBuilder

+0

Simplemente ejecutando el sistema operativo, ya hay una gran cantidad de hilos flotando. Entonces, un hilo por núcleo es sí óptimo, pero nunca sucede en realidad. No veo cuál es el punto de saber cuál sería el número óptimo de hilos por núcleo ... tu aplicación no es la única en ejecución. –

+2

@Joel Gauvreau Llámalo curiosidad. No es por eso que terminamos en este trabajo en primer lugar. Una sed de conocimiento y comprensión ... así que mi respuesta a "¿qué sentido tiene saber?" es "solo para saber". – BobTheBuilder

Cuestiones relacionadas