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の場合、コマンドを表記すると、

などです。

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

などです。

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

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

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

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には#５６から#６３コアが割り当たっていました。

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

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

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

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

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

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

【環境】

• Xeon E5-2680v4 (14Core/2.4GHz/35MB/QPI 9.6GT/120W) x 2個
• 8GB DDR4-2400 ECC REG 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

スレッド数1、7、21、28での結果が以下のグラフです。(スレッド数１ではhimenoBMTxp_l size Lの結果、スレッド数7、21、28ではcc_himenobmt_mpi size Lの結果です。)

スレッド数7程度で、メモリ帯域を使い切ってしまうのかスコアが収束しているように見えますが、28スレッドでは42000 MFLOPS程度のスコアが出ました。

計測したシステムには、1CPU当りメモリ4枚が取り付けられ、 最適なメモリモジュール配置構成(quad-channelで動作)で計測を行いましたが、あえてメモリモジュールを各CPUから1枚づつ取り外して、計測した結果が、マゼンタで表示されている箇所です。

最適にメモリモジュールが配置されている場合には、42000 MFLOPS程度の性能が出ていますが、おおよそ半分程度までスコアが下がっています。メモリを適切に配置することは、重要と言えます。

Compiler: gcc 4.8.5
Benchmark: himenoBMTxp
Size: L

[TABLE=19]

Skylakeアーキテクチャー・ワークステーション用CPU「Xeon E3-1230v5」のベンチマーク記録を追加しました。コンパイラーは、gcc 4.8.5を利用しました。

Compiler: gcc 4.8.5
Benchmark: himenoBMTxp
Size: L

[TABLE=22]

Haswell Refreshアーキテクチャー・プロセッサーCPU「Core i3-4170 」のベンチマーク記録を追加しました。コンパイラーは、gcc 4.8.5を利用しました。