4コアCPUで同じ計算をより速く行う方法：4スレッドまたは50スレッド？

Question

ブロッキング、スリープ、I/O待機のない一定量の計算作業があると仮定します。この作業は非常によく並列化できます。これは100Mの小さな独立した計算タスクで構成されています。

4コアCPUの方が速いのはなぜですか？4スレッドを実行するにはどうすればいいですか？なぜ2番目の変種がスローでなければならず、どれくらいのスローオーバーが必要ですか？

私が想定しているように、別のCPUを消費するプロセス/スレッドなしで4コアCPUで4つの重いスレッドを実行すると、スケジューラはコア間でスレッドをまったく動かすことができません。この状況でそれを行う理由はありません。 Core0（メインCPU）は、ハードウェアタイマーの割り込みハンドラ（毎秒250回）やその他のハードウェア割り込みハンドラの実行を担当しますが、他のコアでは心配する必要はありません。

コンテキスト切り替えのコストはいくらですか？異なるコンテキストのCPUレジスタを格納し復元する時間は？ CPU内部のキャッシュ、パイプライン、さまざまなコード予測機能はどうですか？コンテキストを切り替えるたびに、キャッシュ、パイプライン、およびCPU内のいくつかのコード解読機能が傷ついていると言うことができますか？単一のコアで実行されるスレッドが増え、シリアル実行と比較して一緒に実行できる作業が少なくなります。

マルチスレッド環境でのキャッシュと他のハードウェアの最適化に関する質問は私にとって今興味深い質問です。

Answer 1

@Baileはコメントで言及しているように、これはアプリケーション、システム、環境固有のものです。

このように、私は、コアごとに正確に1つのスレッドを言及する強硬なアプローチをとるつもりはありません。 （ハイパースレッディングの場合は2つのスレッド/コア）

経験豊富な共有メモリプログラマとして、最適なスレッド数（4コアマシンの場合）は1から64の範囲で設定できます+。

今私は、この範囲を引き起こす可能性の状況を列挙します：

最適なスレッドコアの<＃非常に（このような小さなFFTのような）並列きめの細かいされている特定のタスクで

、スレッディングのオーバーヘッドが主要なパフォーマンス要因です。場合によっては、並列化することはまったく役に立ちません。場合によっては、2つのスレッドでスピードアップしますが、4つのスレッドで後方にスケーリングします。

もう1つの問題は、リソースの競合です。 4つのコア/スレッドに簡単に分割できる高度に並列化可能なタスクがあっても、メモリ帯域幅とキャッシュ効果によってボトルネックになる可能性があります。たいていの場合、2つのスレッドは4つのスレッドと同じくらい速くなることがわかります。

最適スレッド=コアの＃

（非常に大きいのFFTの場合、しばしばかのように）これは、最適なケースです。コアごとに1つのスレッド - ここで説明する必要はありません。メモリやI/Oに縛られていない最も恥ずかしがりな並列アプリケーションはここに適合します。

最適なスレッド>それが面白いところコア

の＃これは...非常に興味深いです。負荷の不均衡について聞いたことがありますか？過分解と作業盗みはどうですか？

多くの並列化可能なアプリケーションは不規則です。つまり、タスクは同じサイズのサブタスクに分割されません。だから、大きなタスクを4つの不等なサイズに分割してしまうと、それらを4つのスレッドに割り当てて、4つのコアでそれらを実行すると...結果は？ 1つのスレッドが他のスレッドよりも10倍多くの処理を行うため、並列パフォーマンスが悪い

ここでの一般的な解決方法は、に多くのサブタスクにタスクをオーバー分解します。それぞれのスレッドを作成することができます（スレッド >>コア）。あるいは、一定数のスレッドでタスクスケジューラを使用することもできます。すべてのタスクが両方に適しているわけではありませんので、4コアマシンで8または16スレッドにタスクを過度に分解するアプローチが最適な結果をもたらします。

---

