web-dev-qa-db-ja.com

サーバーCPUが同じベンチマークスコアのMacbook Pro CPUよりも高速なタスクを実行するのはなぜですか?

次のCPUとGeekBenchのスコアがあるとします。

  • Amazon EC2 z1d.largeインスタンス:Intel Xeon Platinum 8151 4061 MHz(1コア)シングルコアスコア:1094、マルチコアスコア:1300

  • Macbook Proラップトップ:Intel Core i5-8259U 2300 MHz(4コア)シングルコアスコア:1002、マルチコアスコア:4104

Xeonは、シングルスレッドベンチマークスコアで9.1%高速です。

ただし、両方のデバイスでJavaScriptアプリケーションコード(シングルスレッド)をコンパイルすると、Xeonはタスクを60%速く完了します。どうして?ベンチマークスコアによると、Xeonはわずか9%高速です。

どちらもNVMEドライブを備えているので、それがボトルネックになることはありません。 MacはLinuxベースなので、MacとLinux OSの問題もないと思います。

これは、Xeonがサーバー/デスクトップCPUであるためですか? Macbook Pro CPUはフルパワーで実行されておらず、Intel Turbo Boostがランプアップするのを待たなければならないのに対し、100%の速度とパワーで実行されていますか?

12
dandan

あなたが説明するタスク、Bableプロジェクトのコンパイル、および関連するCPUを考えると、パフォーマンスの違いの原因はわかっていると思います。私はもっ​​と早く答えたかったのですが、私の直感を確認するために少し調査をしなければなりませんでした。

最初に、システムにかける負荷を特徴付けます。

