catch-img

バイオインフォマティクスアプリケーションにおけるSMT ON/OFFの比較

HPC(High Performance Computing)の環境において、HT(Hyper-Threading)、SMT(Simultaneous Multi-Threading)はOFFにするというケースが多く、私達も習慣的にOFFにしておりました。
実行中の使用率が常時100%となるようなHPCアプリケーションではそもそも効果が薄かったり、オーバーヘッドにより性能に悪影響が出るケースがあるといったことがその理由ですが、多くのベンダーその他のベンチマーク結果を見てもOFFとしているケースがほとんどかと思います。
実際、最近リリースされた第五世代のEPYCのWorkload別Tuning Guideのp32を見てもHPC用途としての推奨は、SMTはDisableにするように書かれています。
ただ、弊社が取り扱っているAAS-G1の場合、SMTをONにするとOFFの時に比べてaas-matchの実行性能が2,3割高かったということがあり、それを受けて下記の3つのアプリケーションで比較をしてみました。

  1. bwa-mem2
  2. minimap2
  3. gromacs

bwa-mem2, minimap2はそれぞれマルチスレッドで実行はできますが、MPI並列には対応しておらず、スレッド数を増やしていった場合に性能がそれほどリニアに伸びません。そのため、多数のジョブをSlurmで投入して実行時間を比較するというあまりベンチマークっぽくない(しかし、実際のユーザーの実行状況に近い)方法で比較をしています。
一方、gromacsはMPI並列に対応しているので全コア使って1つのジョブを実行する比較を行っています。

目次[非表示]

  1. 1.実行環境
  2. 2.実行結果
    1. 2.1.1. bwa-mem2 (25ジョブ)
    2. 2.2.2. bwa-mem2 (12ジョブ)
    3. 2.3.3. minimap2 (48ジョブ)
    4. 2.4.4. gromacs
  3. 3.まとめ

実行環境

[ Hardware ]


スペック
CPU

EPYC 9654(96core) x1

    Base Clock: 2.4GHz

    Turbo Boost(Max): 3.7GHz

    Turbo Boost(All-Core): 3.55GHz)

Memory

1536GB

   (DDR5-4800, 64GB x24)

Disk(データ領域)

7.6TB U.2 NVMe x1  

[ OS ]


バージョン
OS
Rocky Linux 9.4
Kernel

5.14.0-427.42.1.el9_4.x86_64

実行結果

1. bwa-mem2 (25ジョブ)

  • 実行概要
    • バージョン : 2.2.1(Pre-Build Binaryのavx2版)
    • Reference Genome : human_g1k_v37.fasta
    • 25組のペアエンドのfastqファイル
  • 比較内容
    下記の通り、SMT=ONにすると認識されるコア数が倍になりますのでそれに応じてslurmのスロット数を変更し、25個のジョブをslurmに投入して比較しました。25組のfastqファイルは大小さまざまなため、ジョブの投入順は同じになるようにしています。

SMT = OFF
SMT = ON
OSから認識されるコア数/スレッド数
96
192
Slurmで設定するCPU数
96
192
bwa-mem2の各ジョブのスレッド数
32
32
同時に実行されるジョブ数
3
6
実行コマンド : 
$BWA mem -t 32 $INDEX $FASTQ1 $FASTQ2 > $OUTDIR/out-JOBNAME.sam


  • 結果比較#1 : 全てのジョブが完了するまでの時間の比較
      左がSMT=OFF, 右がSMT=ONの時のグラフです。
      グラフの見方ですが、縦軸はSlurmのジョブID(Job Number)、横軸は最初のジョブの実行開始時間を0(起点)とした場合の時間(分)で、それぞれの水平方向のカラフルな線は各ジョブID毎の実行開始から完了までの時間を長さで表しています。
      
      序盤に実行時間の短いジョブ、後半から実行時間が長いジョブというようになったためか差が見えにくいグラフになりました。
      同時実行ジョブ数は、SMT=OFFの時の3に対して、SMT=ONの場合は6ですが、どちらも51~52分程度で全てのジョブが完了しています。

  • 結果比較#2 : 25個の各ジョブ毎の実行時間の比較
    こちらは、各ジョブ毎の実行時間を比較したグラフです。SMT=OFFが青、SMT=ONがオレンジです。実行時間の短い左側のグラフでは違いが見えないものの右の方では各ジョブ概ね2,3割はSMT=OFFの方が早く終わっています。ただ、同時に投入されるジョブがSMT=ONの方が早い分、全てのジョブが完了する時間は同程度に落ち着くという結果となりました。

2. bwa-mem2 (12ジョブ)

