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.
5 Réponses :
Je commencerais maintenant. Je soupçonne fortement que nous avons vu la majeure partie des changements - même s'il y a quelques modifications dans le candidat de la libération, je suis sûr qu'ils seront bien documentés dans le Blog de l'équipe PFX et facile à changer. Même si les puces changent, je m'attendrais à ce que le TPL s'adapte à l'adaptation appropriée dans les versions futures - et j'attendrais personnellement que la TPL actuelle est toujours susceptible de faire un meilleur travail de manipulation de ces nouvelles puces que n'importe quel code de filetage artisanal de simples mortels comme Les États-Unis pouvaient écrire.
Le seul inconvénient, je vois à commencer maintenant, c'est que les ressources d'apprentissage ne sont pas vraiment là. Il y a une certaine documenta, certains postes de blog (dont certains seront obsolètes maintenant) et de certains échantillons de code - mais aucun livre dédié au PFX. Je suis sûr que ceux-ci viendront à temps cependant - et si vous êtes tôt dans le jeu, vous pouvez même en écrire un :)
Selon votre application, vous pouvez également consulter Extensions réactives , qui fonctionne à la main avec PFX.
Je ne suis pas inquiet du manque de ressources d'apprentissage puisque les API sont très intuitives OMI. TPL est beaucoup plus facile que de rouler votre propre utilisation à l'aide d'API de filetage de base, ce que j'ai dû faire à plusieurs reprises au fil des ans.
@Joe: Ils peuvent être généralement intuitifs, mais imme le diable dans le détail. Je suis certainement impatient de trouver des ressources détaillées à l'avenir.
À la fin, il importe plus que votre moteur central puisse bénéficier d'un parallélisme en général. At-il beaucoup d'état partagé qui doit être gardé avec des serrures? Si cela est vrai, cela peut être facilement déplacé vers un design centré sur des structures de données sans verrouillage?
Je pense que ces questions doivent être répondues en premier, afin que vous puissiez avoir une image plus claire pour évaluer si TPL peut aider sur la route.
Notre moteur central a été conçu à partir du sol pour soutenir le parallélisme, mais les tests dans la période de 2004 ont indiqué qu'il ne valait pas la peine d'effort. C'est un problème complexe avec beaucoup d'État à traiter, mais c'est un problème que j'ai réfléchi à partir de plusieurs années.
Eh bien - votre raison principale contre l'utilisation du TPL aujourd'hui semble être la suivante:
Vous ne savez pas si le TPL prendra le maximum de la multi-processeurs multiples du futur.
Je dirais (c'est seulement une supposition - surtout en informatique, vous ne serez jamais en mesure de dire ce qui se passe ensuite): Oui, ils vont changer. Et oui, le TPL sera modifié à certains points pour optimiser les performances. Cependant, certains changements seront «sous la hotte» - vous bénéficierez d'optimisations sans changer une ligne de code unique.
Et même s'il existe des changements dans les architectures qui entraînent des performances plus élevées uniquement en combinaison qui changeant votre code: je ne pense pas que ces changements affecteront votre code complet - peut-être qu'un pourcentage de milliseconde est très important.
Et où sont les alternatives? En utilisant le threadpool? Eh bien, alors le TPL est beaucoup plus à jour. Par conséquent, votre code sera plus à la preuve future lorsque vous l'utilisez IMHO. Par exemple, les démos des caractéristiques de débogage de VS 2010 ont l'air assez agréable.
En outre, le TPL semble être assez flexible dans mes yeux - s'il ne correspond pas à une situation spécifique, vous n'avez pas à l'utiliser là-bas. D'autre part, il simplifie le développement Mushc à d'autres endroits.
Je pense que la chose la plus importante aujourd'hui est de penser sur la parallélisation et l'inclure dans l'architecture. Le TPL rend ce processus beaucoup plus facile.
Par conséquent, ma conclusion: utilisez-la!
J'irais aussi. Le gros changement à mon avis est le changement de «paradigme» de la «nous l'avons fait de cette façon pour le développement des 8 dernières années» à une programmation gratuite plus fonctionnelle / secondaire.
Si vous commencez à utiliser PFX d'aujourd'hui, je suppose que cela prendra du temps pour vous mettre au courant de la vitesse et de porter littéralement votre code pour en tirer le meilleur parti. Si, d'autre part, PFX disparaît en 2 ans ou apporte des changements majeurs, je m'attendrais à ce que votre code travaille encore de mieux en utilisant ce que vous y arriverez. Nous ne réduirons plus le nombre de cœurs et les grandes tâches à l'échelle ne seront mieux obsolètes pour un certain temps.
En ce qui concerne les changements d'architecture du processeur: je ne peux pas vraiment commenter ceux-ci, sauf que, à mon avis, votre investissement aboutira maintenant à un avantage commercial maintenant + x mois. X est probablement plus petit que le temps jusqu'à ce que des changements majeurs dans le développement de la CPU se produisent -> vous gagnez.
Je n'attendrais pas non plus.
En fait, j'irais plus loin et dis-je n'attendez pas VS2010 / .NET 4.0. Le TPL est disponible pour .NET 3.5 maintenant dans le cadre du Extensions réactives pour .NET. .