11

マイクロソフトが最初に発表して以来、私は.NETタスク並列ライブラリ（TPL）の開発に大きな関心を持って取り組んできました。

最終的にはTPLを活用することは間違いありません。私が質問しているのは、Visual Studio2010と.NET4.0がリリースされたときにTPLを利用し始めるのが理にかなっているのか、それとももう少し待つのが理にかなっているのかということです。

なぜ今すぐ始めるのですか？

  • .NET 4.0タスク並列ライブラリは適切に設計されているようであり、いくつかの比較的単純なテストは、それが今日のマルチコアCPUで適切に機能することを示しています。
  • 約7年前に最初のクアッドプロセッサDellPoweredge6400を購入して以来、複数の軽量スレッドを使用してソフトウェアを高速化することの潜在的な利点に非常に興味を持っています。当時の実験では、努力する価値がないことが示されました。これは主に、各CPUのキャッシュ（当時は共有キャッシュがありませんでした）とRAMの間でデータを移動するオーバーヘッドに起因していました。
  • 競争上の優位性-一部のお客様は十分なパフォーマンスを得ることができず、今日TPLを使用してより高速な製品を構築できることは間違いありません。
  • 楽しそうですね。はい、一部の開発者は鋭い棒で目を突くほうがいいと思いますが、パフォーマンスを最大化することを本当に楽しんでいます。

なぜ待つのですか？

  • 今日のIntelNehalemCPUは、マルチコアサポートが成熟するにつれて私たちがどこに向かっているのかを表していますか？現在、単一のレベル3キャッシュを共有する4コアのNehalem CPUを購入できます。また、Visual Studio 2010 / .NET 4.0がリリースされるまでに、単一のレベル3キャッシュを共有する6コアCPUを購入できる可能性があります。明らかに、コアの数は時間の経過とともに増加しますが、アーキテクチャについてはどうでしょうか。コアの数が増えても、それらは引き続きキャッシュを共有しますか？Nehalemの問題の1つは、コア間に非常に高速な相互接続があるにもかかわらず、コアに不均一なメモリアクセス（NUMA）があるため、パフォーマンスが低下し、結果が予測しにくくなる可能性があるという事実です。将来のマルチコアアーキテクチャはNUMAを廃止できるでしょうか？
  • 同様に、.NETタスク並列ライブラリは成熟するにつれて変更され、それを十分に活用するにはコードを変更する必要がありますか？

制限事項

  • コアエンジンは100％C＃であり、完全な信頼なしで実行する必要があるため、.NETAPIの使用に制限されています。
4

5 に答える 5

8

今から始めます。変更の大部分が見られたのではないかと強く思います。リリース候補にいくつかの調整があったとしても、それらはPFXチームのブログに十分に文書化されており、簡単に変更できると確信しています。チップが変更されたとしても、TPLは将来のバージョンで適切に適応することを期待します。個人的には、現在のTPLは、これらの新しいチップを処理する上で、単なる人間のような手作りのスレッデッドコードよりも優れた仕事をする可能性が高いと思います。私たちは書くことができました。

私が今始めていることの本当の欠点の1つは、学習リソースがまだ実際には存在しないことです。いくつかのドキュメント、いくつかのブログ投稿（そのうちのいくつかは今では古くなっています）、およびいくつかのサンプルコードがありますが、PFX専用の本はありません。しかし、それらは間に合うと確信しています-そして、ゲームの早い段階であれば、1つ書くこともできます:)

アプリケーションによっては、PFXと連携して機能するReactiveExtensionsも確認することをお勧めします。

于 2010-01-28T17:51:26.177 に答える
1

結局、コアエンジンが一般的に並列処理の恩恵を受けることができるかどうかがより重要になります。ロックで保護する必要のある共有状態がたくさんありますか？それが本当なら、それはロックフリーのデータ構造を中心とした設計に簡単に移行できますか？

これらの質問に最初に答える必要があると思います。そうすれば、TPLが将来的に役立つかどうかを評価するために、より明確な状況を把握できます。

于 2010-01-28T17:55:48.407 に答える
1

さて、今日TPLを使用することに対するあなたの主な理由は、次のように思われます
。TPLが将来のマルチコアCPUを最大限に活用するかどうかはわかりません。

私は言います（それは単なる推測です-特にコンピュータサイエンスでは、次に何が起こるかを知ることは決してできません）：はい、それらは変化します。はい、パフォーマンスを最大化するために、TPLはいくつかの時点で変更されます。ただし、一部の変更は「内部」で行われます。実際に1行のコードを変更しなくても、最適化の恩恵を受けることができます。

また、アーキテクチャに変更があり、コードを変更した場合にのみパフォーマンスが向上する場合でも、これらの変更がコード全体に影響を与えるとは思われません。おそらく、1ミリ秒ごとに数パーセントが非常に重要です。

そして、選択肢はどこにありますか？スレッドプールを使用していますか？そうですね、TPLははるかに最新のものです。したがって、コードをIMHOで使用すると、コードの将来性が向上します。たとえば、VS2010のデバッグ機能のデモは非常に見栄えがします。

さらに、TPLは私の目には非常に柔軟なようです。特定の状況に適合しない場合は、そこで使用する必要はありません。一方、それは他の場所での開発マッシュを簡素化します。

今日最も重要なことは、並列化について考え、それをアーキテクチャーに含めることだと思います。TPLを使用すると、このプロセスがはるかに簡単になります。

したがって、私の結論：それを使用してください！

于 2010-01-28T17:56:10.247 に答える
1

私も行きます。私の意見の大きな変化は、「過去8年間、この方法で行った」開発から、より機能的で副作用のないプログラミングへの「パラダイム」シフトです。

今日PFXを使い始めたら、PFXに慣れるのに少し時間がかかり、文字通りコードを移植して最大限に活用できると思います。一方、PFXが2年以内になくなるか、大きな変更が加えられた場合でも、そこに到達するものを使用すれば、コードははるかにうまく機能すると思います。コアの数を再び減らすことはなく、より適切にスケーリングするための大きなタスクがしばらくの間廃止されることはありません。

CPUアーキテクチャの変更について：私の意見では、あなたの投資が今+ Xか月後にビジネス上の利点をもたらすことを除いて、私はそれらについて実際にコメントすることはできません。Xは、CPU開発に大きな変化が起こるまでの時間よりもおそらく小さいです->あなたが勝ちます。

于 2010-01-28T18:01:44.277 に答える
1

私も待ちません。

実際、私はさらに進んで、VS2010 /.NET4.0を待たないでくださいと言います。TPLは、 Reactive Extensionsfor.NETの一部として.NET3.5で使用できるようになりました。

于 2010-03-17T20:48:50.260 に答える