Babel.jsは、並列処理のために非同期I/Oを主に利用するシングルスレッド、シングルプロセスコンパイラとして記述されています(少なくとも、私がグーグルで調べたところ、ワーカースレッドを使用してそれを示しているものはありません)。ディスクからファイルをコンパイルするのはコンパイラなので、その実行の大部分はディスクからのデータの待機を伴います。これにより、次のワークロードが得られます。

  1. シングルスレッドなので、複数のコアまたはハイパースレッディングは、1つの警告でコンパイルに大きな影響を与えません。

  2. Node.jsはワーカースレッドを使用してディスクI/Oを処理しますが、2つまたは4つのハードウェアスレッドを超えて、複数のコアに追加の利点はありません(参照: https://nodejs.org/en/docs/guides/dont -block-the-event-loop /

  3. 並列処理のほとんどは、I/Oレベルで行われます。 Babelはできるだけ多くのファイルを並行して読み取ろうとします。

I5とXeonはどちらも、ポイント1と2に関してかなり同等です。それでは、CPUがポイント3をどのように処理できるかを見てみましょう。Babelの並列ファイル読み取り要求に対応します。

2つのシステムの最初の大きな違いは次のとおりです。

  • Core i5 8259には16のPCIレーンがあります

  • Xeon 8151には48のPCIレーンがあります

したがって、Xeonはi5よりも多くの並列I/O操作を処理できます。利用可能なメモリ転送レーンの数よりも多くのI/Oがある場合、OSは、利用可能なハードウェアスレッドの数よりも多くのタスクがある場合と同じ方法で処理します。それは、それらをキューに入れ、順番に強制します。

次に、NVMEが実際に複数のレーンを使用できるかどうかを知りたいと思いました。これは私が別の興味深い事実にぶつかったところです。 NVME標準では、カードは最大4つのPCIレーンを使用できます(物理的に割り当てられた接続は物理的に多くあります)が、2つしか使用しないカードもあれば、4つ使用するカードもあります。したがって、すべてのNVMEカードが同等に作成されるわけではありません。これだけでも、BabelがRAMに並行してコピーできるファイルの数が2倍になり、帯域幅がほぼ2倍になります。

また、NVMEスロットがCPUに接続されている方法にも依存します。 16のPCIレーンしかないCore i5は、間違いなくそのうちの少なくとも8つをGPU用に予約します。他のデバイスと共有するために8つだけ残します。つまり、NVMEカードがWifiまたはその他のハードウェアと帯域幅を共有する必要がある場合があります。これはもう少し遅くなります。

また、NVMEがCPUのPCIレーンに直接接続されていない場合もあります。 Macbookは実際にGPU用に16レーンすべてを予約し、サウスブリッジ(追加のPCIレーンがある場合があります)を介してNVMEに接続します。 Macbookがこれを行うかどうかはわかりませんが、これでもパフォーマンスが少し低下する可能性があります。

対照的に、Xeonが備えている多数のレーンにより、マザーボードの設計者は非常に高速なI/Oプラットフォームをより自由に作成できます。さらに、AWSサーバーには通常GPUがインストールされていないため、GPUを使用するためにレーンを予約する必要はありません。繰り返しますが、AWSサーバーの実際のアーキテクチャは個人的に知りませんが、Babelプロジェクトのコンパイル時にMacbookよりも優れたアーキテクチャを作成することは可能です。

つまり、最終的にEC2インスタンスがMacbookよりも優れたパフォーマンスを発揮できる主な要因は次のとおりです。

  1. CPUが直接サポートするPCIレーンの数

  2. NVMEドライブがサポートするPCIレーンの数

  3. NVMEレーンがCPUに接続される方法

寄与する可能性のあるその他の要因には、次のものがあります。

  1. I/Oバスの速度(PCI2とPCI3など)

  2. RAMの速度

  3. DMA使用可能なチャネルの数(これだけでは長い回答が必要なので、スキップしましたが、理由はPCIレーンに似ています)

4
slebetman

ベンチマークは、システムの他の要因を考慮に入れないことが多い、非常に具体的なパフォーマンス特性(ピークインストラクションレート)に対するあいまいな波形です。

プログラムに大きな変化をもたらす可能性があるものの、ピークの指導率ではないものの網羅的ではないリスト:

  • メモリ。タイプ、帯域幅、チャネル。これらはすべて、データがCPUに到達して動作する速度に違いをもたらします。サーバーには通常、デスクトップまたはラップトップのCPUよりも多くのRAMチャネル、より多くの量、およびはるかに高いピーク帯域幅の数値があります。シングルコアの命令レートが高くても、そのレートに達するのに十分な速さでCPUにデータを取得できない場合、何のメリットもありません。
    簡単なチェックとして、私は一見して 8180 Xeon (見つけた最も近い)には6つのメモリチャネルがあり、ラップトップのCPUには(うまくいけば)2つのチャネルがセットアップされています(または設計が不十分で、1つしかなかった可能性があります)。サーバーには、ラップトップの3倍のメモリ帯域幅があります。これは、メモリを集中的に使用するタスクに大きな違いをもたらします。
  • ハードディスク。より高速なハードディスク、SDDなどは、CPUが動作するためにデータをメモリに取得する際に大きな違いを生む可能性があります。 SSDは、データの小さなビットをシークするために桁違いに速く、バルク転送もはるかに高速です。 NVMeがさらに高速になりました。サーバーは多くの場合、バックアップにRAIDを使用するか、未処理の速度に設定できます。どちらもNVMeの場合もありますが、サーバーファームはRAID 0または01のエンタープライズクラスのディスクを備え、単一のディスクよりも高速である可能性があります。
  • 熱制限。ベンチマークは、特にラップトップやウルトラポータブルマシンでは、最初のパフォーマンスの増加を確認できるほど長く続く傾向があります。ファンが熱出力に追いつくことができず、その初期のターボブースト速度が「通常の」ピーククロック周波数まで低下するため、時間が経つとリザーバーがいっぱいになります。これにより、ベンチマーク結果が歪められ、長期的な負荷がかかった場合よりもラップトップの外観が大幅に改善されます。サーバーは、パフォーマンスを確保するために、仕様を超えた(そして大音量の)冷却システムを採用する傾向があり、ラップトップは静かな家の快適さを実現するように設計されており、ファンははるかに強力ではありません。ベンチマークに表示されるものは、目の前にあるものと同じ熱制限を持たない場合があり、パフォーマンスも低下し、制限が早くなる場合があります。
  • ボトルネック。サーバーには、ラップトップよりもはるかに多くのI/Oがあります。より多くのPCIeチャネル、より専用のIOポートおよびペリフェラルへのはるかに高い帯域幅は、競合しないパスを通過するより多くのデータを意味します。16レーンCPUに接続されたマルチプレクサで時間を争う複数のPCIeデバイスは40以上の専用レーンを持つCPUよりも遅い。
  • コア。より多くのコアがあることは、1つのコアで実行しているタスクだけでなく、タスクが時間のために戦っていないことを意味します。トレードオフは、バス時間を争うコアの数が多いほど、メモリ帯域幅の制限に到達しやすくなることです。
  • キャッシュ。サーバーCPUは、はるかに大きなCPUキャッシュを持つ傾向があります。これはより最適化されていますが、キャッシュが大きいほどメモリへの移動時間が短くなり、CPUが小さいキャッシュよりも最大のパフォーマンスを発揮できるようになります。シングルコアのベンチマークは、ほとんどのキャッシュサイズに収まるほど小さいので、システムの他の部分については何もわかりません。
  • グラフィックス。 PCIe /メモリバスの競合に関連して、ラップトップはグラフィックス機能を実行します。おそらくiGPUを使用します。これは、グラフィックディスプレイを駆動するために、システムメモリが使用されている(およびメモリ帯域幅が盗まれている)ことを意味します。サーバーにはおそらくそれがなく、おそらく計算クラスタのヘッドレスノードです。サーバーのグラフィックオーバーヘッドははるかに少なくなります。

消費者クラスのCPUは確かに強力ですが、サーバークラスはより広いシステムに対してはるかに多くのロジック、制御、および帯域幅を持っています。一般的には、それで結構です。 15ワットのプロセッサが、140ワットの電力バジェットを備えた10倍の高価なCPUと同じように機能するとは予想していません。その追加の電力バジェットは、より多くの自由を与えます。

サーバーのCPUのパフォーマンスがデスクトップまたはラップトップのCPUと同じである場合、2つのCPUは区別されません。

ポイントをさらに詳しく説明するために、同様のシングルコアスコアは、coresが理想的な条件下で合理的に比較可能であることを示しています。それらは理論的にはパフォーマンスの点で近いかもしれませんが、より広いシステムや他のコンポーネントに接続したときにCPUが何ができるかについては何もわかりません。シングルコアの速度は、システム内の1つの小さなポイントに人為的に集中しているため、システムの通常のほとんどの使用が遭遇するよりも多くなります。

あるシステムが別のシステムよりも「優れている」理由の詳細については、いわゆる「現実の世界」のベンチマークをさらに調べる必要があります。これは、(まだ人工的ですが)より匹敵するシステムを示しますパフォーマンスメトリックとボトルネックがどこにあるかもしれないかについての考えを提供してください。さらに良いのは、実行した種類のテストを実行することです。これは、そのワークロードについては、サーバークラスシステムが基盤となるアーキテクチャとコンポーネントを備えているため、はるかに優れていることを示しています。

50
Mokubai

木梅の優れた答えに加えて:

  • 命令セット拡張。 AVX-512などの一部の拡張機能は、サーバープロセッサー(質問で述べたSKXプロセッサーなど)で使用できますが、コンシューマープロセッサーでは(または後でのみ)使用できません。たとえば、問題のCoffee LakeコンシューマーCPUはAVX-512をサポートしていません。コンパイラはこれによる影響があまり大きくないと思いますが、科学計算や機械学習などの特定の数値タスクを実行すると、違いが生じる可能性があります。

  • コア相互接続。シングルスレッドタスクには関係ありませんが、複数のコアが使用されている場合、相互接続のタイプは、コアが互いに通信できる「速度」に影響を与えます。コンシューマプロセッサはリング相互接続を使用しますが、サーバープロセッサは メッシュ相互接続 を使用する最初のプロセッサです。

10
mrks

Intel Xeon Platinum 8151仕様 Intel Corporationから

Intel i5-8259U仕様 Intel Corporationから

  • Xeonには38.5 MBのL3キャッシュがあるようです
  • インテルCore i5-8259Uには6 MBのインテル®スマートキャッシュしかないようです

プロセッサキャッシュは、メインシステムメモリに依存する代わりに、最近書​​き込まれた値または読み取られた値をプロセッサが格納する場所です。

  • キャッシュはあらゆる種類の形状とサイズで設計されていますが、悪用を容易にするいくつかの古典的な特徴があります。キャッシュは通常、関連性が低く、バンクセレクターを利用します。連想キャッシュ
  • 典型的なプロセッサキャッシュ内では、特定の物理(またはデザインによっては論理)アドレスがキャッシュ内の場所にマップされている必要があります。これらは通常、キャッシュラインと呼ばれるメモリの単位で機能します。メモリのサイズは、16バイトの小さなラインから64バイト、さらには128バイトのラインまでとさまざまです。
  • 2つのソースアドレス(またはキャッシュライン)が同じキャッシュアドレスにマップされている場合、そのうちの1つをキャッシュから削除する必要があります。
  • エビクションとは、失われたソースアドレスが次に使用されるときにメモリからフェッチする必要があることを意味します。完全に関連付けられたキャッシュ(完全に関連付けられたメモリまたはCAMとも呼ばれます)では、ソースアドレスはキャッシュ内のどこにでもマップできます。これにより、エビクションの発生頻度が低くなるため、キャッシュヒット率が高くなります。
  • このタイプのキャッシュは(ダイスペースの点で)高価であり、実装が低速です。キャッシュヒットのレイテンシを上げることは、通常、そうでなければキャッシュミスのペナルティをわずかに節約するだけの価値はありません...詳細を読むことができます here

バスレートが高いDDR4も速度の向上に役立ちます。 Xeonに Transactional Synchronization Extensions があるのに対し、i5にはないことにも言及してください。

それらは同じクラスのプロセッサではありませんが、うまくいけば、上記の情報があなたを助け、インテルコーポレーションからのリンクが私の応答の妥当性を支援します。

7

あなたはもう一つのベンチマーク、「この特定のプロジェクトの構築」を発明しました。また、Amazonのビルド環境は、Macよりもはるかに優れていますATこの特定のベンチマーク。

CPU(およびストレージデバイス、およびコンピュータ全体、オペレーティングシステム、および構築環境)は、同等ではありません。 CPUは、利用可能な電力、冷却、スペース、コスト、および利用可能なテクノロジーに関するさまざまな制約に適合するように作られています。セットアップの他のすべてのコンポーネントも同様です。

ビルドタスクはCPUとメモリを集中的に使用し、ファイルシステムやプロセススケジューラの多くをロードしないため、OS(Linux、Mac OS、Windowsさえ)や基盤となるストレージシステムが異なるため、それほど大きな違いはないと思います。繰り返しになりますが、JSプロジェクトの構築はCやJava私が精通しているプロジェクトとは異なります。

LinuxとMac OSのビルドツールは、パフォーマンスがかなり異なる場合があります。それらは異なるコンパイラー、ライブラリー、最適化オプションなどで構築されている場合があり、これらはあなたが見る全体の違いをもたらすかもしれません。

2
fraxinus

他の回答に加えて、任意のベンチマークで使用される命令がコンパイラで使用される命令と一致しない可能性があることを付け加えます。基本的に、各プロセッサは、特定のタイプの命令でより高速になる場合があります。または、分岐予測の失敗など、特定のシナリオでは、他のプロセッサよりもパフォーマンスが向上する場合があります。

一方のコードは、もう一方のコードのパフォーマンスを予測するものであるとは限りません。それは彼らが異なることを異なる方法で行うからです。

たとえば、Q9550のような最新モデルのCore2プロセッサを33%オーバークロック(かなり可能)することができます。後者はより最近のものですが、多くのタスクでクロックの低い第2世代i5プロセッサと同等かそれを超える可能性があります。 。

ただし、高度なランダム性を備えた多数の分岐命令を含む一連のコードがある場合、分岐予測が失敗した場合のCore2プロセッサのパフォーマンスの低下により、i5はCore2を何回も上回る可能性があります。

この種のことは、あらゆる種類の命令と処理タイプについて、あらゆる種類のマイクロレベルで発生します。これが、1つのCPUがCinebenchベンチマーク(ビデオエンコーディング)ではより優れているが、SunSpiderベンチマーク(JavaScript)ではより悪い場合がある理由です。

2
metamorphosis

どちらもNVMEドライブを備えているので、それがボトルネックになることはありません。 MacはLinuxベースなので、MacとLinux OSの問題もないと思います。

その申し立てをバックアップしてください。 MacOSX は確かにUnixライクなOSであり、おそらくBSDまたはSVR4(1990年代のUnix)からのカーネルコードがたくさんあります。しかし、Unixは20年以上も前にLinuxよりも古くなっています。 history of Linux (および history of Unix で生まれました)をお読みください。ところで、私は1987年にSunOS3.2を使用しました。最初のLinuxカーネルは1991年にリリースされました。Linuxを使用しました1993年後半(カーネル0.99.12)のi486 PC。

しかし Linux には( kernel ランド内に)AFAIKがあり、その時代のソースコードはほとんどありません。

もちろん、MacOSXとGNU/Linuxの両方でいくつかのGNUソフトウェアを実行できます(特に GNU bash ))。

