Skylake XeonのTurbo性能について

先月の話になりますが、IntelのXeonのE5-2600v4の後継の新しいXeonのCPUが発表されました。
今回からネーミングルールがIntel Xeon Scalable Processor Familyのもと
下記のような名称に変更となりました。(Skylakeはコード名で正式名称ではありません)

  • Platinum 81xx
  • Gold 61xx/51xx
  • Silver 41xx
  • Bronze 31xx

具体的にどういった点が変わったかについてはニュース記事などを参照して頂くとして
今回はタイトルの通り、Turbo性能に絞って書いてみたいと思います。

まず、CPUの製品一覧ページの表記が前世代も含めて変更になっていることに注目したいと思います。
これまでは、一覧ページにはベースクロックだけが表示されていたように思いますが
今回の変更からは、Turbo Boost時のMaxクロック周波数が先に表示されるようになっています。
(ブラウザの表示幅によって表示される項目数が変わるようです)

Turbo Boostというのは、熱的に余裕がある場合にCPUのクロック周波数を上げて性能を向上させる機能のことで
BIOSとOSの設定でONにしておけばあとはユーザーは気にせずとも勝手に上げ下げをしてくれます。

上記のURLには定格のクロック周波数とMaxのクロック周波数しか記載がありませんが、
Maxのクロック周波数というのは概ね1コア,2コア程度のみ使用している場合の動作周波数のことで、
Activeなコア数が増えるに従って、徐々に低下していきます。
ただ、全コアがActiveな場合でもクロック周波数は定格周波数まで落ちるということはなく、
定格に比べれば高い周波数で全コアが動作します。
先日確認した限りでは温度エラーのアラートが出るThresholdの温度に至るまではBoostされた周波数で動作していましたので
よほど温度環境が厳しい場合を除けば、基本的にはBoostされた周波数で動作するはずです。

そうなると気になってくるのは、何コアを使用した時にどんな周波数で動作するのかということですが、
Intelの公開されている資料に記載されていて、これについても仕様で決まっています。

E5-2600v4世代との比較のため下記の通りグラフにしてみました。
X軸がCPUの型番、Y軸がクロック周波数(GHz)となっていて、
青い点が各型番のベース周波数、赤い帯がターボ時の周波数の範囲を示しています。
(赤い帯の上端は1core,2coreのみActiveなときのActiveなコアのクロック周波数、
赤い帯の下端は全コア使用した際のクロック周波数です)

型番が多く全ては載せられませんでしたが、Skylake世代のPlatinum/Goldシリーズに関しては、
E5-2600v4世代よりもクロック周波数が高めになっていて、スペック上のターボ性能が向上していることがわかります。
(ベースクロックとMin Turbo Frequencyの間がE5-2600v4世代よりも広い傾向)

特に6154,6134,6128,5122などは、1コアだけ使用している時も全コア使用している時も3.7GHzで動作する仕様になっていて
定格がこれでいいのでは?と思ってしまいます。

具体的なアプリケーションでの性能については別の機会に紹介したいと思いますが、Turboまわりのスペックを比較するだけでも
クロック周波数の性能向上が期待できますね。

Univa Grid Engine : GPGPUのリソース管理(RSMAP)

GPGPUのリソース管理について

CPUの場合、どのコアが使われるのかのスケジューリングはkernelによって行われるため
ジョブスケジューラーは使用コア数・空きコア数などの数を管理するだけでリソースが適切に配分されますが
GPGPUの場合は、ジョブやジョブスケジューラー側でその配分を行う必要があります。
そうしないと複数のジョブが重複して同じGPUで実行されてしまうケースを回避できません。

Univa Grid EngineのRSMAPというリソースタイプを使うと、各ホストのGPGPUの数(搭載GPU数と使用中のGPU数)の管理だけでなく、
各GPGPUに付けられたIDも含めた数の管理が可能となるため、各GPGPUに適切にジョブを振り分けることができます。

demo script

  • 1ジョブあたりGPUを1つ使用するジョブです。”-l gpu=1″
  • マシンには2枚のGPGPUが搭載されています。
  • IDは、SGE_HGR_[リソース名]の変数として出力されますので、アプリケーション側が要求するデバイス指定の書式に合わせる必要があります。
#!/bin/sh
#$ -N TEST_GPU
#$ -l gpu=1

if [ ${SGE_HGR_gpu} = "0" ]; then
GPU="--gpu 0"
fi

if [ ${SGE_HGR_gpu} = "1" ]; then
GPU="--gpu 1"
fi

time python chainer-2.0.2/examples/mnist/train_mnist.py ${GPU} -o out/out_`date +%y%m%d-%H%M%S-%N`

RSMAPが無い場合の挙動

  • ジョブ投入後の状態は下記のようになっています。
  • 下記例では、数の管理はできているため3つ目以降のジョブは待ち状態(qw)となっていますが
    nvidia-smiで確認するとジョブは2つともID:1のGPUに投入されてID:0のGPUが使われていない状態です。
