E 'troppo presto per iniziare a progettare per la biblioteca Task Parallel?

Question

Ho seguito lo sviluppo di .NET Task Parallel Library (TPL) con grande interesse da quando Microsoft ha annunciato di esso.

Non v'è alcun dubbio nella mia mente che alla fine approfittare di TPL. Quello che metto in discussione è se ha senso per iniziare a prendere vantaggio di TPL quando Visual Studio 2010 e .NET 4.0 vengono rilasciati, o se ha senso aspettare ancora un po '.

Perché cominciare ora?

• Viene visualizzata la Parallel Library .NET 4.0 Task essere ben progettato e alcuni test relativamente semplici dimostrano che funziona bene su CPU multi-core di oggi.
• sono stato molto interessato ai potenziali vantaggi di utilizzare più thread leggeri per accelerare il nostro software in quanto l'acquisto il mio primo processore quad Dell Poweredge 6400 circa sette anni fa. Gli esperimenti in quel momento hanno indicato che non ne valeva la pena, che ho attribuito in gran parte al sovraccarico di spostamento dei dati tra la cache di ciascuna CPU (non c'era cache condivisa allora) e RAM.
• Il vantaggio competitivo -. Alcuni dei nostri clienti può mai avere abbastanza le prestazioni e non v'è alcun dubbio che siamo in grado di costruire un prodotto più veloce utilizzando TPL oggi
• Sembra divertente. Sì, mi rendo conto che alcuni sviluppatori preferiscono stessi ficcare in un occhio con un bastone affilato, ma abbiamo davvero godere massimizzando le prestazioni.

Perché aspettare?

• Sono di oggi le CPU Intel Nehalem rappresentante di dove stiamo andando come matura supporto multi-core? È possibile acquistare una CPU Nehalem con 4 core che condividono un unico cache di livello 3 oggi, e molto probabilmente una CPU 6 nucleo condivisione di una singola cache di livello 3 per il momento in Visual Studio 2010 / .NET 4.0 vengono rilasciati. Ovviamente, il numero di core salirà nel corso del tempo, ma per quanto riguarda l'architettura? Come il numero di core va in su, saranno ancora condividere una cache? Un problema con Nehalem è il fatto che, anche se c'è un'interconnessione molto veloce tra le anime, hanno Non-Uniform Memory Access (NUMA) che può portare a prestazioni inferiori e risultati meno prevedibili. Saranno le future architetture multi-core in grado di farla finita con NUMA?
• Allo stesso modo, sarà il .NET Task Parallel cambiamento biblioteca come matura, che richiedono modifiche al codice di trarre pieno vantaggio di esso?

Limitazioni

• Il nostro motore di base è 100% C # e deve funzionare senza la piena fiducia, quindi siamo limitati ad utilizzare le API .NET.

Answer 1

Vorrei iniziare ora. Ho il forte sospetto che abbiamo visto la maggior parte dei cambiamenti - anche se ci sono un paio di modifiche nella release candidate, sono sicuro che essi saranno ben documentati nella squadra PFX blog , e facile da cambiare. Anche se i chip cambiano, mi aspetto il TPL di adattarsi appropriata nelle versioni future - e io personalmente aspetto che l'attuale TPL è ancora probabile a fare un lavoro migliore di gestire questi nuovi chip di qualsiasi codice di threading artigianale comuni mortali come noi potremmo scrivere.

L'unico vero inconveniente che vedo a partire da ora è che le risorse per l'apprendimento non sono veramente lì ancora. C'è un po 'documenation, alcuni post del blog (alcuni dei quali sarà superata ormai) e alcuni esempi di codice - ma non i libri dedicati al PFX. Sono sicuro che coloro che verranno nel tempo però - e se siete all'inizio del gioco, si potrebbe anche scrivere uno:)

A seconda dell'applicazione in uso, si potrebbe anche voler guardare estensioni reattivi , che lavora mano nella mano con PFX.

Answer 2

Alla fine, importa più se il motore principale può beneficiare di un parallelismo in generale. Ha a un sacco di stato condiviso che deve essere custodito con le serrature? se questo è vero, si può che essere facilmente spostato da un design incentrato su strutture di dati senza blocchi?

Credo che queste questioni vanno risolte prima, in modo da poter loro hanno un quadro più chiaro per valutare se TPL può aiutare lungo la strada.

Answer 3

Bene - il motivo principale contro l'uso del TPL oggi sembra essere la seguente:
Non sai se il TPL avrà il massimo della del futuro multicore-CPU.

Direi (che è solo una supposizione - soprattutto in informatica non si sarà mai in grado di dire che cosa accadrà dopo): Sì, cambieranno. E sì, il TPL sarà cambiato in alcuni punti per massimizzare le prestazioni. Tuttavia, alcuni cambiamenti saranno "sotto il cofano" -. Beneficerete di ottimizzazioni senza realmente cambiare una sola riga di codice

E anche se ci sono cambiamenti nelle architetture che danno luogo a prestazioni più elevate solo in combinazione che cambiare il codice:. Non credo che questi cambiamenti influenzeranno il vostro intero codice - magari un po 'per cento erano ogni singolo millisecondo è molto importante

E dove sono le alternative? Utilizzando il ThreadPool? Bene - allora il TPL è molto più aggiornato. Pertanto, il codice sarà più a prova di futuro quando lo si utilizza IMHO. Ad esempio, le demo di funzionalità di debug VS 2010 di un aspetto piuttosto bella.

In aggiunta, il TPL sembra essere abbastanza flessibili nei miei occhi - se non va bene in una situazione specifica non devi usarlo lì. D'altra parte semplifica mushc sviluppo in altri luoghi.

Credo che la cosa più importante oggi è quello di pensare sulla parallelizzazione e comprendono in architettura. Il TPL rende questo processo molto più facile.

Quindi, la mia conclusione: Usalo

!

Answer 4

mi piacerebbe andare per esso pure. Il grande cambiamento a mio parere è il turno di "paradigma" dal "abbiamo fatto in questo modo per gli ultimi 8 anni" sviluppo ad un / effetto collaterale libera programmazione più funzionale.

Se si avvia utilizzando PFX oggi direi che ci vorrà del tempo per arrivare fino a velocità con esso e letteralmente porta il codice per ottenere il massimo da esso. Se, d'altro canto PFX va via in 2 anni o porta grandi cambiamenti, mi aspetto il vostro codice ancora lavorare molto meglio utilizzando qualsiasi ci si arriva. Noi non diminuirà nuovamente il numero di core e le grandi compiti per scalare meglio non sarà obsoleto per un bel po '.

Per quanto riguarda l'architettura CPU cambiamenti: non posso commentare in merito, se non che a mio parere il vostro investimento ora si tradurrà in un vantaggio commerciale ora + X mese di distanza. X è probabilmente più piccolo del tempo fino a grandi cambiamenti nello sviluppo di CPU accadono -.> Si vince

Answer 5

Non vorrei aspettare neanche.

In realtà, vorrei andare oltre e dire non aspettare per VS2010 / .NET 4.0. Il TPL è disponibile per NET 3.5 ora come parte dei estensioni reattivi per .NET .