ついに9%がノイズマージン内にあります。たとえば、allを再コンパイルすることを検討しましたか? Linuxディストリビューションのソースコードから系統的にgcc -O3 -mtune-native -fltoコンパイル時とリンク時の両方で、latest[〜#〜] gcc [〜#〜]Gentoo のようないくつかのソースLinuxディストリビューションを使用してみたり、 LinuxFromScratch ガイドラインに従ってください。

ところで、サーバーコンピュータは、MacBook ProよりもUS $または€高くなります。それらの Dell 価格を見てください。サーバーのパフォーマンスが向上することを期待しています。たとえば、サーバープロセッサには CPUキャッシュコア があり、それによって違いが生じます。一般的なサーバープロセッサの価格は、MacBook Pro全体よりも高くなっています。たとえば、フランスではAND Ryzen Threadripper 2990WXは1 758€ であり、マザーボード、水冷装置、大量のRAMなどを購入する必要があります。同じリセラーが i5-8279U MAcBook Pro for 1 989€Dell PowerEdge R6525 Rack Server の値札はUS $ 2,689.00から始まります(送料が含まれているかどうかはわかりません)。

severalベンチマークを実行する必要があります。

など [〜#〜] spec [〜#〜] ベンチマーク(それらは cost 数千米ドル)。または OpenBenchmarking 。そして、ラップトップとサーバーの両方で、それらすべてを実行します。集合的に彼らはあなたのコンピュータの異なる部分を行使し、それから初めてあなたは彼らのパフォーマンスのより良い評価を得ます。