$ qstat
job-ID prior name user state submit/start at queue jclass slots ja-task-ID
------------------------------------------------------------------------------------------------------------------------------------------------
5123 0.50617 TEST_GPU beowulf r 08/02/2017 22:37:06 node.q@demo01 1
5124 0.50617 TEST_GPU beowulf r 08/02/2017 22:37:07 node.q@demo01 1
5125 0.50617 TEST_GPU beowulf qw 08/02/2017 22:37:33 1
5126 0.50617 TEST_GPU beowulf qw 08/02/2017 22:37:34

$ qstat -j 5123 | grep resource
hard resource_list: gpu=1

$ nvidia-smi pmon -o T
#Time gpu pid type sm mem enc dec command
#HH:MM:SS Idx # C/G % % % % name
22:37:45 0 - - - - - - -
22:37:45 1 40725 C 14 4 0 0 python
22:37:45 1 40736 C 58 18 0 0 python
22:37:46 0 - - - - - - -
22:37:46 1 40725 C 36 11 0 0 python
22:37:46 1 40736 C 36 11 0 0 python

RSMAPを用いた場合の挙動

  • 投入スクリプトは上と同じものを使用
  • qstat -j の出力に上の例では無かった”resource_map”行が表示されています。
    ホスト名(demo01)の後ろの(0)と(1) がGrid Engine側で認識しているGPUリソースのIDです。
  • 5159のジョブでID:0のGPGPUが使用されているため、5160ではID:1が使用されて重複なく振り分けられていることがわかります。
  • nvidia-smiの出力を見てもそれぞれのGPUにジョブが振り分けられていることがわかります。
$ qstat -j 5159 |grep resource
hard resource_list: gpu=1
resource map 1: gpu=demo01=(0)
$ qstat -j 5160 |grep resource
hard resource_list: gpu=1
resource map 1: gpu=demo01=(1)

$ nvidia-smi pmon -o T
#Time gpu pid type sm mem enc dec command
#HH:MM:SS Idx # C/G % % % % name
23:10:30 0 46000 C 58 20 0 0 python
23:10:30 1 46117 C 74 24 0 0 python
23:10:31 0 46000 C 77 28 0 0 python
23:10:31 1 46117 C 54 16 0 0 python
23:10:32 0 46000 C 55 19 0 0 python
23:10:32 1 46117 C 56 18 0 0 python

RSMAPその他の活用法

RSMAPはGPGPUやXeon Phiなどのコプロセッサ向けに開発されたものなのでそれらのデバイスを使う際には必要な機能となりますが、
RSMAP自体は、1台のホスト内に搭載されている複数のデバイスそれぞれにIDを付けてリソース管理が行えるというものなので
それ以外にも使いみちがありそうです。

例えば、Dual CPUのサーバーに2本のNVMe SSDが搭載されていて、それぞれがそれぞれのCPUのPCIeバス上にあるという構成の場合、
コアバインディングと組み合わせて近い方のBUSのNVMeをスクラッチ領域として使うことができ、アプリケーションによっては効果がありそうです。

tuned: tuning daemon

tuned について

tunedは、cpu,disk,kernelなどに関する複数のパラメーターを一括して一つのプロファイルとして保存し、
コマンド一発で設定・切り替えを行うことができるツールです。

CentOS7の場合は、tuned のパッケージにはあらかじめいくつかのプロファイルが用意されていて
その中で変更するだけでも性能の違いを実感できますし、その他にカスタムのプロファイルも作成することができます。

デフォルトで用意されているプロファイル

  • デフォルトで用意されているプロファイルには以下の9つがあります。
    また、tuned-profile-xxx といったパッケージ名で用意されたものをインストールすると
    RHELのAtomic Host、Laptop、Oracleといった環境向けの他、spindown-diskといったディスクの省電力向けの
    プロファイルも追加されます。
# tuned-adm list
Available profiles:
- balanced                    - General non-specialized tuned profile
- desktop                     - Optmize for the desktop use-case
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput.  Generally only necessary on older CPUs or 40G+ networks.
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads.  This is the default profile for RHEL7.
- virtual-guest               - Optimize for running inside a virtual guest.
- virtual-host                - Optimize for running KVM guests

設定方法

manページを見ると、throughput-performanceがRHEL7のデフォルトである旨のことが書かれていますが
実際にはbalancedとなっているケースが多いです。

$ tuned-adm active :  現在有効となっているプロファイルが表示されます。

$ tuned-adm profile balanced : 左のケースでは"balanced"というプロファイルに設定されます。
このコマンドを実行するだけで、OSやサービスの再起動の必要なく、すぐに設定が適用されます。

実際に変更されているパラメーター

