.NET 4 Parallel.ForEach und PLINQ: Können sie den Thread-Pool überwältigen und die App-Leistung killen?

8

Je mehr ich Parallel.ForEach und PLINQ in meinem Code verwende, desto mehr Gesichter und Code-Review-Pushbacks bekomme ich. Also frage ich mich, gibt es einen Grund für mich, PLINQ im Extremfall nicht auf jeder LINQ-Anweisung zu verwenden? Kann die Laufzeit nicht intelligent genug sein, um so viele Threads zu erzeugen (oder so viele Threads aus dem Thread-Pool zu verbrauchen), dass sich die App-Leistung tatsächlich verschlechtert anstatt verbessert wird? Die gleiche Frage gilt für die Parallelbibliothek.

Ich verstehe Implikationen in Bezug auf Thread-Sicherheit und Overhead der Verwendung von Multi-Threading. Ich weiß auch, dass nicht alles zum Parallelisieren gut ist. Ich frage mich nur, ob ich aufhören sollte, meine Ansätze zu verteidigen und diese beiden schönen Dinge einfach aufzugeben, weil meine Kollegen denken, ich sollte besser selbst Threads steuern anstatt mich auf .NET-Funktionen zu verlassen?

UPDATE: Bitte gehen Sie davon aus, dass die Hardware ausreichend gut ist, um die Voraussetzungen für die Verwendung von Multithreading zu erfüllen.

    
Schultz9999 25.03.2012, 03:59
quelle

3 Antworten

3

Um die Anzahl der Worker-Threads festzulegen, können Sie .WithDegreeOfParallelism (N)

verwenden

zB

%Vor%

Siehe Ссылка

    
Luke McGregor 25.03.2012, 05:00
quelle
4

Alles läuft auf zwei Dinge hinaus:

  1. Ist die zusätzliche Arbeit erforderlich, um die Sammlung zu partitionieren und die Threads zu synchronisieren, die größer sind als der Leistungszuwachs im Vergleich zu einem normalen foreach ?

  2. Werden alle Threads eine freigegebene Ressource verwenden, die zu einem Flaschenhals wird?

Ein Beispiel für den zweiten Fall ist eine Parallel.ForEach über den Ergebnissen einer Linq to Sql Anweisung. Wenn Ihre Ergebnisse in diesem Fall sehr langsam von der Datenbank kommen, kann es sein, dass jeder Thread mehr Zeit darauf verwendet, auf die Verarbeitung von Daten zu warten, als tatsächlich etwas zu tun.

Siehe: Ссылка

    
Diego 25.03.2012 04:16
quelle
2

Wenn ich so tief in die Performance-Fragen eingehe, denke ich, dass das Beste darin besteht, ... zu messen, zu messen und zu messen. Selbst wenn jemand geantwortet hat, dass PLINK großartig ist und die Leistung Ihrer Anwendung steigern wird, würden Sie dem vertrauen, ohne es mit Profiling zu überprüfen? Obwohl allgemeine Antworten vorhanden sein können, können Sie nicht die Mühe verschwenden, um die Leistung in Ihrem genauen Fall zu messen. Die Gesamtleistung hängt von so vielen Dingen ab, und es kann sein, dass PLINK in einem Fall hilft, aber nicht in dem anderen.
Meine persönlichen Erfahrungen mit PLINK sind, dass nach jeder LINQ-Abfrage in PLINK die Antwortzeiten viel besser sind ist klein, und es gibt keinen Unterschied, wenn die Last um ihr Maximum herum ist. Aber ich kann mir einen Fall vorstellen, in dem PLINK die Gesamtleistung unter einer großen Last verletzt. Überprüfen Sie es für Ihren eigenen speziellen Fall.
Gut ... und wenn Sie andere Leute davon überzeugen möchten, dass Sie den richtigen Weg gehen, was sonst wäre besser als Messergebnisse?

    
Hari 25.03.2012 07:08
quelle