さまざまなハードウェアでのビルド時間の比較。なぜ非線形の結果ですか？

Question

ディスク（NVMeとHDD）とCPUベンチマークのパフォーマンスが大幅に異なっていても、時代ごとのCPU間でコンパイル時間が大幅に変わらないのはなぜですか？
Ryzen CPUでハイパースレッディングを無効にするとパフォーマンスに大きな影響を与えるのはなぜですか？

過去数か月の間に、リリースから約9年と最近リリースされたものから変化するCPUを備えたLinuxを実行しているいくつかの異なるマシンを見てきました。新しいCPUは cpubenchmark.net からはるかに高いベンチマーク番号を受け取りました。 Ubuntu 18.04を使用したLinux 4.4.176カーネルのコンパイル時間を含む以下の詳細。

簡単に言うと、 cpubenchmark.net で複数倍高速にスコアリングしたCPUは、同じ要因でコンパイル時間を短縮しませんでした。実際、わずかな改善が見られることもありました。

変更または修正するためのボトルネックは何ですか？ Ryzenマシンには、最新のハードウェアガジェットがすべて搭載されています。それとも、これは合成ベンチマーク対現実のケースですか？

この質問は、コンパイル時間の比較によるベンチマークのトピックに触れていますが、確認されたビルド時間の（欠如）変動については触れていません。

最近のRyzen 2950Xシステム

シングルスレッド評価：2208

ディスク：NVMe

ソース：Linuxカーネル、4.4.176、Ubuntu Xenialの.configでコンパイル

呼び出し：make -j32

コンパイル時間：25997u 4910s17:25ウォールタイム

同じシステム、ハイパースレッディング（またはAMDが呼び出すもの）がオフoff

ソース：Linuxカーネル4.4.176、同じ.configファイル

呼び出し：make -j16

コンパイル時間：10561u 1796s13:44実時間

これは、コンパイル時間を20％以上削減し、17：25から13:44までの3分41秒の差に相当します。ハイパースレッディング機能を無効にするだけです。

新しいデータ、2019-03-08

コンパイル時間は実際には単調に減少しましたが、線形ではなく、make -j12まで、12のプロセスで12:46を使用しました。その後、コンパイル時間はmake -j24の最後の実行までゆっくりと単調に増加しました。これらのテストでは、ハイパースレッディングはoffでした。

ボトルネックが何であれ、12個の並列スレッドの後にヒットします。

新しいデータ-2019-03-27

X.M.Pを調整した後メモリプロファイルですが、シングルチャネルアクセスでも、16スレッドで最小値が10：08.5に達するまで時間が短縮されました。コアと同じ数のスレッド（HTが無効）。 1つの例外を除いて、コンパイル時間は32スレッドでゆっくりと10:41に増加しました。

デュアルチャネルメモリが有効になると、17スレッドで時間が6：47.5に減少しました。この時点の後、タイミングは上下に揺らぎ、20スレッドでさらに最低6：46.6になりました。これはおそらくまぐれであり、最小点に到達する決定的な点ではない可能性があります。この場合、最大24のスレッドのみがテストされました。

メモリは巨大な要素であり、このプロセッサのボトルネックのようです。メモリが最適に構成された後、問題の処理スレッドを増やすことは、多くのことを助けたり妨げたりするようには見えません。

結論

メモリはこのCPUの主要な潜在的なボトルネックであり、プロセッサを利用するには適切に構成する必要があります。
プロセッサと同じ数のスレッドの古い規則が保持されているようです。
ハイパースレッディングは最初のテスト以外ではテストされなかったため、その領域で結論を出すことはできません。シングルチャネルメモリのデフォルト構成では、ハイパースレッドコアでメモリアクセスが不足している可能性があります。

casualcoder · Accepted Answer

これは、ソフトウェアエンジニアリングの問題ではなく、ハードウェアの問題であることがわかります。

最近のBIOSにはX.M.P。と呼ばれるメモリ設定があります。この設定は、デフォルトでは、メインボードがサポートするメモリの最小公分母です。インストールされているメモリを最大限に活用するには、BIOSに移動してX.M.Pを設定する必要があります。プロフィール。この場合、デフォルトの設定以外に使用できるプロファイルは1つだけのようです。

もう1つの問題は、デュアルチャネルメモリアクセスとシングルチャネルメモリアクセスの設定です。この設定を有効にするためにメモリを取り付ける方法を決定するために、マニュアルで少し時間がかかります。

いくつかの異なるソフトウェアを使用したテストビルドでは、X.M.Pが向上したため、ビルド時間が20％以上短縮されました。設定対以前のデフォルト設定。したがって、より良いパフォーマンスが期待されます。

調整したら、比較のために最終的な数値を報告します。

2019-03-27結論

メモリは、このCPUの主要なボトルネックでした。詳細と結論については、質問を参照してください。

この質問はあまり関心を集めていないため、誰かが具体的に質問しない限り、これが最後のエントリになる可能性があります。

Robert Harvey · Answer

私の頭の上からちょうど：

コンパイル時間に影響を与えるのはCPUパフォーマンスだけではありません。
ベンチマークでは、実際のプログラムに影響を与えるパフォーマンス要因が常に考慮されるわけではありません。
キャッシュアフィニティは、CPU速度よりも大きな要素になる場合があります。
コンパイラーは常に並行性メカニズムを効果的に活用するわけではありません。
一般に、コンパイラーのようなプログラムは、特定のCPU特性を利用する（または利用できない）方法で作成できます。
同時実行メカニズムにはオーバーヘッドがあります。ソフトウェアが提供される同時実行から何の利益も得ていない場合、結果はネガティブになります

要するに、それは複雑です。コンパイルのような非常に複雑なタスクは、必ずしもベンチマークによって適切にモデル化されているわけではありません。ハードディスクのシーク時間やコードの記述方法など、全体的なパフォーマンスに影響を与えるその他の現実的な要因を考慮する必要があります。

これの単純だが劇的な例については、 here を参照してください。

Simon B · Answer

大規模なプロジェクトのコンパイルには、数百のソースファイルの読み取りや数百の中間（オブジェクト）ファイルの書き込みが含まれる場合があります。次に、これらすべての中間ファイルを再度読み取り、完成した実行可能ファイルまたはライブラリをコンパイルします。

多くの場合、最大のボトルネックはCPUではなく、ディスクサブシステム（ディスクドライブ自体とディスクコントローラー）です。

マルチコアまたはハイパースレッドのCPUは、それぞれが異なるファイルを要求する複数の同時読み取りまたは書き込み要求をディスクサブシステムに送信することにより、システムをさらに混乱させる可能性があります。ディスクのシーク時間が長い場合、シングルコアCPUと比較すると、パフォーマンスが低下する可能性さえあります。

ファイルがリモートサーバー上にあり、ローカルマシン上のドライブとしてマップされている場合、ディスクパフォーマンスの影響は特に深刻になります。