macでインフォマティクス

macでインフォマティクス

NGS関連のインフォマティクス情報についてまとめています。

ベンチマーク(2019)

2020 2/10 追記

2020 3/15 文章修正

2020 9/13  誤字修正

 

最近はZEN世代のCPUが高いパフォーマンスを出している。しかし、公開されている情報の多くはCPUの基礎的な特性を示すベンチマークだったり、ゲーミングや映像編集など需要が高い分野に限定されており、世間的にはニッチなバイオインフォマティクスのツールのパフォーマンスについての情報は乏しい。そこで、このブログ記事では実際にryzen7 3700xの計算機やインテル系CPUの計算機を使ってHTS関連のツールを動かし、そのランタイムから、ZEN2世代CPUがHTSのデータ処理においても有用なのか考えていく。結果が良好であれば、同じ規格のCore Complex (CCX)の組み合わせから成るEPYCやRyzen Threadripperも似た傾向が期待できる。

 

 

今回使用したハードウエア

1、3700x自作機

  •  CPU: Ryzen3700x 8コア (合計16スレッド)
  •  memory: DDR4 2667MHz 16B x 2 (合計32 GB)
  •  GPU: GTX1080
  •  system: drive: Crucial M2 SSD:1TB x1 (link)メモリキャッシュ機能は無効
  •  OS: ubuntu18.04LTS

