5.3 Ubuntu と CentOS の性能差の原因調査
評価環境agileとsocialの性能差の原因はUbuntuとCentOSというOSの違いにあるということが分かっ た．UbuntuとCentOSの性能差の原因を調査するために以下の調査を行った．
5.3.1 sysctlを用いた調査
まず，sysctlを用いた調査を行った．sysctlはカーネルパラメータを実行時に修正するのに用いられ る．また，-aオプションをつけることで設定されているカーネルパラメータの一覧とその値を得ることが できる．UbuntuとCentOSで共に設定されているカーネルパラメータを比較することで性能差の原因を調 査した．sysctlによって得られたカーネルパラメータを一部抜粋しUbuntuとCentOSで比較したものが 表7である．
表7: UbuntuとCentOSのカーネルパラメータの比較 Ubuntu CentOS kernel.threads-max 32077 65534 kernel.shmmax 33554432 4294967295 kernel.shmmni 2097152 268435456
kernel.msgmax 8192 65536
これらは特にカーネルパラメータの値の差が大きいものである．特にkernel.shmaxは共有メモリの最 大値であるが，CentOSの値がかなり大きいことが分かる．単一ノードでの計算では共有メモリを介した並 列計算を行っているので，このようなメモリに関するカーネルパラメータはUbuntuとCentOSの性能差に 関係していると考えた．そこで，sysctlを用いてUbuntuのカーネルパラメータをCentOSの値に変更し，
再度評価を行いCentOSの結果と比較してみたが，変更する前と比べあまり大きな差は認められなかった．
kernel.shmmaxは共有メモリの最大サイズであるが，カーネルパラメータを4294967295bytes(4GB)に 変更したとしても，仮想マシンの設定でメモリを2GBしか取っていないので，共有メモリを4GB使用する ことはできない．そのためカーネルパラメータを変更してもあまり影響はなかったのだと考えられる．
5.3.2 straceとhtopを用いた調査
次に，straceとhtopを用いて，システムコールとプロセスの関係の面からの調査を行った．
straceはプログラムが使用するシステムコールおよび受け取るシグナルを監視するものである．strace を用いることで実行中にプログラムが使用するシステムコールの呼び出し回数やそれにかかる時間を得る ことができる．straceを用いて実行中に呼び出されるシステムコールからUbuntuとCentOSの性能差の 原因を調査した．
straceによる結果を見てみると呼び出されているシステムコールの中ではpollが最も時間を取って いた．ここでpollはファイルディスクリプタにおけるイベントを待つシステムコールである．
5.3 UbuntuとCentOSの性能差の原因調査
htopはインタラクティブなプロセスビューワであるが，使用中にtを押すことでプロセスの親子関係を 図35,36のようにツリー状に表示することができる．
図35: Ubuntuでのプロセスの関係
図36: CentOSでのプロセスの関係 図35,36はプロセッサ数4のときのhtopの結果を抜粋したものであるが，これらを見てみるとともに mpirunという親プロセスがあり，その親プロセスが子プロセスを作成することにより並列計算を行ってい ることが分かる．また，図36よりCentOSでは子プロセスがさらに子プロセスを2個ずつ持っていること が分かる．これはUbuntuでは確認できなかった．
straceは-fオプションをつけることで子プロセスが呼び出すシステムコールも得ることができる．そ こでstrace -fを用いて子プロセスが呼び出すシステムコールも含めて再度調べてみると，CentOSでは pollに加えselectも呼び出されていることが分かった．selectもpollと同様にファイルディスクリ プタにおけるイベントを待つシステムコールである．strace -fにより子プロセスのシステムコールも取 得したところselectが増えたことから，CentOSでの子プロセスの子プロセスではselectが使われて いるのではないかと考えた．そこで，CentOSの子プロセスの子プロセスをGDBを用いて調査したところ，
2つのうち1つはpollを呼び出した状態で，もう1つはselectを呼び出した状態で停止していた．ま た，プロセスの状態も監視してみるとsleepingとなっており，CPU使用率も0%であった．
システムコールの違いと図35,36のようなプロセスの関係の違いがUbuntuとCentOSの性能差に関わっ ている考えていたが，strace,htop,GDBを用いた調査の結果から現段階ではこの違いによる性能差はな いと考えている．
5.3.3 -log summaryオプションを用いた調査
PETScでは実行時に-log summaryオプションを適用することで，事前設定した関数の実行時間や呼び
出し回数を得ることができる．これを用いて実行時に呼び出される関数の実行時間を比較し，プログラム 中のどの関数がUbuntuとCentOSの性能差に関わっているのかを調査した．
図37はプロセッサ数4のときの遷移確率行列でKrylov-Schurを用いた際に，-log summaryオプショ ンによって得られたログを用い，呼び出された各関数の処理時間をUbuntuとCentOSで比較したものであ る．ここで，横軸は呼び出された関数名，縦軸はその処理時間(秒)である．なお，STSetUpやEPSDense
5.3 UbuntuとCentOSの性能差の原因調査
などグラフが表示されていない関数がいくつかあるが，これは処理時間が極めて短いためである．また，複 数の関数で同様な差が見られるのは関数間の包含関係によるものである．
0 50 100 150 200 250 300 350
STSetUp STApply EPSSetUp EPSSolve EPSDense IPOrthogonalize IPInnerProduct UpdateVectors VecMAXPBY MatMult MatAssemblyBegin MatAssemblyEnd VecScale VecCopy VecSet VecReduceArith VecReduceComm
Time(sec)
Ubuntu CentOS
図37:遷移確率行列でのKrylov-Schurの各関数における処理時間の比較
図37よりIPOrthogonalaizeやIPInnerProductなどといった関数はUbuntuの方が処理時間が短いことが分 かる．しかし，UpdateVectorsを見てみると，Ubuntuに比べCentOSの処理時間がかなり短く半分以下であ る．EPSSolveは全体として固有値計算にかかった時間であるが，これまでの調査から分かっている通り，
遷移確率行列でのKrylov-Schurの処理時間はCentOSの方が短い．Ubuntuの方が処理時間が短い関数がい くつかあるにもかかわらず，全体としてCentOSの方が処理時間が短いことから，UpdateVectorsがUbuntu
とCentOSの性能差の原因になっていることが分かる．
5.3.4 gprofを用いた調査
-log summaryオプションを用いた調査により，プログラム中のどの部分が性能差の原因となっているの か見当をつけることができた．この結果をふまえ，gprofを用いた関数に関するさらに詳細な調査を行う．
gprofはプロファイラの一種である．gprofを用いることでプログラム実行時に関数の呼び出し回数や それにかかる時間を得ることができる．gprofを用いた調査により，遷移確率行列でのKrylov-Schurでは dgemmとdgemvという関数が処理時間の多くを占めていた．
図38は全体の処理時間(折れ線グラフ)とdgemm+dgemvの処理時間(棒グラフ)をUbuntuとCentOS で比較したものである．ここで，横軸はプロセッサ数，縦軸は処理時間(秒)である．これより，dgemmと dgemvの処理時間を足したものが全体の処理時間の半分以上を占めていることが分かる．また，Ubuntuと
0 100 200 300 400 500 600 700 800 900
1 2 3 4 5 6
Time(sec)
Number of Processors
dgemm+dgemv (Ubuntu) dgemm+dgemv (CentOS) Ubuntu CentOS
図38:全体の処理時間とdgemm+dgemvの処理時間を比較
CentOSの処理時間の差は，dgemm+dgemvの処理時間の差とほぼ同じである．よって，UbuntuとCentOS
の性能差はdgemmとdgemvの性能差が関わっていることが分かる．
gprofを用いた調査により，dgemm+dgemvの処理時間の差がUbuntuとCentOSの性能差に関わってい ることが分かった．この差を解消することができれば，固有値計算のさらなる高速化を図ることができる．
6 行列・ベクトル計算の最適化
調査の結果，dgemmとdgemvが性能差の原因であることが分かった．dgemmは行列と行列の積を，dgemv は行列とベクトルの積を計算するBLASのサブルーチンである．
6.1 ATLAS, GotoBLAS とは
ATLASはテネシー大学のWhaleyらが開発したライブラリで，対象プロセッサのハードウェアリソース
に適したライブラリを自動生成する[8]．GotoBLASはテキサス大学の後藤らが開発しているBSDライセ ンスのオープンソースソフトウェアである．ATLAS, GotoBLASを用いることで，BLASのサブルーチンを 最適化することができる．