問題タブ [ppl]

私は Windows ストア (C++) アプリに取り組んでいます。Webサービスを利用してデータベースから読み込む方法です。

受信したデータを呼び出し元の関数に返す方法がわかりません。今、私は次のようにデータクラスのコンストラクターでこの関数を呼び出しています:

GetFromDB() から返されたデータを受信しようとすると、常に COM 例外が発生します。しかし、これはうまくいきます：

GetFromDB の完了を他のコードにチェーンするより良い方法を提案してください。そして、 GetFromDB() の try{} ブロック内から戻り値を取得する方法。私は非同期プログラミングの非常に新しい学生であることを覚えておいてください。

ベイヤー画像チャンネルを RGB に変換するアルゴリズムがあります。私の実装ではfor、ベイヤー チャネルを反復処理し、ベイヤー インデックスから RGB インデックスを計算し、ベイヤー チャネルからそのピクセルの値を設定する単一のネストされたループがあります。ここで注目すべき主な点は、各ピクセルは他のピクセルとは独立して計算できる (以前の計算に依存しない) ため、このアルゴリズムは自然に並列化の候補になるということです。ただし、計算は、すべてのスレッドが同時にアクセスするが変更されないいくつかのプリセット配列に依存します。

ただし、メインforを MSと並列化しようとするとcuncurrency::parallel_for、パフォーマンスが向上しませんでした。実際、4 コア CPU で実行されるサイズ 3264X2540 の入力の場合、非並列バージョンは ~34 ミリ秒で実行され、並列バージョンは ~69 ミリ秒で実行されました (10 回の実行の平均)。実際に操作が並列化されていることを確認しました (タスク用に 3 つの新しいスレッドが作成されました)。

Intel のコンパイラを使用するとtbb::parallel_for、ほぼ正確な結果が得られました。比較のために、ループC#も使用したこのアルゴリズムの実装から始めたところ、parallel_forほぼ X4 のパフォーマンス向上が見られました (C++この特定のタスクC++ではシングルコアでも高速だったので選択しました)。

私のコードがうまく並列化できない理由は何ですか?

私のコード:

TBB で PPL のタスクの継続に似たものはありますか? tbb::tasks を手動で割り当て、継続タスクも手動で割り当て、それらの参照カウントを手動で管理する低レベルの TBB メソッドを認識しています。

それは単に恐ろしいことです。生成する子タスクの数を事前に把握し、参照カウントを適切に手動で設定する必要があります。これは非常に壊れやすいコーディングです...

継続を指定する PPL の方法はとても単純です。

TBBでそれをどのように達成しますか?

私は、他の職務の中でも、定期的に (1 時間に 1 回) サーバーに要求を行う C++ アプリケーションを作成しています。
このスケジュールされたタスクは中断され、早期に (アプリケーションが新しいユーザー データを受信したときに) 強制的に実行することができます。この目的のために ConcRT を使用することにしました。

• このようなスケジューリングの標準的な方法 (Win32 のタイマー キューなど) はありますが、タスクとタスク グループはありますか?
• または、タスクを継続してチェーンする必要がありますか?
• Agents Library の方が適しているのではないでしょうか? （私の問題ではやり過ぎだと思った）

PS HTTP 要求は古き良き WinHTTP で作成されます (実行可能ファイルはサードパーティのライブラリに依存せず、サイズを小さく保つ必要があります)。ConcRTメカニズムに準拠した、HTTPリクエスト機能の非同期実装はありますか?

私は MSVC 2010 を使用して新しい MFC プロジェクトを開始しており、現在、同時実行タスクに使用するライブラリを決定しようとしています。新しい C++0x スレッド機能は知っていますが、VC10 には実装されていません。VC12 はまだオプションではありませんが、将来提供される予定です。私には良さそうな Microsoft PPL がありますが、新しいプロジェクトのために Windows から Linux に移行する可能性があります。そのために、VC12 で標準に変更するためにブーストを使用するオプションがあります。

私の質問は、PPL または一時的にブーストしてから std のどちらを優先すべきかということです。どちらがより強力で、より便利で、長所と短所があるか、両方の経験をお聞きしたいと思います.

私は、C++ 環境内で PPL タスクを使用することに関してはまったくの初心者なので、次の C# コードの C++ 構文が何であるかを理解するのに苦労しています。

この C# コードは、Windows Store reversi Microsoft sample codeから取得したものです。私がこれまでに得た最高のものはこれです：

ただし、次のコンパイル エラーが発生します。

このエラーが発生する理由は理解できますが、2 つの異なる場所で戻り値を持たずにタスクを返す関数を作成する方法がわかりません。GetImageStream にもまだ取り組んでいません。

私はこれに正しい道を歩んだかどうかさえ確信が持てません...

ありがとうございました！

一度に複数のソースからデータを取得し、それを内部データベース (現在はstd::set) に格納するサーバー アプリケーションを作成しています。

私はちょうど Microsoft の ConcRT PPL データ構造を見ていて、std::unordered_set. たとえば、次の 2 つのコード スニペットのパフォーマンスに大きな違いはありますか?

と：

Moveover、私はしばしばデータを順番に出力する必要があります。そのため、私は現在 ではstd::setなく を使用してstd::unordered_setいconcurrency::concurrent_unordered_setます。印刷する必要がありますか？

PPL スレッド プールを事前に初期化する標準的な方法はありますか? 問題は、たとえば parallel_for() が実行されているときに、PPL が実行時にスレッド プールを作成することです。これにより、追加のスレッドが作成されるため、最初の実行時にパフォーマンスが少し低下します。

問題を明確にするために、例を次に示します。

コンカレンシー ランタイムは、タスクによってスローされた例外を処理できず、"すばやく失敗する" ことを検出します。つまり、プロセスを終了します。に与えられた複数のサブタスクwhen_allが例外をスローする場合があります。理想的には、これらの例外がタスク ツリーをキャンセルし、最上位の get または wait で発生する単一の例外に集約されることを望みます。代わりに、私のプロセスは私の下で終了します。問題を示すおもちゃの例を次に示します。

この例では、「Process is still running」がコンソールに出力される前にプロセスが終了します。サブタスクの例外によりwait_all、他のサブタスクが終了/キャンセルされるのを待たずにすぐに継続が呼び出され、他のサブタスクによって発生した例外を処理できず、プロセスが終了するようです。これは非常に望ましくないようです。回避策はありますか? これはバグですか？何か不足していますか？