スレッドを追加すると負荷分散が向上する可能性がありますが、オーバーヘッドが増えます。だから、典型的にどこかに最適な点があります。私は4つのコアで最高64スレッドを見ました。しかし、言及したように、それは非常にアプリケーション特有です。そして実験する必要があります。

---

EDIT：

は、コンテキストスイッチのコストは何です...質問に答えるより直接的に答えを拡大？ストアと復元の時間は CPUは異なるコンテキストに登録されますか？

これは環境に非常に依存しており、直接測定するのは多少困難です。
短い答え：非常に高価This might be a good read.

何 CPU内部キャッシュ、パイプラインおよび各種のコード予測の事についてはどうですか？コンテキストを切り替えるたびに、キャッシュにCPUの パイプラインといくつかのコードデコード機能が壊れていると言うことができますか？

短い答え：はいあなたコンテキストが出て切り替えると、あなたはおそらく、すべての予測を、あなたのパイプラインと混乱をフラッシュします。キャッシュと同じです。新しいスレッドは、キャッシュを新しいデータで置き換える可能性があります。

キャッチはありますがスレッドが同じデータを共有するアプリケーションでは、あるスレッドが、別の着信スレッドまたは同じキャッシュを共有する別のコアの別のスレッドのキャッシュを潜在的に「温める」可能性があります。（まれに、これは私のNUMAマシンの前で起こりました - 超高速のスピードアップ：16コアにわたって17.6x！）！

単一のコア上で実行されるスレッドが多いほど、シリアル実行と比較して を一緒に実行できますか？

依存している...ハイパースレッディングを除いて、間違いなくオーバーヘッドがあります。しかし、私は誰かが2番目のスレッドを使ってメインスレッドを先読みした紙を読みました...はい、それは狂っています...

Answer 2

4つのスレッドを使用できる場合は、それらを使用してください。 4コアのマシンでは、50が4より速く進む方法はありません。あなたが得ることは、より多くのオーバーヘッドです。

実際には、現実世界では理想的ではない状況を説明しているので、実際に何を構築していても、パフォーマンスにどのような影響があるかを理解するために測定する必要があります。

Answer 3

CPUあたり1つ以上のスレッドを処理できるハイパースレッディングテクノロジがありますが、実行する計算の種類にほとんど依存しません。最大限の電力を得るには、GPUまたは非常に低いアセンブリ言語の使用を検討してください。

Answer 4

実際に50スレッドを作成すると、それはまったく意味がありません。

理想的には、4つのスレッドをそれ以上ではなく、それ以下にする必要があります。コンテキスト切り替えのためにオーバーヘッドがありますが、それはやむを得ないことです。 OS/services /その他のアプリケーションスレッドも実行する必要があります。しかし、今日では非常に強力で高速なCPUを使用しているので、これらのOSスレッドはCPU時間の2％しかかかりませんので、これは問題ではありません。プログラムが実行されている間は、ほとんどすべてがブロック状態になります。

パフォーマンスが非常に重要なので、小さなレベルの重要な領域を低レベルのアセンブリ言語でコーディングする必要があります。現代のプログラミング言語ではこれが可能です。

しかし、真剣に...コンパイラ、そしてJavaの場合、JVMは、そのような部分をあまりにも最適化して、（実際にこのようなことをしない限り）価値がないでしょう。あなたの計算が100秒で終了するのではなく、97または98で終了します。あなた自身が尋ねなければならない質問は、コーディングとデバッグのすべての時間にかかりますか？

コンテキスト切り替えの時間コストについて質問しました。最近、これらは非常に低いです。たとえばWindows 7を実行する現代のデュアルコアCPUを見てください。そのマシンとMySQLデータベースサーバーでApache Webサーバーを起動すると、簡単に800スレッド以上になります。マシンはそれを感じないだけです。この費用の低さを確認するには、How to estimate the thread context switching overhead?をお読みください。あなたは検索/読込部を惜しまないために、文脈の切り替えを行うことができます。秒間に数十回。

Answer 5

オペレーティングシステムよりも40個のタスクの切り替えをプログラムできるなら、スレッド数は4倍です。