2、MousePro(リンク

  •  CPU: xeon E5 2680 v4  2.4 GHz/14コア x 2 (合計56スレッド)
  •  memory: DDR4 ECC Registered 8GB x 16(合計128 GB)
  •  GPU: quadroK620
  •  system: drive: SATA3 SSD:1TB x2 (RAID0)
  •  OS: ubuntu18.04LTS

3、自作ワークステーション

  •  CPU: xeon E5 platinum  2.1 GHz/ 28コア x 2 (合計56スレッド)
  •  memory: DDR4 ECC Registered 64GB x 8 (合計512 GB)
  •  GPU: quadro K4000
  •  system: drive: SATA3 SSD:1TB
  •  OS: ubuntu18.04LTS

4、mac mini 2018上位

  •  CPU: core i7 8700B 6コア  (合計12スレッド)
  •  memory: DDR4 2667MHz 16GB x 2 (合計32 GB)
  •  GPU: CPU内蔵グラフィック
  •  system: drive: M.2 SSD 512 GB
  •  OS:  OSX mojave

5、Apple mac pro 2012 early (リンク

  •  CPU: xeon (Westmere EP) 3.46 GHz/6コア x 2 (合計24スレッド)
  •  memory: DDR3 1,333 MHz 8GB x 12 (合計96 GB)
  •  GPU: GTX 680
  •  system: drive: SATA3 SSD:512 GB x 3 (RAID0のストライピング)
  •  OS: OSX sierra

 

2020 2/10 追記

6、3990x自作機

  •  CPURyzen Threadripper 3990X  64コア (合計128スレッド)
  •  memory: DDR4 3000MHz 16GB x 8 (合計128 GB)
  •  GPU: GTX 1600
  • motherboard: TRX40 Taichi
  •  system: drive: Crucial M2 SSD:512GB x1
  •  OS: ubuntu18.04LTS
  •     CPUクーラー  ROG RYUJIN 360 ()

後から3990xをベンチマークすると、再現性が疑われる結果になってしまいました。何かバージョン管理できていないライブラリがある可能性があります。追記はしないことにします。申し訳ありません。

 

 

簡単な解説

  • 1、Ryzen3700xの自作機。マザーはASUSmicro-ATXボードB450M-K。メモリはDDR4 2666MHz 16GBx2。3700xは定格で3200MHzのメモリまで対応しているが、安価な2667MHzのメモリと組み合わせている(*)。GuppyのGPU版やニューラルネットワークベースのツールを使うため、グラフィックボードはGTX1080 を選択。スモールゲノム解析用のため、メモリは32GBに留めた(ボードは最大128GBメモリまで認識)。CPUクーラーは純正を使用。
  • 2、マウスコンピュータが販売しているxeon E5 v4のワークステーション。CPUの開発コードネームはBroadwell-EP。この世代のxeon E5 2680v4を2つ搭載している。メモリは8GBのDDR4  2400MHz16枚でトータル128GB。システムディスクは1TB SATA3 SSDのストライピング(最近のQLCではなく書込み耐性の高いSSDを使用)。cinebenchR15のスコアは4000前後。電源は900W。GPUを無視すれば、今回の比較中では絶対性能が高く、そして最もバランスが取れた計算機
  • 3、Intel Xeon P-8136インテルOEM向けCPUだが、中国の知人経由で入手)をシングルで積んだワークステーション。CPUの開発コードネームはSkylake-SP。自分でパーツを選定し組み立てた。電源はgoldの1000W。メモリは64GBx8の512GBで、de novo assemblyなどのタスクで多く要求されるメモリは今回のマシンの中で圧倒的に多い。システムディスクはubuntuが512GBのSSD、windows10 proが1TB SSDでdual bootにしている。本機は大容量メモリを積んでいるにしてはシステムの容量が少ない(*2)。ボードは10Gb Ethernetポート搭載。インテルの新しめのサーバに切り替えるとどのくらい処理が早くなるのかの指標になる。(*3)
  • 4、mac mini2018のcore i7 CPUカスタム。インテルの8700Bが積まれていて6コア12スレッドで動作する。メモリは32GB。オプションの10Gb Ethernetポートに変更している。フットプリントは小さいが、背面端子の種類が豊富で、他の機器との接続がしやすい。現在主力機として使用(*4)。
  • 5、2世代前、つまり2009-2012世代のMac proで、本機は2012年モデル。以後、mac pro2012と記載する。デフォルトのCPUからX5690(3.44GHz)に換装し、メモリ容量は96GBまで増設、システムディスクをPCIスロットに繋ぎ3台でストライピングするなどの改良を施している。2009-2012世代のmac proではほぼ最速構成。しかし、10年前の設計であり、メモリ、バス(用語)などの足回りも含めてあらゆる点で現在の世代の計算機より見劣りする。ロートルな計算機と新しい計算機でどのくらい差がつくのかの参考になる。

 

 他にIvy Bridge-EPやHaswell-EPのxeonxeon platinum8180M dualなどの計算機が利用できたのですが、オーバーホール中だったり、他のジョブのラン中だっため今回のベンチマークには使えませんでした。また、私物でmac pro2009 2.22GHz x2、macbook pro2015、2017等がありましたが、今回のシロイヌナズナゲノムのデータ処理にはスペックが不十分と考えて使いませんでした。

 

ベンチマーク時のハードウエア設定と環境

部屋の温度20-25度。他のジョブは実行しない。再起動して10分後に測定開始。mac proのファンは最大回転速度に設定。自作機のファンはマザーの自動回転に設定。

 

使用したデータ

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5803254/のデータを使った。モデル植物シロイヌナズナのシーケンシングデータになる。 リード数はショートリードが16,841,951x2、ロングリードが300,071。トータル長はショートリードが84億bp、ロングリードが34億bp。変異解析やde novoアセンブリなどのタスクであれば、十分なリード数が確保できていると言える。

ファイルサイズ

f:id:kazumaxneo:20200112221734p:plain

 

始めに、mac mini2018とxeon E5 2680v4 dualの2台だけを使って、unixのコマンドやツール実行時の使用スレッド数とランタイムの関係を調べた。pigzコマンドによる圧縮と、3つのツールの実行時間を調べた。

 

 1、pigzによるfastqの圧縮にかかる時間

 fastqの圧縮/解凍はHTS関連でも頻繁に行う作業になる。並列処理に対応したpigzを使って、fastqをgzippingする時のランタイムを調べた。

 下の図が結果。横軸が使用スレッド数、縦軸がランタイム(timeでrealを測定)。使用スレッドが1-4の少ない時は、xeon E5 2680 v4 dual(以後、xeon E5 dual)よりmac mini2018(以後、mac mini)の方が早くジョブが終わっているが、使用コア数が6コア以上に増えると逆転し、xeon E5  dualの方が早くジョブが終わった。xeon E5 2680 v4 dualはスレッド数増加に従いランタイムが短くなり、1スレッドと比較して40スレッドは27.0倍早くジョブが終わった。mac miniは、1スレッドと比べ12スレッド使用時は7.5倍早くジョブが終わった。mac miniの12スレッドとxeon E5dualの40スレッドを比較すると、xeon E5 dualはmac miniの4.2倍早くジョブが終わった。

 xeon E5 2680 v4 dual計算機の利用可能な物理コア数は28で、論理コア数は56になる。興味深いことに、32スレッドから40スレッドにスレッド数を増やしたときでも87%の時間までランタイムが短縮した。pigzはハイパースレッドを上手く使えるらしい。mac miniはあえて16スレッドまで増やした時のタイムも計測した。16スレッド使用時は12スレッド使用時より遅く、12スレッドと比較して106%のランタイムになった。

f:id:kazumaxneo:20200111102840p:plain

ここには載せていないが、unpigz での解凍は、どれだけ並列化してもランタイムはあまり変わらなかった(2コア以上で80-90%前後の時間に短縮)。

 

 

2、GNU parallelによる並列化

 GNU parallelやxargsを使うと簡単に"なんちゃって"並列化ができる。そこで、ONTのsquiggle plotデータをbasecallして得た大量のfastqファイルを入力とし、GNU parallelで並列しながらnanofiltのクオリティフィルタリングラン(使用スレッド-t=1)を実行した時のランタイムを計測した。

 下の図が結果。傾向はpigzによく似ていた。並列数が4以下だとmac mini2018の方がxeon E5 dualより早く全ジョブを終え、並列数が6以上に増えると逆転、xeon E5 dualの方が早く全ジョブが終わるようになった。mac miniの12スレッドとxeon E5 dualの40スレッドを比較すると、xeon E5 dualはmac miniの1.6倍早く全ジョブが終わった(pigzの4.2倍と比べると並列化効率は低かった)。GNU parallelによる並列化は、様子をみて、10以下、できれば4程度に留めておくのが無難と思われる。リミットが低いのは"なんちゃって"並列化=、真面目な並列化をしているのが原因と思われる。増やしすぎて他のジョブと I/Oリソースを奪い合えば、全部遅くなる(同じくらいのサイズのファイルを同じタイミングで同時に処理するので、ピーク負荷のタイミングが常にほぼ同時になる)。

f:id:kazumaxneo:20200111102842p:plain

 

3、SPAdesランの使用スレッド数

pigzやGNU parallelと同様の結果になった。SPAdesのように複数の段階からなる複雑なツールだと、内部で並列化できないプロセスが多くなる。そのためアムダール則(*5)の影響が強く出るのだろうと思われる。

f:id:kazumaxneo:20200111102844p:plain

 

4、mac mini 2018を使って、minimap2によるマッピング、samtoolsのcoordinate sort、minimap2のマッピングとパイプしたsamtoolsのcoordinate sort、の3つのコマンドランタイムを計測した。データは3つとも同じデータを使用した。n=1

f:id:kazumaxneo:20200112203441p:plain

(追記)samtools sortの並列化による恩恵は少ない(オレンジ)。samtools sortは2ー4スレッド使えば飽和量かもしれない。黒線のminimap2とsamtools のパイプ処理は8スレッド付近まで早くなる傾向が見られるが、minimap2がコア数に応じて早く処理しているのを合わせて考えると(黄緑線)、黒線がコア数に応じて高速化しているのは、minimap2のマッピングだけの高速化だけに由来すると思われる。

 

ここまでのまとめ

pigzのランは論理コア数上限近くまでランタイムが短縮したが、他のジョブは物理コア数を超えた付近でランタイムは縮まらなくなった。たくさんのCPUコアを利用できる環境やツールであっても、使用スレッド数は物理コア数+1かそれ以下にとどめておくのが無難そうである(物理コア+1)。




ここからは、1−5の計算機全てを使ってベンチマークを取っていく。以下のスクリプトを1−5の計算機それぞれ5ループ回し、ランタイム(real)とピークメモリをまとめた。

#!/bin/sh 
#benchmark20191230
ref='Arabidopsis_lyrata.v.1.0.dna.toplevel.fa.gz'
shortf='ERR2173372_1.fastq.gz'
shortr='ERR2173372_2.fastq.gz'
ont='ERR2173373.fastq.gz'
thread='12'

for i in 1 2 3 4 5
do
echo fastp${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v fastp -i $shortf -I $shortr -o clean_1.fq.gz -O clean_2.fq.gz -q 30 -w $thread) 2>> run_log

echo Nanoflint${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v gunzip -c $ont |NanoFilt -q 8 --headcrop 50 -l 500 | gzip > ont_trimmed.fq.gz) 2>> run_log

echo NanoPlot${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v NanoPlot --fastq ont_trimmed.fq.gz --loglength -t $thread) 2>> run_log

echo cat${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v cat clean_1.fq.gz clean_2.fq.gz > merged.fq.gz) 2>> run_log

echo lordec${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v lordec-correct -2 merged.fq.gz -k 19 -s 3 -T $thread -i ont_trimmed.fq.gz -o ont-corrected.fasta) 2>> run_log

echo flye_raw${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v flye --nano-raw ont_trimmed.fq.gz --out-dir flye_raw --genome-size 120M --threads $thread) 2>> run_log

echo flye_correct${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v flye --nano-corr ont-corrected.fasta --out-dir flye_correct --genome-size 120M --threads $thread) 2>> run_log

echo minimap2${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v minimap2 -t $thread -ax sr flye_correct/assembly.fasta clean_1.fq.gz clean_2.fq.gz > short.sam) 2>> run_log

echo samtools_sort${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v samtools sort -@ $thread -O BAM short.sam > short.bam) 2>> run_log

echo samtools_index${i} >> run_log
time(/usr/local/Cellar/gnu-time/1.9/bin/gtime -v samtools index -@ $thread short.bam) 2>> run_log

done



 

1、fastpによる前処理

mac mini2018とryzen7 3700x自作機が一番早くジョブが終わった。mac pro2012だとこれらの計算機の2倍近い時間がかかった。xeon platinumはCPU世代が新しいにしては遅かった(xeon platinumの遅さや大きなばらつきは計測を通して最後まで続いた)。

f:id:kazumaxneo:20200111092638p:plain

                                                                                     12 threads  (n=5) (shorter is better)

 

 2、nanofiltによるONTリードのクオリティフィルタリング

fastpと傾向は同じで、mac mini2018とryzen7 3700x自作機が一番早くジョブが終わった。fastpとnanofiltの結果からは、共通してxeon CPUの計算機が遅いという傾向があるように見える。

f:id:kazumaxneo:20200112223520p:plain

                                                                                                                      12 threads  (n=5)

 

3、nanoplotによるONTリードのクオリティ分析

ryzen7 3700xが最も早くジョブが終わった。mini2018はryzen7より時間がかかっている傾向があるが、ばらつきが大き過ぎて差があるのか不透明だった。mac pro2012はエラーになった。

f:id:kazumaxneo:20200112223636p:plain
                                                                                                                          1 thread  (n=5)

これまでのまとめ

1ー3の結果をまとめると、ryzen7はfastp、nanofilt、nanoplotのような軽い計算では十分高速と言える。次に、より計算集約的なツールを走らせた時の結果を見ていく。

 

 

4、lordecによるONTリードのエラーコレクション

lordecによるONTリードのエラーコレクションを、12スレッド指定で実行した。1−3までの傾向とは異なり、最も早く計算が終わったのはxeon E5 v4 dualだった。            

f:id:kazumaxneo:20200111092647p:plain

 

 次に、同じジョブをそれぞれの計算機のCPU論理コア数の上限か、40コアに指定して実行した。mac miniは12スレッドが上限になるため、上の図のデータをそのまま使用している。

 結果を見ると、ryzen7も12スレッドから16スレッドに増やすとランタイムは縮まったが、それ以上にxeon E5 v4 dualとmac pro2012のランタイム短縮が著しく、303min ≒ 5時間でランを終えた(12スレッド時は690min)。mac mini2018は16時間以上かかるため、結果が出るまで1日待たないといけない。一方、5時間で終わるならパラメータを変えて1日に2回は回せる。計算機の性能によって大きな差が出ていると言える。興味深いことに、mac pro2012はryzen7より100分以上早く計算が終えた。

f:id:kazumaxneo:20200112142727p:plain

                                                                        

 

 5、flyeによるONTリードのde novo assembly

 flyeによるONTリードのde novo assemblyを、12スレッド指定で実行した。lordecでエラー修正したリード(下図の上半分)と、エラー修正していないリード(下図の下半分)を使った。エラー修正すると計算量が減るため、ランタイムは大きく短縮される。

 結果を見ると、最も早く計算が終わったのはxeon E5 v4 dualだった。ryzen7の計算機は、raw ONTリードのアセンブリはメモリが足らず強制終了したが(同じメモリ容量のmac miniは正常にランした)、先にエラー修正したリードを使うと、r正常にランは終了した。

f:id:kazumaxneo:20200113145013p:plain

xeon platinumは信じられないほど遅い。

 

 5のジョブをそれぞれの計算機の論理コア数の上限か、40スレッドに指定して実行した。12スレッド時と同じく、エラー修正したリード(下図の上半分)と、lordecでエラー修正したリードを使っている(下図の下半分)。xeon E5 v4 dualの計算機が最もランタイムを縮めた。これはlordecのランでスレッドを増やした時と同様の傾向になる。"エラー修正したONTリードを使うと、120-Mbゲノムのde novo アセンブリがわずか1時間で終わる"、ということを強調しておく。100ドルゲノムならぬ、植物の1-h whole genome de novo assemblyと言える。

f:id:kazumaxneo:20200113144416p:plain

  

これまでのまとめ 

 ここまでの結果から、ryzen7は軽いジョブでは十分高速だが、エラーコレクションやde novoアセンブリのような計算集約的なジョブではワークステーションクラスの計算機に大きく劣ることがわかった。これは誰もが予想する結果ではあるが、実際にその傾向が出たのは検証した甲斐があったと思う。ryzen7は一般向けの性能と消費電力のバランスが取れたCPUだが、NGSの計算機として十分使えると言ってよい(de novo assemblyなどに使うのでなければ)。

 

 次に、flyeでde novoアセンブリしたコンティグにショートリードをマッピングし、bamファイルを出力するまでのランタイムを計測する。初期はおかしなデータが出たが、まとめる時に間違ってしまっていた。やり直した結果が以下になる。

6、minimap2によるマッピング

 minimap2を使い、flyeで作成したcontig配列にショートリードをマッピングした。スレッドはmac minimac pro、ryzen7がCPUの論理コア数の上限、xeonマシンは40コアに指定している。これまでと同じように、xeon E5 v4 dualの計算機が最もランタイムが短くなった。注目すべきはxeon platinumで、これまでのジョブではスレッドを増やしても遅かったに対し、今回は相応にランタイムが短くなった(*6)。

f:id:kazumaxneo:20200113182122p:plain

                                                                         

 

7、samtoolsによるsam => bam変換とsort(samtools sort -O BAM -@ <thread>)

 6のステップで得たsamファイルを入力として、samtoolsによるsam=>bam変換とcoordinate sortに要する時間を計測した。スレッド数は、各マシンともステップ6と同じにした。マッピングと似た傾向が見られるが、xeon platinumとxeon E5 dualのタイムは逆転し、samtools sortはxeon platinumの方が早く計算を終えた。

f:id:kazumaxneo:20200113171901p:plain


2に続く。


 


関連

 

*1

CPU内部のCCX間のインターコネクトであるinfinity fabric(マーケティング的な名称で信号は2種類)のクロックがメモリのクロック(メモリコントローラのクロック)と同期するため(Infinity Fabric Dividerオンで1:2、すなわち半分にもできる)、低クロックメモリと組み合わせた場合、ZEN CPUの性能は伸びにくくなる。

https://www.corsair.com/corsairmedia/sys_master/productcontent/Ryzen3000_MemoryOverclockingGuide.pdf 

 

*2

初期はもっと大容量だったが、色々あってこうなってしまった。

 

*3

蛇足だが、cinebench R20の全CPUスコアは7650前後。core i7の7700Kが2400くらいなので、2017年の一般向けハイエンドCPUと比較して3倍以上の性能がある事になるが、ZEN2世代CPUが出た現在ではけっして高いスコアではない(12コアの3900Xが7200前後、16コアの3950Xが9300前後。2月発売の3990X(64コア)はリークで25000オーバーという数値が出ている(リンク))

 

*4

GUIツールやofficeファイルの操作、小さな計算、このブログを書くことなどにこのmac miniを使っている。4Kモニタと組み合わせているが、レスポンスは良好。他のマシンにはSSH悪いポートを開けてアクセスしている。

 

*5

http://www.hpc.cmc.osaka-u.ac.jp/wp-content/uploads/2016/07/2016-09-02_ParallelComputingGuide-for-print.pdf

 

biocondaでコンパイルされたバイナリをそのまま使っているのでAVX512が利用できる(link)とは思っていなかったが、実はONになっているのか?と考えたが、AVX512が利用できるminimap2はminimap2のレポジトリのbranchバージョンである。AVX512は使えないと思われる。

  

timeについて

ピークメモリも測定する場合(mac)

/usr/local/Cellar/gnu-time/1.9/bin/gtime -v  

 

ubuntu

apt update && apt install time してから

/usr/bin/time -v

 

さらにランタイムも測定する

time (/usr/bin/time -v echo hello)

 

logも含めて保存する

time (/usr/bin/time -v echo hello) 2>>  time