HyperTreading のコンパイラ最適化に関する論文を書きたいと思っています。最初のステップは、HyperThreading (Simultaneous Multithreading) を使用するプロセッサが、このテクノロジを使用しないプロセッサよりもパフォーマンスが低下する理由を調査することです。最初のステップは、HyperThreading を使用しない方が優れているアプリケーションを見つけることです。これにより、ハードウェア パフォーマンス カウンターを実行できます。どのように、またはどこで見つけることができるかについての提案はありますか?
ということで、まとめます。ハイパースレッディングのメリットが -10% から +30% の間であることはわかっています。パフォーマンスが 10% 低下する C アプリケーションが必要です。
ありがとう。
おそらく、ハイパースレッディングの主な欠点は、キャッシュサイズを効果的に半分にすることです。各スレッドはキャッシュにデータを投入するため、事実上、各スレッドには半分のキャッシュがあります。
ハイパースレッディングを使用しない場合よりも実行率が低いプログラムを作成するには、L1キャッシュ内にぴったり収まるタスクを実行するシングルスレッドプログラムを作成します。次に、ワークロードを共有する2番目のスレッドを追加します。これは、データの「もう一方の端」からの作業です。パフォーマンスが低下することがわかります。これは、両方のスレッドがL2キャッシュにアクセスする必要があるためです。
ハイパースレッディングは、パフォーマンスを劇的に改善または悪化させる可能性があります。それは完全に使用に依存しています。この-10％/ + 30％のものはどれも-それはばかげています。
David が指摘したように、私は HT のコンパイラの最適化にも、i7 HT と P4 の違いにも精通していません。ただし、いくつかの一般的な動作は期待できます。
コンテキストの切り替えは非常にコストがかかります。したがって、1 つのコアで 2 つのスレッドを同時に実行する場合、一方のスレッドをもう一方のスレッドから切り替えると、常にパフォーマンスが低下します。ただし、スレッドは常にコアを使用するわけではありません。たとえば、スレッドがメモリの読み取りまたは書き込みを行う場合、通常は 100 サイクル以上、コアを使用せずにメモリ アクセスが完了するのを待ちます。スレッドがこのように停止する必要があるケースは他にもたくさんあります。たとえば、I/O 操作、データの依存関係などです。ここで HT が役立ちます。待機中の (またはブロックされた) スレッドを出荷し、代わりに別のスレッドを実行できるからです。
したがって、すべてのスレッドがブロックされる可能性が本当に低い場合、コンテキストの切り替えはオーバーヘッドのみを引き起こすと考えることができます。小さなデータセットで動作する非常に計算量の多いアプリケーションについて考えてみてください。