2020 9/17、9/20 文章修正
3990x（64コア）のような多くのCPUコアが利用できるプロセッサを積んだ計算機を使いこなすには、高度に並列化された計算が欠かせない。しかし並列化は技術的に可能なケースと不可能なケースが存在する。並列化が捗りそうなHigh-Throughput Sequencing（HTS）関連の計算分野でも、CPUコア数増加に比例してほぼ線形の時間短縮が可能なタスクというものは少ない（*1）。しかしながら、１つのジョブでそれなりの計算時間を要するHTSの計算では、１つのジョブを走らせている間に別の処理を行うことも多い（*2）。そのため、利用可能なCPU数に余裕があることは悪いことではない（*3）。
CPUコア数増加に応じた計算の高速化が難しいとしても、CPUリソースをより簡単かつ効率的に使い切れる方法がある。それは計算の単純並列化である。計算を行いたいファイルがたくさんある際に、計算を並列に行うということである。技術的には面白みがない単純な並列化だが、単純な並列化であるが故、並列数を増すだけほぼリニアに計算時間は短くなる。特に、処理したいファイルが何百も存在する場合はこの単純並列化の効果は大きく、物理64コアある3990xのようなCPUを使っている場合、圧倒的なランタイム短縮が期待できる。
ここでは3390xの計算機を使って単純並列化の効果を簡単に調べてみる。原核生物のパンゲノム解析を想定し、prokkaを使ってバクテリアのゲノム配列128個にアノテーションをつけ、タンパク質配列情報を取得するまでの処理時間を調べる。この処理を選んだのは、個人的にこの処理を行うことが多く、また、Novaseqで１レーンシーケンスすれば（アセンブルとビニングにより）相当な量のドラフトゲノム情報が得られるようになっており、この処理の高速化が重要であることも背景にある。128ものゲノムもあると、計算の並列化に対応したprokkaであっても、全ファイルの逐次アノテーションには一晩近くかかる。このアノテーション付加処理を単純並列で実行し、どのくらい早くなるのかを調べる。まず手順を説明してから結果をまとめる。
方法
128バクテリアゲノム（平均ゲノムサイズはおよそ4Mbほど）のアノテーションを行う。並列化にはGNU parallelを使用した。GNU parallelを使い、prokkaを並列ランする。prokkaの使用スレッドを１とし、10個を単純並列してランするなら、以下のコマンドをテキスト保存し、時間を図りながら実行する（time ./code.sh）。
#!/bin/sh
#prooka annotation
ls *.fasta | parallel -j 10 'prokka {} --outdir prokka_{.} --addgenes --cpus 1 --quiet'
同じディレクトリに128ゲノムのfastaファイルを置いて実行。実行内容を記録する目的も兼ね、ファイルを叩いて実行している。実際に使う際はターミナルで直接叩いてしまって問題ない。
計測には以下の構成の計算機を使用した。
- OS: ubuntu18.04LTS
- CPU: Ryzen Threadripper 3990X 64コア (合計128スレッド)
- CPUクーラー ROG RYUJIN 360
- memory: DDR4 3000MHz 16GB x 8 （合計128 GB）
- GPU: GTX 1600
- motherboard: TRX40 Taichi
- system: drive: Crucial M2 SSD：1TB
ゲノムのfastaファイルはSATA3接続の内臓6TB HDDに置き、そのディスク上で読み書きを行なった。
結果
並列処理数を1から128まで変えて、128ゲノム全てのアノテーションがつくまでの時間を調べた結果が下の表になる。prokkaの使用スレッドは1、2、4の３つを検討した。
まず左端の列がprokkaの使用スレッドを1として単純並列の数を変えた時のランタイムになる。１スレッドで128のゲノムを順番に処理するには835分（13.9時間）かかったが、並列処理を取り入れると、並列処理数が増えるにしたがってトータルのランタイムは短くなっていき、128並列処理時では21.2分で全ての計算を終えた。単純並列化の時間短縮効果は圧倒的と言える。次に、使用スレッドと並列処理数のバランスについても調べるため、prokkaの使用スレッドを2または4に増やして単純並列のタイムを調べた。それが中央と右端の列となる。ランタイムが一番短かったのは、２、４スレッドいずれも64個並列処理した時で、それぞれ19.1分と19.3分だった。もう１つ注目すべき結果は、１スレッドで４並列した時の231.2分と比較して、4スレッドで1つずつ処理した時は264.3分と、１スレッドで４並列した時の方がよりトータルのランタイムは短かったことである。プログラム内部の並列化より単純並列化した時の方が短い傾向が出ている（*4）。
次に、CPUコアの多い3990xと他の計算機で単純並列化の効果を比較する。別のゲノム128個のアノテーションにかかる時間を、3990xの計算機とxeon E5 v4 dual（28C56T）の計算機で調べた。以下のコマンドを実行した。
#3990x
ls *.fasta | parallel -j 128 'prokka {} --outdir prokka_{.} --addgenes --cpus 1 --quiet'
#xeon E5 v4 2680 dual
ls *.fasta | parallel -j 64 'prokka {} --outdir prokka_{.} --addgenes --cpus 1 --quiet'
結果は3990xの計算機が20m.59.8s、xeon E5 v4 2680 dual の計算機が43m38.9sで、3990xの計算機の方が半分以下の時間で処理を終えた。
まとめ
単純並列化するだけでバクテリアゲノムのアノテーションにかかる時間を大きく短縮できることがわかった。コア数の多い3990xの計算機では特に効果が絶大で、４スレッドの逐次処理では４時間かかる計算を20分まで短縮できた。これはあくまでケーススタディだが、似た計算内容（粒度）の計算では同様の傾向が期待できると思われる。１つ気をつけたいのはメモリの使用量で(*8)、メモリ使用量の多いタスクを単純並列化すると、メモリ不足で最悪計算機が落ちてしまう危険性がある。特にTR3990xなどは256GBしか物理メモリを詰めないため、コアあたりのメモリ利用可能量は一般的なシングルノードの計算機の最大量より少ない。このこともあり、共有計算機で無闇矢鱈に単純並列化する事は勧められない（他のユーザが実行中の計算を阻害してしまうリスクも高い）。あくまで個人用のワークステーションクラス計算機で、様子を見ながら行うものだということを強調しておきます。
参考
*1
64コアのCPUを単一のジョブで使い切る処理も当然存在する。この半年間3990xを使ってきたが、大きなアプリの全ビルド（Boostのビルド）、IQtree、MAFFT、CONSENTなどのエラーコレクションツールのエラー修正、Nextflowを使って実装した一部のツール、そして特にDIamond blastxのラン等は3990XのCPUリソースをかなり効率的に使う。また、Trinityのように非常に効率的にコアを使用するが、計算時間は短くならないものもあった（理由は不明）。
*2
例えば、あるユーザーが16スレッド指定でスモールゲノムのDe novoアセンブリを行なっている間に（数時間かかる）、別のユーザーが同じ計算機でRNA seqの発現解析用にfastqの16スレッド指定マッピングを３つ並行して行う、という処理が急ぎで必要になったとする。物理16コアのryzen最上位3950xでは厳しいことが予想されるが、物理64コアでメモリ帯域も多いTR3990Xなら余裕を持って行うことができる。
*3
TRやEPYCはメモリのアクセス速度も速くなっており、日常的な複数タスクの処理を前提にCPUとその足回りを設計している節がある。
*4
単純にprokkaをループ処理しても、128ゲノム程度なら一晩待つだけでアノテーションファイルを得ることができる。しかし、アノテーションをつけるだけで研究が終わるわけではない。20分で終わるなら当日中にかなりの事ができるようになる。
prokkaのランを使用コア数を増やしてランしても、内部で高速化が起きるのはhmmsearchによる相同タンパク質の検索などの一部のステップだけであり、リニアに処理が速くなるわけではない。
*5
xeon E5 v4 2680は、2016年に発売されたインテルのxeon v4 CPUシリーズになる。上で使ったのは、このCPUを１つのボードに２つ積んだ計算機になる。２つ積んでいるので、対等なCPUの性能比較ではないが、2680v4の値段は１つ23万円程度であり、２つあたりの値段は3990xに近い。
*6
1桁表記は曖昧すぎるので、そろそろ単位のピコメートル表記への切り替えまたは別の指標が必要。面積になるので、6.6nmと7.4nmでは集積率に大きな差が出る。
*7
今後より半導体製造が微細化し、製造プロセスが1nm以下のプロセッサ（*6）や積層プロセッサのようなものが出てくれば、2030年ごろには、１ノードあたりで512-1024物理コア利用できるハイエンド環境も出てくるかもしれない（現在はintelではxeonの4-way、AMDではdual quad EPYCが市販品最大）。あるいは現在のwebサーバのように仮想化技術によって混雑度により利用可能コア数を自在に指定できるクラウドサービスがより一般的になることで、必要に応じてメニーコア環境が利用できる環境がより一般的になるかもしれない（*7,*9）。
*8
prokkaのランは、ゲノムサイズにもよるが４スレッドで最大１GB前後のメモリーを使用する。128並列だとピーク時に100GB以上使う可能性があることになるが、実際は128並列でもメモリ使用量は30GB程度にとどまっており、100GBになることはなかった。処理するゲノムが異なるため、メモリのピーク使用量のタイミングが同調しないためと思われる。
*9
仮に2030年ごろには512コア、1024スレッドのCPUが出て、このようなCPUを利用できるノードを10000米ドルで１つ設置、運用できるとする。そうなれば、1024スレッドのうちの10コアの使用量はかなり安いものになる。そうなるとやがてGoolge chromebook、またはそれ相当の環境が上から下まで浸透して、ターミナルはブラウザ上でネットワーク越しに使うのが当たり前になるかもしれない。その時は囲い込みが重要なので、（あくまで例だが）10コア、32GB、100GB、というスペックが無料で使える可能性がある。webサーバは仮想化されており、ユーザの希望に合わせてリソース利用可能数は簡単に切り替えできる。例えば10ドル/月のSubscriptionを契約すると、100コア、256GBメモリ、2TB作業スペース、という感じで簡単に切り替えできるようになる。そうなると、大半のユーザーにとってCPUコア数やメモリ容量を気にしてマシンを買う必要はなくなる。妄想もいいところですが。
引用
O. Tange (2011): GNU Parallel - The Command-Line Power Tool, ;login: The USENIX Magazine, February 2011:42-47.
