¿Cómo elijo la mejor cantidad de hilos para hyptherthreading/multicore?

Question

Tengo un trabajo vergonzosamente paralelizable en una aplicación de consola .NET 3.5 y quiero aprovechar los procesadores hyperthreading y multi-core. ¿Cómo selecciono el mejor número de subprocesos de trabajo para utilizar cualquiera de estos los mejores en un sistema arbitrario? Por ejemplo, si es un núcleo doble, querré 2 hilos; quad core. Querré 4 hilos. Lo que finalmente busco es determinar las características del procesador para poder saber cuántos hilos crear.

No estoy preguntando cómo dividir el trabajo ni cómo hacerlo, me pregunto cómo puedo determinar el número "óptimo" de subprocesos en una máquina arbitraria en la que se ejecutará esta aplicación de consola.

Answer 1

Puede utilizar Environment.ProcessorCount si eso es lo único que está buscando. Pero usualmente usar una ThreadPool es la mejor opción.

El grupo de subprocesos .NET también tiene disposiciones para asignar en ocasiones más subprocesos que los que tiene núcleos para maximizar el rendimiento en ciertos escenarios donde muchos subprocesos están esperando a que termine la E/S.

Answer 2

Le sugiero que no intente determinarlo usted mismo. Use ThreadPool y deje que .NET administre los hilos por usted.

Answer 3

La única forma es una combinación de datos y análisis de código basado en datos de rendimiento.

Diferentes familias de CPU y velocidades vs. velocidad de la memoria frente a otras actividades en el sistema todos van a realizar la puesta a punto diferente.

potencialmente un poco de auto-tuning es posible, pero esto va a significar tener algún tipo de ajuste de rendimiento en vivo y autoajuste.

Answer 4

Se puede argumentar que la verdadera manera de elegir el mejor número de hilos es de aplicación a perfilarse de forma adaptativa y cambiar su comportamiento roscado sobre la base de lo que le da el mejor rendimiento.

Answer 5

He leído algo sobre esto recientemente (véase la respuesta aceptada a this question por ejemplo).

La respuesta simple es que deja que el sistema operativo decida. Puede hacer un mejor trabajo al decidir qué es lo mejor que puedes.

Hay una serie de preguntas sobre un tema similar: la búsqueda de "hilos de número óptimo" (sin las comillas) le da un par de páginas de resultados.

Answer 6

Escribí una aplicación simple de crujido de números que utilizaba varios subprocesos, y descubrí que en mi sistema Quad-core completaba la mayor parte del trabajo en un período fijo utilizando 6 subprocesos.

Creo que la única manera real de determinarlo es a través de la comprobación o la creación de perfiles.

Answer 7

Una buena regla del pulgar, dado que usted está completamente vinculado a la CPU, es processorCount+1.

Eso es porque siempre se obtendrá algunas tareas arrancado/parado/interrumpe y n tareas será casi nunca se llene por completo n procesadores.

Answer 8

Yo diría que también depende de lo que esté haciendo, si hace una aplicación de servidor y usa todo lo que puede de la CPU a través de Environment.ProcessorCount o un grupo de subprocesos es una buena idea. Pero si esto se está ejecutando en un escritorio o en una máquina que no está dedicada a esta tarea, es posible que desee dejar algo de CPU inactiva para que la máquina "funcione" para el usuario.

Answer 9

El número óptimo sería simplemente el recuento del procesador. De manera óptima, siempre tendría un hilo ejecutándose en una CPU (lógica o física) para minimizar los cambios de contexto y la sobrecarga que lleva consigo.

Si ese es el número correcto depende (como todo el mundo ha dicho) de lo que está haciendo. The threadpool (si lo entiendo correctamente) prácticamente intenta usar el menor número de subprocesos posible, pero genera uno más cada vez que se bloquea un hilo.

El bloqueo nunca es óptimo, pero si está realizando alguna forma de bloqueo, la respuesta cambiará drásticamente.

La forma más sencilla y fácil de obtener un buen comportamiento (no necesariamente óptimo) es usar el grupo de subprocesos. En mi opinión, es realmente difícil hacer algo mejor que el grupo de temas, por lo que es simplemente el mejor lugar para comenzar y solo pensar en otra cosa si puedes demostrar por qué no es lo suficientemente bueno.

Answer 10

O incluso mejor que el ThreadPool, utilice instancias de tareas de .NET 4.0 del TPL. La Biblioteca de tareas paralelas está construida sobre una base en el marco .NET 4.0 que realmente determinará la cantidad óptima de subprocesos para realizar las tareas de la manera más eficiente posible para usted.

Answer 11

El número correcto es obviamente 42.

Ahora en la nota seria. Solo usa el grupo de subprocesos, siempre.

1) Si usted tiene una larga procesamiento tarea (es decir. CPU) que puede ser dividida en varias comidas pieza de trabajo, entonces debería particionar su tarea y presentar todos los elementos de trabajo individuales a la ThreadPool. El grupo de subprocesos recogerá los elementos de trabajo y comenzará a producirlos de forma dinámica, ya que tiene capacidades de autocontrol que incluyen iniciar nuevos subprocesos según sea necesario y pueden ser configured at deployment by administrators according to the deployment site requirements, en lugar de precalcular los números en el momento del desarrollo. Si bien es cierto que el tamaño de partición adecuado de su tarea de procesamiento puede tener en cuenta la cantidad de CPU disponibles, la respuesta correcta depende tanto de la naturaleza de la tarea y de los datos que ni siquiera vale la pena mencionar en esta etapa (y además las principales preocupaciones deberían ser su NUMA nodes, localidad de memoria y contención de caché interbloqueada, y solo después de eso, la cantidad de núcleos).

2) Si está realizando E/S (incluidas las llamadas a bases de datos), entonces debe usar E/S asincrónica y completar las llamadas en ThreadPool denominadas rutinas de finalización.

Estas dos son las únicas razones válidas por las que debe tener varios subprocesos, y ambos se manejan mejor con el ThreadPool. Cualquier otra cosa, incluido el inicio de un hilo por 'solicitud' o 'conexión', es de hecho anti patrones en el mundo API de Win32 (fork es un patrón válido en * nix, pero definitivamente no en Windows).

Para una más especializada y forma, la discusión de forma más detallada del tema sólo puedo recomendar los papeles Rick Vicik sobre el tema:

• designing-applications-for-high-performance-part-1.aspx
• designing-applications-for-high-performance-part-ii.aspx
• designing-applications-for-high-performance-part-iii.aspx

Answer 12

Además del recuento del procesador, es posible que desee tener en cuenta la afinidad del procesador del proceso al contar bits en la afinidad máscara devuelta por la función GetProcessAffinityMask.

Answer 13

Si no hay un excesivo procesamiento de E/S o llamadas al sistema cuando los subprocesos están en ejecución, entonces el número de subprocesos (excepto el subproceso principal) es en general igual al número de procesadores/núcleos en su sistema, de lo contrario puede intentar aumentar el número de subprocesos probando.