Intel Xeon Silver 4114 (Skylake-SP) Linpckベンチマーク

Skylake-SPがリリースされて以来、ベンチマーク走らせていなかったのでやってみました。

■ハードウェア構成

CPU: Intel Xeon Silver 4114 (10core x2CPU)
MEM: DDR4-2400 128GB (16GB x8 枚 )
OS: CentOS 7

■ベンチマーク
HPL 2.2
# プロセスで使うメモリは、おおよそ 32GB 程度に調整

・環境1
GCC: 8.2.0
BLAS: Atlas 3.10.3
MPI: OpenMPI 3.1.1

・環境2
Intel Compiler: 2018 update3 Cluster Edition
BLAS: Intel MKL
MPI: Intel MPI

■スコア
・環境1
Compiler option: mpicc -Ofast -march=native
Score: 223.2GFLOPS
Core frequency: 2.2GHz

・環境2
Compiler option: mpiicc -Ofast -xCORE-AVX512
Score: 413.6GFLOPS
Core frequency: 1.4GHz

■補足情報
Intel Skylake-SP は並列計算時に、 AVX未使用時 AVX2使用時 AVX512使用時で各々にBase frequencyが決まっています。
そしてTurbo Boostにて、各々のBase frequencyに対しプロセスを動かすコア数ごとに動作周波数が変動します。

・AVX未使用時 （10Core動作）
Base frequency: 2.2GHz
Turbo frequency: 2.5GHz

・AVX2使用時 （10Core動作）
Base frequency: 1.8GHz
Turbo frequency: 2.2GHz

・AVX512使用時 （10Core動作）
Base frequency: 1.1GHz
Turbo frequency: 1.4GHz

■評価
前提とする最大理論性能を以下に示します。
AVX未使用時Turbo frequency = 2.5GHz x 4 演算 x 10core x 2CPU = 200GFLOPS
AVX2使用時Turbo frequency = 2.2GHz x 8 演算 x 10core x 2CPU = 352GFLOPS
AVX512使用時Turbo frequency = 1.4GHz x 16 演算 x10core x 2CPU = 448GFLOPS

・環境1のスコアについて
「 -march=native 」指定しているので、 AVX512 なコードを出していると期待している。
実際に AVX2 アーキテクチャの CPU で実行するとエラーを吐いて動作しないことから、少なからずAVX512 なコードになっているのではないか？
しかし、 AVX512使用時Turbo frequency 1.4GHz で動作していない。
考えられることとしては、 GCCでは中途半端にAVX512なコードを出しているだけで(ほとんど AVX2 なコードに近いのか?) AVX512 を最大限最適化していないと見えます。そのためにAVX2使用時Turbo frequencyと同じ 2.2GHz で動作していると見える。
仮に AVX2 のコードと仮定して理論性能と比較しても、実際のスコアは 223.2GFLOPS ですので、最大理論性能の 63% となります。
# これはリーズナブルな値と言えるのか。。。

・環境2のスコアについて
スコアは 413.6GFLOPS ですので、理論性能の 92% となります。
もはやSkylake-SPでは、開発環境にIntelコンパイラとIntel MKLを選択しない理由は無いのではないか?と思える結果でした。

以上

AMD EPYC 7501 + 32GB DDR4-2666 性能評価

EPYC1CPU当たり32コアを持つEPYC 7501 x 2個と、32GB DDR4-2666 x 32枚（合計1024GB）を搭載するシステムPOWER MASTER Server S5081にて、姫野ベンチマークによる計測を行ってみました。

ちなみに、AMD EPYCには8coreのダイが4つパッケージに入っていて、各々のダイにはメモリ2chとPCIE x16 2本が接続できる構成となっているとのこと。1CPUでメモリ8chとPCIE x16 8本も持っているのです。

【環境】

    CPU：EPYC 7501 x 2個
    メインボード：Supermicro H11DSU-iN
    メモリ：32GB DDR4-2666 ECC Registered x 32枚（合計1024GB）
    OS：CentOS7.3 x86_64

【テスト】

① シングルスレッド評価

    Compiler: gcc 7.2.1
    Benchmark: himenoBMTxp_l（C, dynamic allocate version）
    Size: L