上の結果を見ると、実行時間が極端に異なるジョブが混ざっていると違いが見えにくい面がありました。
実行時間の長い順に12個のデータで再度実行した結果が下記のグラフです。
左(SMT=OFF)が3個ずつ、右(SMT=ON)が6個ずつ同時実行されていることが見えやすく、各ジョブ毎の実行時間の差も見えやすくなっていますが、全てのジョブが完了するまでの時間を比較すると右(SMT=ON)が数分短いという結果となりました。



3. minimap2 (48ジョブ)

  • 実行概要
    • バージョン : 2.28-r1221-dirty
    • Reference Genome : human_g1k_v37.fasta
    • 48組のペアエンドのfastqファイル

今回はbwa-mem2の2パターンに加えて、SMT=ONで192コア認識されているけれども、Slurm的には96coreのみという設定を加えて比較しました。
OSが起動している状態でSMT=ON ⇔ OFFを切り替えるという操作は実運用上は避けたいという意図によるものです。


SMT = OFF 

SMT = ON(A)
SMT = ON(B)

OSから認識されるコア数/スレッド数 

96
192
192

 Slurmで設定するCPU数 

96
96
192

 minimap2のスレッド数

32
32
32

同時に実行されるジョブ数 

3
3
6
実行コマンド:
$MINIMAP -ax sr -t 32 $INDEX $FASTQ1 $FASTQ2 > $OUTDIR/out-JOBNAME.sam
  • 実行結果#1 : 全てのジョブが完了するまでの時間の比較
    はっきりとした差が出ています。SMT=ONで192コアでは30分以内に全てのジョブが完了しましたが、残りの2つは約38分、41分という結果となりました。2回ずつ実行しましたが同様の結果でした。

  • 結果比較#2 : 48個の各ジョブ毎の実行時間の比較
    minimap2での各ジョブ毎の実行時間の比較です。各ジョブ毎の実行時間でSMT=OFFの方が速いのはbwa-mem2同様ですが、slurmで96coreと揃えた条件にもかかわらず、ほとんどのジョブにおいて、SMT=ONの方がSMT=OFFより若干短い実行時間となっている点は注目に値します。原因についてはわかりませんので今後も調査していきたいと思います。

4. gromacs

gromacsは上の2つと異なり1ジョブで比較しますが、MPIの並列数、OpenMP数で下記の4パターンで比較します。

  • 実行概要

  • 結果比較
    結果は以下の通り、SMT=OFFが一番良い結果となりました。SMT=ON(B)との性能差は小さいのでこちらでもよいような気がしますが、複数のユーザーで共有して利用する解析マシンの場合に、SMT=ON(B)のような使い方を推奨するのは難しいためOFFに最初からしていた方がよいと思います。


SMT=OFF
SMT=ON(A)
SMT=ON(B)
SMT=ON(C)
OSから認識されるコア数/スレッド数
96
192
192
192
MPI並列(-np)
96
96
96
​​​192
OpenMP(-ntomp)
1
2
1
1
結果(ns/day)
178.342
163.117
172.697
142.273

また、実行中のCPU負荷を比較したグラフが以下の通りです。SMT=OFFのグラフは最初から最後まで100%にべったり張り付いているのに対して
SMT=ONの場合のグラフはそれぞれ程度の差はあるもののギザギザになっている部分があり、このあたりが性能差に表れていると言えそうです。



まとめ

この結果を受けてSMTをONにすべきかOFFにすべきか、ということが言えればいいのですがなかなか難しいところです。アプリケーション次第という測定する前から半ばわかっているような結論にもしたくありませんので、もう少し具体的に検討してみたいと思います。

今回のベンチマークと実際の環境の違い

今回の測定環境と一般的なクラスタシステムを比較すると以下のような違いがあります。

  1. メモリ容量が潤沢  : 1.5TBのメモリを抱えている → ジョブ数が倍になってもメモリが逼迫したりすることが無い

  2. 入出力ファイルのストレージが高速 → 単体で実行したため、LocalのNVMeに読み書きを行いました。計算途中で3GB/s程度のI/Oも見られましたので多数の計算ノードから同時にアクセスされるHDDベースのNFSサーバーですと異なる結果となった可能性も十分にあります。

以上の点からNFSサーバーにメモリを減らした環境、NFSサーバーに対してファイルI/Oするような環境での測定の比較をした方がより一般に近い条件になるはずです。

SMT=ONにすることによる明らかなデメリットは?

gromacsの結果を除けば、SMT=ONにすること自体の性能面でのペナルティは無さそうです。

その他、上でも触れたように同時に実行されるジョブが倍になることにより、メモリ逼迫、あるいはディスクI/Oの逼迫が懸念されるようなケースでは避けた方がよさそうですが、そういった懸念が無い環境ではSMT=ONを試してみる価値はありそうです。


k-ohki
k-ohki