Est-il trop tôt pour commencer à concevoir pour la bibliothèque parallèle de tâches?

Question

J'ai suivi le développement de la bibliothèque parallèle de tâches .NET (TPL) avec beaucoup d'intérêt depuis que Microsoft a d'abord annoncé.

Il ne fait aucun doute dans mon esprit que nous finirons par profiter de TPL. Ce que je me demande est de savoir s'il est logique de commencer à tirer profit de TPL lorsque Visual Studio 2010 et .NET 4.0 sont libérés, ou s'il est logique d'attendre un peu plus longtemps.

Pourquoi commencer maintenant?

• La bibliothèque parallèle de tâches .NET 4.0 semble bien conçu et des tests relativement simples démontrent que cela fonctionne bien sur les processeurs multi-core aujourd'hui.
• J'ai été très intéressé par les avantages potentiels de l'utilisation de plusieurs threads légers pour accélérer notre logiciel depuis l'achat de mon premier processeur quad Dell Poweredge 6400 il y a environ sept ans. Des expériences à cette époque ont indiqué que cela ne valait pas la peine, que j'attribuai en grande partie à la surcharge de données entre le cache de chaque CPU (il n'y avait pas de cache partagé à l'époque) et la RAM.
• Avantage concurrentiel -. Certains de nos clients ne peut jamais obtenir des performances suffisantes et il n'y a aucun doute que nous pouvons construire un
produit plus rapidement en utilisant aujourd'hui TPL
• Il semble amusant. Oui, je me rends compte que certains développeurs préfèrent se fourrer dans les yeux avec un bâton pointu, mais nous apprécions vraiment maximiser la performance.

Pourquoi attendre?

• Est représentant aujourd'hui les processeurs Intel Nehalem où nous allons comme mûrit support multi-core? Vous pouvez acheter un CPU Nehalem avec 4 cœurs qui partagent un seul niveau 3 cache aujourd'hui, et très probablement un processeur 6 core partageant un seul niveau 3 cache au moment où Visual Studio 2010 / .NET 4.0 sont libérés. De toute évidence, le nombre de cœurs sera au fil du temps, mais que sur l'architecture? Comme le nombre de cœurs monte, vont-ils partager encore un cache? Un problème avec Nehalem est le fait que, même si il y a une interconnexion très rapide entre les noyaux, ils ont accès à la mémoire non uniforme (NUMA) qui peut conduire à des performances moindres et moins des résultats prévisibles. Est-ce que les futures architectures multi-core capable de faire disparaître NUMA?
• De même, sera le groupe .NET parallèle changement bibliothèque comme il arrive à maturité, ce qui nécessite des modifications au code de tirer pleinement parti de celui-ci?

Limites

• Notre moteur de base est de 100% C # et doit fonctionner sans confiance totale, nous sommes donc limités à l'utilisation des API .NET.

Answer 1

Je commencerais maintenant. Je soupçonne fortement que nous avons vu l'essentiel des changements - même s'il y a quelques modifications dans la version release candidate, je suis sûr qu'ils vont être bien documentés dans le blog de l'équipe PFX et facile à changer. Même si les puces changent, je pense le TPL d'adapter appropriée dans les versions futures - et je pense personnellement que le TPL actuel est toujours susceptible de faire un meilleur travail de gérer ces nouvelles puces que tout code de filetage fabriqué à la main de simples mortels comme nous pourrions écrire.

Le seul véritable inconvénient que je vois de commencer est maintenant que les ressources d'apprentissage ne sont pas vraiment encore là. Il y a quelques Documenation, certains messages de blog (dont certains seront dépassés maintenant) et quelques exemples de code - mais pas de livres dédiés à PFX. Je suis sûr que ceux qui viendront dans le temps si - et si vous êtes tôt dans le jeu, vous pouvez même écrire un:)

En fonction de votre application, vous pouvez également regarder Reactive Extensions , qui travaille main dans la main avec PFX.

Answer 2

En fin de compte, il est plus important si votre moteur de base peut bénéficier du parallélisme en général. At-il beaucoup d'état partagé qui doit être gardée avec des serrures? si cela est vrai, peut-il être facilement déplacé à une conception centrée autour des structures de données sans blocage?

Je pense que ces questions doivent être répondues en premier lieu, de sorte que vous pouvez les avoir une image plus claire pour évaluer si TPL peut aider sur la route.

Answer 3

Et bien - votre principale raison contre l'utilisation aujourd'hui TPL semble être la suivante:
Vous ne savez pas si le TPL prendra le maximum de multicœurs processeurs de l'avenir.

Je dirais (c'est seulement une supposition - surtout dans la science informatique vous ne serez jamais en mesure de dire ce qui se passe à côté): Oui, ils changeront. Et oui, le TPL sera modifié à quelques points pour optimiser les performances. Cependant, certains changements seront « sous le capot. » - vous bénéficierez d'optimisations sans changer une seule ligne de code

Et même s'il y a des changements dans les architectures qui se traduisent par des performances plus élevées qu'en combinaison qui changer votre code. Je ne pense pas que ces changements auront une incidence sur votre code entier - peut-être quelques pour cent étaient chaque milliseconde est très important

Et où sont les alternatives? Utilisation de la Threadpool? Eh bien - alors le TPL est beaucoup plus à jour. Par conséquent, votre code sera plus à l'épreuve lors de son utilisation à mon humble avis. Par exemple, les démos des fonctionnalités de débogage de VS 2010 semblent tout à fait agréable.

En outre, le TPL semble être assez souple à mes yeux - si elle ne rentre pas dans une situation spécifique que vous ne devez pas utiliser là. D'autre part, il simplifie mushc de développement à d'autres endroits.

Je pense que le plus important aujourd'hui chose est de penser À propos de parallélisation et l'inclure dans l'architecture. Le TPL rend ce processus beaucoup plus facile.

Par conséquent, ma conclusion: Utilisez

Answer 4

Je vais pour elle aussi. Le grand changement à mon avis est le changement de « paradigme » de la « nous l'avons fait ainsi depuis 8 ans » le développement à une programmation plus fonctionnelle / sans effet secondaire.

Si vous commencez à utiliser PFX aujourd'hui je suppose que cela prendra un certain temps pour se mettre à jour avec elle et littéralement le port de votre code pour obtenir le maximum de celui-ci. Si d'autre part PFX disparaît en 2 ans ou apporte des changements majeurs, j'attends votre code encore travailler beaucoup mieux en utilisant tout ce que vous allez y arriver. Nous ne réduirons pas le nombre de cœurs à nouveau et les grandes tâches à l'échelle mieux ne sera pas rendu obsolète pendant un certain temps.

En ce qui concerne les changements d'architecture CPU: Je ne peux pas vraiment commenter ceux-ci, sauf que, à mon avis votre investissement va maintenant donner lieu à un avantage commercial maintenant + X mois loin. X est probablement plus petit que le temps jusqu'à ce que des changements majeurs dans le développement du processeur arrive -.> Vous gagnez

Answer 5

Je n'attendrais pas non plus.

En fait, je voudrais aller plus loin et dire ne pas attendre VS2010 / .NET 4.0. Le TPL est disponible pour .NET 3.5 maintenant dans le cadre des Reactive Extensions pour .NET .