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ノードへのジョブが集中しない様に、分配する方が良いパフォーマンスを得られることがわかります。

tasksetで姫野ベンチマークを実行するコアを指定する

Opteron 6380を利用するシステムで、姫野ベンチマークによる計測を行ったところ、
ジョブの割り当て方によって、スコアが大きく変わりましたので、その結果を紹介します。

【環境】

  • Opteron 6380 (16 Core/2.5GHz/16MB/115W) x 4個 で64コア
  • 4GB DDR3-1866 ECC Registered x 16枚
  • Supermicro H8QGi+-F
  • OS：CentOS7.1 x86_64
  • GNUコンパイラ：GCC 4.8.5
  • OpenMPI：1.8.5
  • 姫野ベンチ：himenoBMTxp_l size L
  • 姫野ベンチMPIバージョン：cc_himenobmt_mpi size L

検証した環境では６４個ものCPUコアを搭載しています。
NUMAノードを確認すると、node0には#０から#７コアが、node1には#８から#１５コア,…, node7には#５６から#６３コアが割り当たっていました。

$ cat /sys/devices/system/node/node0/cpulist
0-7
$ cat /sys/devices/system/node/node1/cpulist
8-15
..
..
$ cat /sys/devices/system/node/node7/cpulist
56-63

予め８個のコアを利用してベンチマークを実行するファイルｂｍｔ８.outを作成し、コア０−７を使った場合(１つのNUMAノードでジョブを実行させる場合)と、コア０,8,16,24,32,40,48,56を使った場合（８つのNUMAノードへジョブを均等に分割配分する場合）とで計測を実施しました。

$ taskset -c 0-7 mpirun -n ８ ./ｂｍｔ８.out ←①
$ taskset -c 0,8,16,24,32,40,48,56 mpirun -n ８ ./ｂｍｔ８.out ←②

①のスコアを1とするならば、②では３.３となりました。

また、１６個のコアをベンチマークを実行するファイルｂｍｔ１６.outを利用して計測も行いました。

$ mpirun -n 16 ./ｂｍｔ16.out ←③
$ taskset -c 0-15 mpirun -n 16 ./ｂｍｔ８.out ←④
$ taskset -c 0-1,8-9,16-17,24-25,32-33,40-41,48-19,56-57 mpirun -n 16 ./ｂｍｔ16.out ←⑤

tasksetにより実行するコアを指定しない③のスコアを１とするならば、②では０．４、⑤では1.2となりました。

これらから複数のNUMAノードへジョブを分散させて実行する方がパフォーマンスが良いことが分かります。