.NET 4 Parallel.ForEach y PLINQ: ¿pueden abrumar el grupo de subprocesos y matar el rendimiento de la aplicación?

Question

Cuanto más uso Parallel.ForEach y PLINQ en mi código, más respuestas de revisión de caras y códigos estoy obteniendo. Entonces, me pregunto si hay alguna razón para que NO use PLINQ, en extremo, en cada declaración LINQ. ¿Puede el tiempo de ejecución no ser lo suficientemente inteligente como para comenzar a generar tantos hilos (o consumir tantos hilos del grupo de subprocesos) que el rendimiento de la aplicación realmente se degradaría en lugar de mejorar? La misma pregunta se aplica a la biblioteca de Parallel.

Entiendo las implicaciones relacionadas con la seguridad de hilos y la sobrecarga de usar multihilo. También me doy cuenta de que no todo es bueno para paralelizar. Todo lo que me pregunto es si debería dejar de defender mis enfoques y renunciar a estas dos cosas buenas porque mis compañeros piensan que será mejor que yo mismo controle el hilo en lugar de confiar en las instalaciones de .NET.

ACTUALIZACIÓN: suponga que el hardware es suficientemente bueno para cumplir los requisitos para el uso de multihilo.

Answer 1

Para establecer el número de subprocesos de trabajo puede utilizar .WithDegreeOfParallelism (N)

por ejemplo

var query = from item in source.AsParallel().WithDegreeOfParallelism(2) 
      where Compute(item) > 42 
      select item; 

Ver http://msdn.microsoft.com/en-us/library/dd997425.aspx

Answer 2

Todo se reduce a dos cosas:

1. es el trabajo extra que se requiere para dividir la colección y sincronizar los hilos superiores a la ganancia de rendimiento en comparación con un habitual foreach?

2. ¿Todos los hilos van a utilizar un recurso compartido que se convertirá en un cuello de botella?

Un ejemplo del segundo caso está haciendo un Parallel.ForEach sobre los resultados de una instrucción Linq to Sql. En ese caso, si los resultados provienen del DB muy lentamente, cada hilo puede pasar más tiempo esperando que se procesen los datos que hacer algo en realidad.

Ver: http://msdn.microsoft.com/en-us/library/dd997392.aspx

Answer 3

Cuando excavación en cuestiones de rendimiento de esta profundo, creo que lo mejor que se puede hacer es ... medir, medir y medir. Incluso si alguien respondiera que PLINK es excelente y que aumentará el rendimiento de su aplicación, ¿confiaría en eso sin verificarlo con el perfil? Aunque pueden existir respuestas generales, no puede ahorrar el esfuerzo de medir el rendimiento en su caso exacto. El rendimiento general depende de muchas cosas y puede ser que PLINK ayude en un caso pero no en el otro.
Mi experiencia personal con PLINK es que después de cambiar cada consulta LINQ a PLINK, los tiempos de respuesta son mucho mejores cuando la carga es pequeña, y no hay diferencia cuando la carga está alrededor de su valor máximo. Pero me puedo imaginar un caso donde PLINK perjudica el rendimiento general bajo una gran carga. Debe verificarlo en su caso particular.
Bueno ... y si quiere convencer a otras personas de que está caminando por el camino correcto, ¿qué otra cosa sería mejor que los resultados de las mediciones?