2電子積分計算ルーチンの性能評価

稲富 雄一, 小原 繁, 長嶋 雲兵


Return

1 はじめに

分子軌道(MO)法は、さまざまな化学現象を理論的に解明するための重要な手段である。Gaussian[1]やGAMESS[2]、あるいはMOPAC[3]などの様々なパッケージが開発されたことで、今では理論計算の専門家ではない化学、生物化学分野の研究者でもMO計算を手軽に行えるまでになっている。しかし、経験的パラメータを一切含んでいない非経験的分子軌道計算では、対象とする系の大きさの4乗に比例する計算量(O(N4))を持つ2電子積分の計算、およびその操作が計算時間の95%以上の割合を占めているため、計算時間の短縮や、より大規模系へMO法を適用するためには2電子積分を高速に計算する必要がある[4]。そのためには、2電子積分計算にための効率的なアルゴリズムの開発や、専用計算機の開発などが考えられる。これまでに積分の高速計算のために多くのアルゴリズムが提案されているが、Obaraらが提案した一連のアルゴリズム[5 - 7]は、積和の形を持つ簡単な漸化式で表されており、専用計算機への実装も容易である。
ところで、著者らが関わっている専用計算機開発のプロジェクトで2電子積分専用プロセッサ(ERICチップ)の開発を目指しているが、その設計を行う際には積分実行に必要なプロセッサ資源情報の収集、分析が必須である。そこで、今回Obaraら[5 - 7]、あるいはHead-Gordonら[8]が提案した2種類のアルゴリズムに基づいて作成したルーチンを、最近では科学技術計算にも広く用いられているPentium4TM[9]プロセッサを用いて実行し、プロセッサが持つperformance counterを利用した積分ルーチンの性能評価を行った。一般には、必要演算数が少ないアルゴリズムほど、より高速に積分計算を行える、と思われがちであるが、今回の結果からは、演算数だけでなく、計算途中で必要となるメモリアクセス数も、積分計算の性能に大きく影響を及ぼすことが分かった。

2 評価方法

使用したプログラムはKikuchiらによって開発された非経験的分子軌道計算プログラムABINIT[10]の2電子積分計算部分を、1) Vertical Recurrence Relation (VRR)[5]とHorizontal Recurrence Relation (HRR)[8]のhybridアルゴリズムを用いたルーチン(hybrid法)、2)Obaraらによる改良ルーチン(new Obara法)[6, 7]、の2つでそれぞれ置き換えたものを用いた。各ルーチンの性能評価は、命令数やキャッシュミスなどを、Linux Performance-Monitoring Counters Driver (Perfctr)[11]を組み合わせたPerformance Application Programming Interface (PAPI)[12]を用いて測定することで行った。実際の測定は、2電子積分を行うルーチンを呼び出す直前にカウンタをリセットし、計算終了直後にカウンタの値を取り出す、という手順で行った。それぞれのプログラムを5回実行したが、実行時間のばらつきは0.1%未満であった。ほかのプロセスの影響が最も小さいと考えられるため、実行時間が最も短かった場合における測定値を、測定結果として後ほど報告する。計算の対象分子はGlycine (C2H5NO2)で、用いた基底関数は6-31G*であり、基底関数の数は85である。プロセッサ、コンパイラなどの使用した計算機環境の詳細はTable 1に示した。

