.NET 4 Parallel.ForEach e PLINQ: possono sopraffare il pool di thread e terminare le prestazioni dell'app?

Question

Più utilizzo Parallel.ForEach e PLINQ nel mio codice, maggiore è il numero di volti e revisioni del codice che sto ricevendo. Quindi mi chiedo se ci sia qualche ragione per me per NON usare PLINQ, in estrema, su ogni istruzione LINQ? Può il runtime non essere abbastanza intelligente da avviare la generazione di così tanti thread (o il consumo di così tanti thread dal pool di thread) che le prestazioni della app si degraderebbero invece di migliorare? La stessa domanda si applica alla libreria parallela.

Comprendo le implicazioni relative alla sicurezza del thread e al sovraccarico dell'utilizzo di multi-threading. Capisco anche che non tutto è buono per il parallelismo. Tutto quello che mi chiedo se dovrei smettere di difendere i miei approcci e rinunciare a queste due belle cose perché i miei colleghi pensano che farei meglio il controllo dei thread me stesso invece di affidarmi alle funzionalità .NET.

UPDATE: si supponga che l'hardware sia sufficientemente buono per soddisfare i prerequisiti per l'uso del multithreading.

Answer 1

Per impostare il numero di thread di lavoro è possibile utilizzare .WithDegreeOfParallelism (N)

esempio

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

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

Answer 2

Tutto si riduce a due cose:

1. è il lavoro supplementare richiesto per partizionare la raccolta e sincronizzare i fili superiore al guadagno di prestazioni rispetto ad un normale foreach?

2. Tutti i thread utilizzeranno una risorsa condivisa che diventerà un collo di bottiglia?

Un esempio del secondo caso sta facendo un Parallel.ForEach sopra i risultati di un'istruzione Linq to Sql. In tal caso, se i risultati provengono dal DB molto lentamente, ogni thread potrebbe impiegare più tempo in attesa che i dati vengano elaborati rispetto a quelli effettivamente eseguiti.

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

Answer 3

Quando scavare in domande di prestazioni questa profondo, penso che la cosa migliore da fare sia ... misurare, misurare e misurare. Anche se qualcuno ha risposto che PLINK è ottimo e migliorerà le prestazioni della tua applicazione, ti fideresti di ciò senza verificarlo con la creazione di profili? Sebbene possano esistere risposte generali, non è possibile risparmiare lo sforzo di misurare le prestazioni nel caso specifico. Le prestazioni complessive dipendono da così tante cose e può essere che PLINK aiuti in un caso ma non nell'altro.
Le mie esperienze personali con PLINK sono che dopo aver interrotto ogni query LINQ in PLINK i tempi di risposta sono decisamente migliori quando il carico è ridotto e non c'è differenza quando il carico è intorno al massimo. Ma posso immaginare un caso in cui PLINK ferisce le prestazioni complessive sotto un carico enorme. Devo controllarlo per il tuo caso particolare.
Beh ... e se vuoi convincere altre persone che stai percorrendo la strada giusta, che altro sarebbe meglio dei risultati delle misurazioni?