2

質問1。

Parallel.For と Parallel.ForEach の使用は、順序付けされたタスクまたは順序付けられていないタスクの操作に適していますか?

質問する理由は、StringBuilder を使用してさまざまなパラメーターに基づいて SQL ステートメントを生成するシリアル ループを最近更新したためです。その結果、標準の foreach ループを使用した場合と比較して、SQL が少しごちゃごちゃしていました (構文エラーが含まれる点まで)。したがって、TPL は、データが特定の形式で表示される必要があるタスクの実行には適していないというのが私の直感です。特定の順序。

質問2。

TPL はマルチコア アーキテクチャを自動的に利用しますか? 実行前に何かをプロビジョニングする必要がありますか?

これを尋ねる理由は、TPL 操作のパフォーマンス プロファイリングに関して以前に尋ねた質問に関連しています。アプリケーションが複数のコアにアクセスできない可能性があるため、TPL が標準のシリアル ループよりも常に効率的であるとは限らず、したがって追加のスレッドとループを作成するオーバーヘッドにより、比較してパフォーマンスが低下するという事実を、質問への回答で教えてくれました。標準のシリアルループに。

4

5 に答える 5

2

私の直感では、TPL は、データを特定の順序で表示する必要があるタスクの実行には適していません。

正しい。物事が順番通りに行われることを期待すると、ループを「並列化」したときに何が起こるかについて誤解している可能性があります。

TPL は自動的にマルチコア アーキテクチャを利用しますか? 実行前に何かをプロビジョニングする必要がありますか?

msdn マガジンの次の記事を参照してください: http://msdn.microsoft.com/en-us/magazine/cc163340.aspx

このライブラリを使用すると、公開された並列タスクが利用可能なすべてのプロセッサで同時に実行される既存の順次コードで潜在的な並列処理を簡単に表現できます。

于 2012-10-30T15:26:50.760 に答える
1
  1. 結果を順序付けする必要がある場合、ループを並列化するには、実際の作業を任意の順序で実行し、結果を並べ替えることができる必要があります。これは、状況に応じて、最初に作業を連続して行うよりも効率的である場合とそうでない場合があります。任意の順序で実行できる作業を並列化することの利点が、結果を並べ替えるコストよりも大きい場合、それは純利益です。そのタスクが十分に複雑でない場合、ハードウェアが多くの並列化を許可していない場合、または並列化がうまくいかない場合 (つまり、データの依存関係のために多くの待機がある場合)、結果の並べ替えにさらに時間がかかる可能性があります。ループを並列化するよりも時間がかかります (さらに悪いことに、ループを並列化すると、並べ替えがなくても時間がかかります。質問 2 を参照してください)。したがって、ループを並列化するべきではありません。

    特定の順序で結果を必要とするだけでなく、実際の作業単位を特定の順序で実行する必要がある場合は、並列化できないか、並列化できないことに注意してください。ほぼ同じように効果的です。共有リソースへのアクセスを適切に同期しないと、実際には間違った結果になります(あなたの場合のように)。そのためには、パフォーマンスの最適化を行っても、実際に正しい結果が得られなければ意味がないことを覚えておく必要があります。

  2. TPL を使用すると、ハードウェアについてあまり心配する必要はありません。タスクを明示的に追加または制限する必要はありません。できる方法はいくつかあります、事実上、このようなことを行うと、パフォーマンスが低下します。そのようなことを行うと、TPL に制限が追加され、望んでいることを実行できなくなります。多くの場合、それはあなたよりもよく知っています。

    ここで別の点にも触れていますが、それは、ループの並列化に時間がかかることが多いということです (この動作を引き起こす可能性のある理由を示していませんでした)。多くの場合、実行する必要がある実際の作業は非常に小さいため、スレッドの作成、スレッドの管理、コンテキスト シフトの処理、および必要に応じたデータの同期の作業は、いくつかの作業を並行して行うことで得られる作業よりも多くの作業になる可能性があります。これが、いくつかの作業を並列化することを決定する際に実際に多くのテストを行い、実際にその恩恵を受けることを確認することが重要である理由です。

于 2012-10-30T15:27:07.673 に答える
0

ポイント1で、TPLを使用している場合、どのタスクがどの順序で実行されるかわかりません。それが並列と順次の美点です。物事の順序を制御する手段はありますが、そうすると並列の利点が失われる可能性があります。

On 2: TPL はすぐに使えるマルチコアを利用します。しかし、実際には、複数のスレッドを使用するとオーバーヘッドが常に発生します。スケジューラーの負荷が増大し、スレッド (コンテキスト) の切り替えは無料ではありません。競合状態を回避するためにデータの同期を維持するには、おそらくオーバーヘッドにも追加される何らかのロック メカニズムが必要になるでしょう。

TPL を使用して高速な並列アルゴリズムを作成することは、はるかに簡単になりますが、それでもある種の芸術です。

于 2012-10-30T15:25:15.500 に答える
0
  1. 順序付けられていないリストの場合、良くも悪くもありません。#1 の問題StringBuilderは、並列クエリが失敗した理由であるa への共有依存関係があることでした。TPL は、独立した作業単位で見事に機能します。それでも、並列クエリの評価を強制し、並列操作がすべて終了したときに結果の元の順序を維持するために使用できる簡単なトリックがあります。

  2. TPL と PLINQ は技術的に異なるものです。PLINQ は TPL を使用して目的を達成します。とはいえ、PLINQ はアーキテクチャを検査し、可能な限りセットの実行を構造化しようとします。TPL は、タスク アーキテクチャの単なるラッパーです。タスクを作成するオーバーヘッド (1MB のメモリのようなもの) と、タスクを実行するためのコンテキスト切り替えのオーバーヘッドが、単純にタスクを連続して実行するよりも大きいかどうかを判断するのは、あなた次第です。

于 2012-10-30T15:27:11.570 に答える
0

明らかに、TPL は、クエリのような順序付きセットを構築するための優れたツールではありません。

一連のアイテムに対して実行する一連のタスクがある場合は、BlockingCollection を使用できます。タスクは並行して実行できますが、セットの順序は維持されます。

BlockingCollection クラス

于 2012-10-30T15:44:11.380 に答える