② マルチスレッド評価

    MPI: mpich3.2
    Compiler: gcc 7.2.1
    Benchmark: cc_himenoBMTxp_mpi（C + MPI, static allocate version）
    Size: L、XL

【結果】

[TABLE=26]

[TABLE=27]

(SMT: Simultaneous MultiThreading)

Xeon E5-2680v4とEPYC 7501のシングルスレッド値で比較すると、 EPYC 7501は、Xeon E5-2680v4よりも 約1.35倍の高い結果となっています。

並列計算でもスレッド数64で良い結果となっていますが、スレッド数128では値が少し下がっていて、このあたりがメモリ帯域の限界ではなかろうか？

いずれにしても、すでに持っているバイナリ（アプリケーション）で、パフォーマンス向上を目指すならば、AMD EPYCは良い選択肢となるかもしれません。

Ryzen 7 1800X + 8GB DDR4-2400 性能評価（姫野ベンチ）


1CPU当たり8コアを持つRyzen 7 1800Xと、8GB DDR4-2400 x 2枚（合計16GB）を搭載するシステムPOWER MASTER A9391にて、姫野ベンチマークによる計測を行ってみました。

【環境】

    CPU：Ryzen 7 1800X
    メインボード：ASUS PRIME B350M-A
    メモリ：8GB DDR4-2400 x 2枚（合計16GB）
    OS：CentOS7.3 x86_64

【テスト】

① シングルスレッド評価

    Compiler: gcc 4.8.5
    Benchmark: himenoBMTxp_l（C, dynamic allocate version）
    Size: L

② マルチスレッド評価

    MPI: mpich3.2
    Compiler: gcc 4.8.5
    Benchmark: cc_himenoBMTxp_mpi（C + MPI, static allocate version）
    Size: L

【結果】

[TABLE=25]

Xeon E5-2695v4搭載システム　姫野ベンチマーク評価

1CPU当たり18コアを持つXeon E5-2695v4を2個と、256GB(32GB DDR4-2400 ECC REG x8枚)を搭載するシステムPOWER MASTER Vision S4382にて、姫野ベンチマークによる計測を行ってみました。

【環境】

  • Xeon E5-2695v4 (18Core/2.1GHz/45MB/QPI 9.6GT/120W) x 2個
  • 32GB DDR4-2400 ECC Registered x 8枚
  • Supermicero X10DAi
  • OS：CentOS7.1 x86_64
  • GNUコンパイラ：GCC 4.8.5
  • OpenMPI：1.8.5
  • 姫野ベンチ：himenoBMTxp_l size L
  • 姫野ベンチ並列バージョン：cc_himenobmt_mpi size L

NUMAノードを確認すると、node0には#０から#1７コアが、node1には#1８から#3５コアが割り当てられていました。（Hyper-Threading分まで含めると、node0には#０から#1７コアと#36から#53、node1には#18から#35コアと#54から#71まででした。）

スレッド数1、2,4,8,16,32,36,72での結果が以下の青色で示す棒グラフです。(スレッド数１ではhimenoBMTxp_l size Lの結果、スレッド数2,4,8,16,32,36,72ではcc_himenobmt_mpi size Lの結果です。)

ベンチマークを行う際、なるべくジョブを各NUMAノードに均等に配分する様に実行しました。例えば、8 threadsの場合、コマンドを表記すると、

$ taskset -c 0-3,18-21 mpirun -n 8 ./bmt

などです。

また、4, 8, 16 threadsのみとなりますが、片方のNUMAノードにのみでジョブを実行した場合の結果もグラフに、マゼンタで示してあります。実行時のコマンドも表記すると、

$ taskset -c 0-7 mpirun -n 8 ./bmt

などです。

特に面白い結果が4, 8, 16 threadsにおいて、各NUMAノードへ均等にジョブを割り当てた場合と、片側NUMAノードにのみジョブを実行した場合です。

片側NUMAノードへジョブを割り当てた場合には、各NUMAノードへ均等にジョブを割り当てた場合と比べて、分割数４では１０％程度、分割数８では２０％程度、分割数１６では４０％程度落ち込んでいます。

１つのNUMAノードへのジョブが集中しない様に、分配する方が良いパフォーマンスを得られることがわかります。