Table 1. Computational environment used in calculation
processorPentium4 (3.6GHz, EM64T, 1GB L2 cache)
OSFedora Core 3 (kernel 2.6.11 with Perfctr patches)
PAPI version3.0.8.1
Perfctr version2.6.13
C compilerIntel C++ compiler (version 8.0, option = "-O3 -static -xP) [13]
Fortran compilerIntel Fortran compiler (version 8.0, option = "-O3 -static -xP) [14]

3 結果と考察

PAPIを用いて測定したプロセッサイベントの数をTable 2に示す。new Obara法のカッコ内の値は、Hybrid法の対応する数値に対する比を表している。まず、浮動小数演算数(Floating- Point Operations)の値について考える。これは、倍精度実数に対する四則演算などの数に、整数(固定小数)から浮動小数への変換などの操作を加えた値であり、積分アルゴリズムの良し悪しを決める指標として一般に用いられる「演算数」に対応する。この値を見ると、hybrid法では1.7×107回であるのに対して、new Obara法では1.4×107回と、hybrid法に比べて2割ほど少ない演算回数で積分計算を実行できていることが分かり、演算数の点から見ると、new Obara法がhybrid法よりも性能が高いことが分かる。しかし、実際の計算時間と直接対応している値である必要クロックサイクル数(Total Cycles)は、hybrid法に比べるとnew Obara法は3割以上大きい。すなわち、new Obara法のほうがhybrid法に比べて演算数では2割ほど少ないにもかかわらず、計算時間は3割以上長い、という結果になっている。この原因は、new Obara法のメモリアクセスの多さにある。Table 2中の"Load/Store Instructions"は、メモリアクセス数に相当するが、これを見ると、new Obara法はhybrid法に比べて3.4倍のメモリアクセスを行っていることがわかる。メモリアクセス数の増加は、当然ながらキャッスミスの増加も招いており、レベル1データキャッシュミス(Level 1 Data Cache Miss)の値を比べると、new Obara法ではhybrid法の25倍近い頻度でキャッシュミスを起こしていることがわかる。キャッシュミスが起こると、レベル2キャッシュ、あるいはアクセス速度がプロセッサに比べて格段に遅いメインメモリにまでアクセスする必要が出てくる。データがレジスタにロードされるまではプロセッサの演算の実行が中断するため、キャッシュミスはプログラムの実効性能を大きく低下させる要因になる。また、メモリアクセスはアドレス計算を伴うことが多いため、メモリアクセス命令だけでなく、整数演算も増加し、総命令数の増加にもつながる。実際に、積分計算に実行に要したプロセッサの総命令数(Total Instructions、 浮動小数演算数、メモリアクセス数なども含む)の値を見ると、new Obara法はhybrid法の2倍もあることが分かる。

Table 2. Number of counter value for each processor event in calculating two-electron integrals a using hybrid b and new Obara c algorithms
Counter ContentHybridNew Obara(ratio d)
Floating-Point Operations17,477,08314,483,404(0.83)
Total Cycles181,076,389245,536,511(1.36)
Load/Store Instructions18,941,28164,709,252(3.42)
Level 1 Data Cache Miss34,909870,671(24.9)
Total Instructions58,087,253121,364,431(2.09)
a; Target molecule is Glycine using 6-31G* basis set (including 10 atoms and 85 basis functions)
b; Hybrid algorithm between the vertical recurrence relation (VRR) [5] and horizontal recurrence relation (HRR) [8]
c; See references [6, 7]
d; Ratios vs. corresponding data in hybrid algorithm

したがって、高速に2電子積分計算を行うためには、演算数を減少させるだけではなく、計算途中で保存しておくべき中間積分などのデータ量を減らす工夫も必要である。

4 まとめ

今回、分子軌道計算において計算量が最も多く、高速化が求められている2電子積分計算に対して、2種類の計算ルーチンを用いて、プロセッサ資源を指標とした性能評価を行った。その結果、積分の高速計算には、浮動小数演算数を減少させるだけでなく、積分計算の途中で出てくる保存すべき中間積分などの各種パラメータの数を減らし、メモリアクセス回数を減らすことが非常に重要であることが分かった。
先にも述べたとおり、積分アルゴリズムの性能を評価する際の指標の1つとして、よく演算数が用いられている。しかし、ユーザから見た場合は、「計算時間が短い」、すなわち積分に要するクロックサイクル数が少ない、ことだけが重要である。積分プログラムの性能は、アルゴリズムの良し悪しだけでなく、キャッシュの構成や大きさ、演算器構成などのプロセッサアーキテクチャや、プログラムのコーディング手法に大きく左右される。ただ、”memory wall”という言葉が使われるほど、現在では、プロセッサ速度とメモリアクセス速度との間に大きな隔たりが生じており、その差は、今後、さらに広がっていくものと思われる。したがって、積分アルゴリズム開発、ならびにプログラム作成を行う際には、メモリアクセス数の減少も念頭に置くべきであり、2電子積分専用プロセッサ(ERIC)開発の際にも、積分計算中に頻繁にアクセスする必要のある中間積分データが十分に収まるようなキャッシュ容量を考える、などの対策が必要である。

本研究の一部は、科学技術振興費の総合研究「科学技術計算専用ロジック組み込み型プラットフォーム・アーキテクチャに関する研究(EHPCプロジェクト)」の支援による。

参考文献

[ 1] M. J. Frisch, G. W. Trucks, H. B. Schlegel, G. E. Scuseria, M. A. Robb, J. R. Cheeseman, V. G. Zakrzewski, J. A. Montgomery, Jr., R. E. Stratmann, J. C. Burant, S. Dapprich, J. M. Millam, A. D. Daniels, K. N. Kudin, M. C. Strain, O. Farkas, J. Tomasi, V. Barone, M. Cossi, R. Cammi, B. Mennucci, C. Pomelli, C. Adamo, S. Clifford, J. Ochterski, G. A. Petersson, P. Y. Ayala, Q. Cui, K. Morokuma, D. K. Malick, A. D. Rabuck, K. Raghavachari, J. B. Foresman, J. Cioslowski, J. V. Ortiz, A. G. Baboul, B. B. Stefanov, G. Liu, A. Liashenko, P. Piskorz, I. Komaromi, R. Gomperts, R. L. Martin, D. J. Fox, T. Keith, M. A. Al-Laham, C. Y. Peng, A. Nanayakkara, C. Gonzalez, M. Challacombe, P. M. W. Gill, B. G. Johnson, W. Chen, M. W. Wong, J. L. Andres, M. Head-Gordon, E. S. Replogle and J. A. Pople, Gaussian 98, Gaussian, Inc., Pittsburgh PA (1998).
[ 2] M. W. Schmidt, K. K. Baldridge, J. A. Boatz, S. T. Elbert, M. S. Gordon, J. H. Jensen, S. Koseki, N. Matsunaga, K. A. Nguyen, S. J. Su, T. L. Windus, M. Dupuis, J. A. Montgomery, GAMESS, J. Comput. Chem., 14, 1347-1363 (1993).
[ 3] MOPAC2000 ver.1.0, Fujitsu Ltd, Tokyo, Japan (1999).
[ 4] 中野達也、高島一、長嶋雲兵, シミュレーション, 19(4), 271-281 (2000).
[ 5] S. Obara and A. Saika, J. Chem. Phys., 84, 3963 (1986).
[ 6] M. Honda, K. Sato and S. Obara, J. Chem. Phys., 94, 3790 (1991).
[ 7] H. Honda, T. Yamaki and S. Obara, J. Chem. Phys., 117, 1457 (2002).
[ 8] M. Head-Gordon and J. A. Pople, J. Chem. Phys., 89, 5777 (1988).
[ 9] Pentium 4, Trade mark of Intel Corporation
[10] O. Kikuchi, K. Morihashi, T. Nakano and Y. Inadomi, ABINIT, Ab initio program package, University of Tsukuba,(1999)
[11] The Linux performance monitoring counters kernel extension (Perfctr) (version 2.6.13), Mikael Pettersson
http://user.it.uu.se/~mikpe/linux/perfctr/
[12] PAPI, Performance Application Programming Interface (version 3.0.8.1)
http://icl.cs.utk.edu/papi/
[13] Intel C++ compiler 8.0 for Linux, Copyright ? 2001-2003 Intel Corporation
[14] Intel Fortran compiler 8.0 for Linux, Copyright ? 1998-2003 Intel Corporation


Return