パッケージに含まれているプロファイルについては、/usr/lib/tuned/[プロファイル名]/tuned.conf に
実際に変更されているパラメーターとその設定値が記載されています。

下記はthroughput-performanceのtuned.confで
cpupower, x86_energy_perf_policyで設定されるようなCPUの電力管理系のプロファイル、
ディスクのread_ahead_kbのサイズ、kernelのパラメーターに関して記載されていることがわかります。

----
[main]
summary=Broadly applicable tuning that provides excellent performance across a variety of common server workloads.  This is the default profile for RHEL7.

[cpu]
governor=performance
energy_perf_bias=performance
min_perf_pct=100

[disk]
readahead=>4096

[sysctl]
kernel.sched_min_granularity_ns = 10000000
kernel.sched_wakeup_granularity_ns = 15000000
vm.dirty_ratio = 40
vm.dirty_background_ratio = 10
vm.swappiness=10
----

性能の比較

結論から言えば、”throughput-performance” がたいていのケースではおすすめです。

ネットワーク、ファイルコピーの速度比較

  • InfiniBand : QDR
  • OS : CentOS7.2
  • Mode : Connected Mode
balanced network-throughput throughput-performance
Netperfでの速度比較 21,656 Mbps 23,909 Mbps 25,528 Mbps
ddで作成した10GBのファイルのコピー時間(NFS越し) 0m12.873s 0m8.616s 0m8.624s

fioでのIOPS測定

  • Device /dev/md0(NVMe x4)
  • Filesystem:XFS
  • Queue Depth : 32
  • numjobs: 1
Random Read(4K) Random Write(4K)
balanced 200569 IOPS 227951 IOPS
latency-performance 268315 IOPS 289342 IOPS

bowtie2 の実行時間比較

  • bowtie2 : 2.3.1
  • index : hg19
  • fastq : SRR067579_1.fastq, SRR067579_2.fastq,
threads throughput-performance
(intel_pstate)
balanced
(intel_pstate)
throughput-performance
(acpi_cpufreq)
8 2479s 2477s 2507s
16 1276s 1290s 1279s
32 679s 690s 676s
56 545s 649s 616s

NAMDの性能比較

  • NAMD : Nightly Build(2017-06-30)
  • data : stmv.namd
  • OS : CentOS 7.3
threads throughput-performance(ns/day) balanced(ns/day)
4 0.0578 0.0555
8 0.1083 0.1077
16 0.2094 0.2086
32 0.4028 0.3931
上の例では、ベンチマークツールで1-4割、アプリケーションレベルで数%から2割程度の性能差が出ています。

もちろん、常時"throughput-performance"に設定しておいても良いのですが、
コマンド一発でプロファイルの切り替えができるという特性を考えると
ジョブ実行前に"throughput-performance"に切り替え、ジョブ完了後に省電力モードに戻す
といった使い方(ジョブスケジューラーへのジョブ投入スクリプト内に追記)はシンプルで
効果もあるかもしれません。(省電力の効果のほどはいずれ確認したいと思いますが)

また、仮にアプリケーションやデータの種類などそれぞれに最適のプロファイルを用意できたとすれば
ジョブスケジューラー側の機能を使ってジョブの名前やその他の値から自動的にプロファイルを選択、
設定して実行させるいった使い方もできるのではないかと思います。

Univa Grid Engineの紹介

TakeruではこれまでデフォルトのジョブスケジューラーとしてOpen SourceのOpen Grid Schedulerを使ってきましたが、昨年からは同じくGrid Engine系ではあるものの有償版のUniva Grid Engine(以下、UGE)をデフォルトのジョブスケジューラーとしています。

主な背景として以下の2つの理由があります。

  • UGEがGPGPUやDockerに対応している点
  • UGEがOpen Grid Schedulerと同じコマンド体系である点

Open Grid SchedulerでもGPGPUのジョブやDockerのジョブを投入・管理することは可能です。
ただ、Open Grid Scheduler自体は2012年から開発が止まっているため、これらのテクノロジーに適切に対応できておらず、余分に手間がかかったり、不十分なリソース配分をしてしまう可能性があります。

今後の投稿では、Univa Grid Engineの以下のような機能について紹介をしていきたいと思います。

  • GPGPU/Xeon Phiなどのコプロセッサー対応
  • Docker 対応
  • JSV(Job Submission Verifier)
  • Job Class
  • その他

Takeru Boostについて

Takeru Boostは、
Takeruをより”Boost”して活用して頂くための情報を中心としたNabe Internationalの技術情報ブログです。
OSやアプリケーションの設定や性能比較、新しいハードウェアの紹介などをしていきたいと思います。

(こちらのブログで紹介した内容は、あくまで特定の環境下での動作を確認したものです。
実際にお使いのTakeruへの適用をお考えの場合は別途ご連絡頂ければと思います。)