スケジューラがタスクをスレッド ロックフリー キューに渡すタスク ベースのマルチスレッド エンジンがセットアップされています。エンジンはレンダリング用の DirectX を使用した C++ であり、スレッドの作成には boost::thread を使用しています。ウィンドウ モードの場合、1 秒ほどランダムに速度が低下し、その後速度が上がります。どうやらVistaが原因らしいのですが、どうすれば解決できるのかわかりません。
ランダムなスローダウンに役立つと思われる私たちが試したことの 1 つは、各タスクが処理された後にスレッドを 1 ミリ秒間スリープさせることでしたが、それは他の問題を引き起こし、実際には優れた解決策ではありません.
私がお勧めする最初のことは、プロファイリングによってスローダウンの原因を理解することです。
ランダムなスリープをスローすることはめったに良い考えではありません (ここでの経験から言えば、はい、これを実行し、後で修正しました)、特にマルチスレッド環境でのパフォーマンスの問題の原因を推測することもありません。
Visual Studio 2010 beta1 には優れたプロファイラーがあり、アプリケーション内にある場合に速度低下の原因を理解するのに最適です。Hazim Shafi のブログでは、その使用方法について説明しています。
また、 Windows パフォーマンス ツールキットで利用可能な xperf ツールを確認することもできます(プラットフォーム SDK インストーラーを使用する必要がありますが、そのノードをインストールするだけでよいため、実際にはかなり高速です)。
XP と Windows 7 で同じコードを実行してみましたか?
オフスクリーン互換ビットマップにレンダリングするマルチスレッド コードがあります。各スレッドは、互換性のある独自のビットマップにレンダリングされます。ただし、奇妙な理由で、この図面は Vista で AGES を使用します。処理時間の 50% 以上を GDI レンダリングに費やしています。Win 7 と XP では、そのような問題はありません。興味深いことに、Vista でのマルチスレッド GDI レンダリングが絶望的に壊れていることを意味するこの記事に出くわしました。ある時点で、Vista のパフォーマンスが向上するかどうかをテストするために、すべてのレンダリングを補助スレッドではなくメイン スレッドで行う方法を考え出すつもりです。ただし、これはコード化することの大きな悪夢であり、私の主要な市場は XP を使用しているので、私はそうではありません。その瞬間に大騒ぎした...