No.1 「Osaka2002_nanoのロードテスト」

CMP Technical Report No. 1
「Osaka2002 nano」
のロードテスト
白井光雲
大阪大学・産業科学研究所
２００２年５月７日
Department of Computational Nanomaterials Design
ISIR, Osaka University
1
「Osaka2002」
「Osaka2002 nano」（通称「Osaka2002」、コードネーム eroica）の基本部分が長
い苦しみの後ようやく完成した。これは以前の v.2 を Fortran90 により根本的に書
き換えたものである。つまり単に Fortran77 のプログラムコードを Fortran90 に翻
訳したものではなく、Fortran90 のプログラミング精神に則った根本的な書き直しで
ある。
まずどうして Fortran90 に書き直したのかについて述べたい。従来の Osaka2000
は、いろいろのプログラムの集合体である。それぞれは始めから統合化を意識して
開発されたわけではないので、プログラム開発上いろいろ非効率的な部分が多くあっ
た。たとえば結晶を作ったり、ポテンシャルをつくる部分は本体 pwm でもバンド計
算でも基本的には共通しているのだが、プログラム開発上独立してつくられたため、
後で何か変更をしようとすると、すべてのプログラムの相当する部分を書き直さね
ばならなかった。少しの修正は新たなバグ導入の機会を増やす。また、ある部分を
変更すると、他のルーチンへの影響はプログラムごとに違うこともあるので、その
テストに大変な労力が費やされる。こういうことは、以前のバージョンの開発途中
でも十分わかっていたことであるが、その時点でこのプログラムパッケージはすで
に膨大なコードを含んでおり、今さら根本から書き直すことなんて到底不可能なこ
とで、結局、場当たり的な対応で何とかやりくりしてきた。しかしこのような態度
では先の見通しがもう完全に無くなると筆者には感じられた。少しくらいの機能の
付加くらいなら何とかなるが、もっと大きな、例えば密度汎関数摂動理論、線形応
答関数などを導入しようと考えるならば従来法ではもう破綻することは見え見えで
ある。またこうした巨大プログラムを開発することはすでに個人の能力を超えるも
のになりつつある。そのようなとき、チームで開発することを念頭に置かないプロ
グラムは生き残れないとの危機感に襲われたのである。
Fortran90 のプログラミングスタイルに則ったプログラムコードの読み易さも動
機の一因であることは間違いない。というより「他人に対する読みやすさが」最大
の動機といえる。というのはこのパッケージは今後長く使用されること、および更
なる発展を想定している（すぐに捨てられることを想定したプログラムを書いてい
る人もいないと思うが）。その場合他の開発者が参加が想定されるが、「プログラム
コードがとても読みにくい」ということでは、プログラム開発参加に躊躇してしま
う。プログラムというものはどれだけうまく書かれても所詮記号の集まりであるか
ら誰にも読めるというものではないし、またそのようなことを私は意図してもいな
い。専門化がわかれば良いと割り切っている。しかしその専門家でさえもそれを解
読しようとする意欲を失ってしまうものでは問題だ。そのようなものは人類共通の
文化遺産の資格を失う。その点では、旧コードはとても人に説明できるしろもので
はなかった。特に TSPACE を利用する部分では、表現方法の違うものをドッキング
1
させるため、変換、逆変換の連続で筆者自身でさえ見直すと吐き気を催す。それと
開発設計段階から特に統合化を念頭にしたものではなかったので、トップダウン式
の開発手順が組まれていない。そのような設計思想では、いずれプログラムが巨大
化したとき行き詰まる。こうして「他人が読める」ものにしなければならないとい
う使命感（誰に対するだろう？）で立ち上がった。
Fortran90 といっても所詮単に表現方法が異なっただけだから、大局的にいえば計
算に対する基本的考え方が変わったわけではない。しかし実際にプログラムを書く
上では大局的な立場に立っていたのではいつまでもはじまらない。プログラムを正
しく動かすためには局所的立場に立ちささいなプログラム文法の違いとの格闘が不
可避である。そういう見方から行くと Fortran90 と f77 は大変な違いである。筆者自
身は Fortran90 に関して造詣が深いわけではない。むしろ初心者で、Fortran90 の簡
便な解説書を見ながらの開発であった。そのような本の２∼３冊をざっと目を通し
たが、それらには新しい Fortran の使い方については書かれているが、なぜそれを
使わなければならないのかが書かれていない。いろいろな書き方はできますという
ことは教えてくれるが、その違い、またどれが良い書き方なのかに対しては答えて
くれていない。そのなぜについて、新しい Fortran の推奨されるプログラミングス
タイルとともに答えてくれたのは Chapman の参考書 [1] である。同書で書かれてい
るプログラミングスタイルが今回のプログラムの至る所に反映されている。この本
の作者には心より感謝する。 erica プログラム開発に用いた環境をリストする。
platform
============
Mac
SGI
Origin2000
IBM
OS
================
OSX (10.1.3)
compiler
==================
Absoft ProFortran
version
=======
7.0
IRIX (6.4)
AIX (4)
MIPSpro Fortran
XL Fortran
7.2
6.1
プログラム開発は主に MacOSX 上の Absoft ProFortran v.7 で行ない、後のプラッ
トフォームはその動作確認に用いた。
2
プレーンな pwm のスピード比較
この Fortran90 による全面的書き直しにより、どれくらいプログラムが効率化し
たか興味あるところである。勿論、Fortran77 から Fortran90 への切り替え自体は特
2
に高速化を意味するものではない。和や内積を従来の DO ループで書こうが、新し
い Fortran の関数（SUM や Dot Product）で書こうがその下で働いている原理が同
じである以上、結果は同じはずである。しかしながら、Fortran90/95 はより並列化
を意識した設計となっているので、その移植によっては、自動的にベクトル処理や、
マルチプロセッサ構成の場合であれば自動的に並列処理をしてくれている可能性が
ある。1
それで早速ベンチマークテストを行った。プログラムの全面的見直しにより、各
サブルーチンやプログラムパーツは旧バージョンと一対一対応になく、どこの部分
の違いということは難しいが、主要な部分は対応がつく。
テスト時点（4/19/2002）でのプログラムは
VersionNo
= ’0.30’
VersionDate = ’17 Apr 2002’
である。
テストは Si8 結晶を用いて行っている。k 空間のカットオフ半径を 7.65 と入力し、
カットオフエネルギー Ecut = 21.9 [Ry]、平面波数 Npw = 1875 となっている。k 点
のサンプリング数は 4 点である。収束条件として
npath0wfn
=
5
for CG process
wftol =
1.000E-11
etol =
1.000E-12 (Ry)
rsmin =
1.0D-12 (Ry)
を用いている。
まず、計算結果を示すと、新しいコードでは
iter
====
1
2
3
4
5
6
7
8
9
10
11
12
13
Eel
(Ry/cell)
===============
4.9934364011
3.9344814364
3.9138308412
3.9124727787
3.9123410793
3.9123204015
3.9123171211
3.9123167724
3.9123166970
3.9123166895
3.9123166881
3.9123166879
3.9123166879
deE
(Ry/cell)
============
-2.7186E+01
-1.0590E+00
-2.0651E-02
-1.3581E-03
-1.3170E-04
-2.0678E-05
-3.2804E-06
-3.4870E-07
-7.5469E-08
-7.4323E-09
-1.4652E-09
-1.6066E-10
-1.9848E-11
Xsi
(Ry^2/cell)
============
4.1456E-02
6.8359E-04
4.9215E-05
6.5488E-06
6.4279E-07
1.5470E-07
1.2805E-08
2.9464E-09
3.7449E-10
5.9801E-11
1.8768E-11
1.1466E-11
9.7113E-12
nst/bk
aglmax
========
5/ 0
5/ 0
5/ 0
5/ 0
5/ 0
5/ 0
5/ 0
5/ 0
5/ 0
4/ 0
2/ 0
2/ 0
1/ 0
=============
0.587308168
0.285489512
0.026634702
0.006376082
0.002696727
0.000583087
0.000465584
0.000084400
0.000061882
0.000020794
0.000006225
0.000003989
0.000000000
1
もっともスーパーコンピュータのコンパイラーは DO ループで書かれていても、それが和や内
積を求めるものであれば、そうと判断し、ベクトル処理や並列処理をやってくれているようである。
その場合は上で述べた恩恵は無くなることになる。
3
TOTAL ENERGY
--ELECTRONIC ENERGY
Sum of eigenvalues
2.45321278E+00
-Hartree term
-4.35723205E+00
Exchange correlation
-1.91385432E+01
Sum of Vxce
2.49548792E+01
-----------------------------------------Electronic Energy
3.91231669E+00
Electrostatic Energy
-6.71871186E+01
Present Total Energy
-6.32748019E+01
(RY./CELL)
となる。
これは v.2 の結果
Main loop
1
4.764265798
-28.08481
2
3.927457804
-0.8368080
3
3.913603813
-0.1385399E-01
4
3.912442198
-0.1161616E-02
5
3.912339223
-0.1029749E-03
6
3.912319663
-0.1956001E-04
7
3.912317306
-0.2357111E-05
8
3.912316991
-0.3145932E-06
9
3.912316970
-0.2173183E-07
10
3.912316968
-0.1422165E-08
11
3.912316968
-0.7295142E-10
12
3.912316968
0.3552714E-14
Els converged at 12
resid=
0.3776295E-01
0.4596711E-03
0.4758119E-04
0.4800408E-05
0.6412149E-06
0.1252034E-06
0.1361338E-07
0.5418838E-08
0.4471460E-08
0.4379220E-08
0.4382300E-08
0.4382300E-08
4.382E-09
de=
5/ 0
0.64035862
5/ 0
0.26959252
5/ 0
0.03259722
5/ 0
0.00679186
5/ 0
0.00223707
5/ 0
0.00070895
5/ 0
0.00036367
5/ 0
0.00005999
4/ 0
0.00003057
3/ 0
0.00000527
1/ 0
0.00000000
1/ 0
0.00000000
3.553E-15
TOTAL ENERGY
-- comparison (RY./CELL)
One way:
Sum of eigenvalues
2.453183616
Hartree
4.357198422
Exchange correlation
-19.138529550
Sum of Vxce
24.954861323
-----------------------------------------Electronic Energy
3.912316968
Electrostatic Energy
-67.187118619
Present Total Energy
-63.274801651
と比べると、数値誤差の範囲内で一致している。初期波動関数として乱数を使って
いるため、途中のエネルギーには当然違いがある。それにもかかわらず最終的収束
値が一致することは素晴らしいことである。
次にベンチマークを行ってみた結果を表（1）に示す。以下の議論でバージョン番
号が Osaka2k のものや、OS のものなどが入り乱れるので、これ以降、Osaka2k の
旧バージョン v.2 を「old osaka」とし、新しい２００２を「eroica」と称することに
する。
Mac まずいきなり特殊な場合についてであるが、開発環境に用いている Mac に
ついて述べる。Mac に関しては少し複雑である。今回開発した環境はマルチタスク
の OSX のもとで、Absoft ProFortran v.7.0 を用いている。一方で旧バージョン old
osaka は OS9 で、同じソフトウェアの v.6 を用いている。ただし同じ old osaka でも、
4
表 1: ベンチマークテスト。Si8 の計算。FFT として他のライブラリーを用いて実行
したものは備考に書いてある。また Mac の old osaka の場合、OS9 か classic 環境か
の区別をした。
マシン名
CPU（クロック） CPU 時間 (s)
備考
（ホスト名）
(MHz)
old eroica
iMacG3
PPC/G3
8909
OS9
(333)
iMacG3
PPC/G3
11008
OS9
(450)
3778
IMSL OS9
PowerMacG4
PPC/G4
4437
5262
OS9
(400)
12030
classic
PowerMacG4
PPC/G4
2307
IMSL OS9
(400)
2913
IMSL classic
PowerMacG4
PPC/G4
3055
3051
OS9
(733)
1645
IMSL OS9
1708
IMSL classic
SGI Origin2000 MIPS R10000
3010
3654
(five)
(195)
1621
NETLIB
IBM,7043-260
Power3
2478
3484
(pablo)
(200)
SX-5/1288M8
(312.5)
183
もともとの OS9 上と OSX 環境下での（いわゆる Classic 環境）とでは多少の違いが
出る。というのは OSX はマルチタスク OS で一つのジョブしか走らせていなくとも
いろいろ付加的な作業がバックグラウンドで走っているからである。実際、コンパ
イル速度は（数値は出していないが、体感で）Classic 環境ではかなり遅く感じられ
た。400 MHz の PowerMac/G4 では全く同じ数値結果を出すにもかかわらず、その
実行速度比は OS9 と classic 上では３倍もの違いが出た！これは驚きで、どうしてそ
れほどの差が出たのわからない。IMSL ライブラリーを使った場合にはそれほどの差
は出ていない。733 MHz の G4 では IMSL を使おうが使うまいがそのような差は出
なかった。400 MHz マシンの場合、まだ G4 マシンとしては初期のころの製品なの
で何かチューニングが行き届いていないのかもしれない。その後 450 MHz の iMac
でもテストしたところによると、IMSL を使わない場合、速度が遅くなるだけでな
く、なぜか速度自身がかなりばらつくようである。333 MHz の iMac で IMSL を使
わない場合の計算時間が 8909 sec なのに対し、より早い 450 MHz のものではかえっ
5
て時間がかかっている。計算時は余計な負荷がかからないように、他のタスクは動
かしていないのだが、意図しないにもかかわらず何か余計なタスクが発生したのだ
ろうか？
次に Osaka2k の実行にあたり PowerMac/G4 のクロックの差がそのまま出るだろ
うか？クロックが 400 と 733MHz のものは 1.83 倍の開きがあるが、old osaka で比較
すると、実行速度費はたかだか 1.44 倍となっている。それが eroica だとほぼクロッ
ク比くらいの 1.72 倍となって出ている。もっとも結果がクロック比に比例すること
は OSX の最適化が行われたことを意味するのだろうか？それとも OS がクロック比
を補って高い性能を保持していることを意味するのか？そのあたりは筆者にはわか
らない。
また Mac では G3 と G4 プロセッサーではクロック以上にベクトル処理機能の付加
による差が出ると期待される。Apple の公式サイトによると G4 の Velocity Engine
の効用を盛んに宣伝している。また開発に使っている Absoft ProFortran の宣伝文
句もやはり Velocity Engine の効用を謳っている。2 それでは G3 マシンと G4 マシン
を比較してみる。iMac(333 MHz) と PowerMac/G4(400 MHz) ではクロック比では
1.2 倍の開きしかない。ところが実行速度は 2 倍の開きがある。このクロック比を上
回る差がすべて Velocity Engine によるものかはわからないが、ともかくトータルと
して G4 マシンのパフォーマンスは非常に良いことになる。
UNIX マシン次に Mac だけでなく表（1）に示されるさまざまなマシンでの比
較を見てみる。old osaka と eroica との比較でまず気付くのは、今回のバージョン
eroica になって一様に時間がかかっていることである（開発環境の MacG4/733 だ
けは例外である）。これは Fortran90 で実行速度が落ちたことを意味するのだろう
か？多分そうではなく、プログラムのアルゴリズム（特に収斂条件）が以前と全く同
じでないことによると思われる。というのは開発時に主要なプログラムコードの個
別部分の速度比較では Fortran90 と f77 に差はないことを確認しているからである。
MacG4/733 を開発に使っていたから、このマシンだけ計算効率が落ちなかったのか
もしれない。となると差は、SCF 計算の収束の判定条件の差であると思われる。以
前のバージョンでは、計算効率を上げるため、できるだけ同じ計算を繰り返さない
ようにさまざまな工夫を凝らしている。ある部分は経験的なものである。そのため
プログラムコードがやたら込み入ってしまい、他人が読もうとするととても読みに
くいものとなってしまった。
2
しかし Absoft のサイトをよくよく見ると、ベクトル処理しているのは整数演算と、単精度実数
計算だけとなっている。こんなものが役に立つのだろうか。その制限が単に Fortran の移植が間に合
わなかったからであれば、近い将来バージョンアップで倍精度まで含めたベクトル処理が実現される
と期待できる。もしそうではなくその制限が Velocity Engine のアーキテクチュア自身にあるもので
あればどうにもならない。どちらなのだろうか？
6
今回はそのような部分を排除したので、前回のような技巧を凝らした部分がない
代りに、その部分が貢献している計算効率が落ちたようである。詳細はこれから詰
めるようにしたい。プログラムがこのように巨大化すると、作者自身にもどこが効
いているのかは直ちにはわからない。
以上述べてきた速度比較はしょせん１割２割程度の差を問題にしているに過ぎず、
結果が正しいなら「そんな差なんてなんだ」と言うことはできるし、筆者自身その
考えは健全だと思う。実際問題として、早くなるにしろ遅くなるにしろ２割くらい
の差が、実際の研究上問題となることは少ないだろう。プログラム開発におけるご
たごたを考えると、筆者としてはここでやめたい気持ちであるが、一応パフォーマ
ンスの問題を次節以降でさらに探ってみたい。
3
収束の改善
前で見た、今回のバージョンでの速度の低下の原因を探る。これらはファイル*.out
の最後に記述されている timing summary に出力されている計算ユニットごとの計
算時間を比較することで解析できる。結局わかったことは、やはり個々のバンドに
関して波動関数が収束しているにもかかわらず、無駄な演算があったからであった
（具体的にはハミルトン演算子を波動関数にかける演算 H · C で、ここに一番計算時
間がかかる）。そのバンドに関して収束すればもう演算 H · C は必要ないのに、それ
を実行していた。その部分を直した。それにより eroica は old osaka と基本的には同
じアルゴリズムになったはずである。
「基本的に」と断ったのは、考え方としては同
じだが、判定条件の適用の順番とか微妙な違いはあるので、数値上の違いはあるか
らである。
この改良を行った上で、もう一度 old osaka との比較を行う。テスト時点（4/24/2002）
でのプログラムは
VersionNo
= ’0.31’
VersionDate = ’23 Apr 2002’
である。表には今度は収束するまでの繰り返し回数（iter）、H · C の全演算回数も
リストしてある。先程述べた収束に際する微妙な違いを示すためである。全計算時
間が早くなっているものも実は単に収束までの繰り返し回数が少なくなっている場
合もあるからである。
表ではさらに数値結果、電子系のエネルギー Eel の最終値に対しても比較してい
る。old osaka を MacG4/733 で動かしたとき得た値の 3.912317964 [Ry/cell] を基準
として、それとの差を求めた。勿論これが正しいという意味で基準としているので
7
はなく、単なる便宜上の基準である。デジタル計算機のばらつきの程度を示すもの
という意味くらいで了解して欲しい。
表 2: Si8 の計算を用いたベンチマークテスト。old osaka と eroica の違いを o と e そ
れぞれの行ごとに示してある。収束するまでの繰り返し回数（iter）、H · C の全演
算回数と計算時間（s）を示す。∆Eel は電子系のエネルギーの収束値のバラつきを
示す。マシン名
CPU
o/e
∆Eel
iter n of HC time
PowerMacG4 PPC/G4
400
+IMSL
PowerMacG4 PPC/G4
733
+IMSL
Origin2000
(SGI)
pablo
(IBM)
rita
(IBM)
SX-5
+ASL
MIPS R10000
195
PowerIII
200
PowerIII
350
128M8
312.5
o
e
o
e
o
e
o
e
o
e
o
e
o
e
o
e
o
e
0.0
−1.3 × 10−6
0.0
−5.3 × 10−7
−1.3 × 10−6
0.0
−5.3 × 10−7
1.1 × 10−5
−1.3 × 10−6
7.2 × 10−5
−1.3 × 10−6
7.2 × 10−5
−1.2 × 10−6
3.2 × 10−7
−1.2 × 10−6
−1.0 × 10−6
12
13
12
10
12
13
12
10
12
12
12
13
12
13
12
13
12
13
3545
3598
3545
3297
3545
3598
3545
3297
3559
3115
3452
3164
3452
3552
3547
3472
3472
4437
4572
2307
2131
3016
2587
1717
1462
2993
3121
2478
2908
1294
1492
166
157
87
95
この表からわかる通り、old osaka と eroica の計算速度はほとんど同じということ
がわかる。細かく見れば、G4/733 が若干早くなり、それ以外のマシンでは少し遅く
なっている。しかしながら、その程度の差は重要でなく、むしろ収束条件（wftol や
etol など）の与え方で違ってくる。収束までの繰り返しはだいたい 12 13 回くらい
だが、この収束条件により H · C の全演算回数がかえって繰り返し回数の少ないほ
うが大きくなっていたりする。
コンパイル時のオプションは実行速度を決めるのに大切な要因である。筆者は細
かなオプション指定は試みていなく、だいたいどのマシンでも一様処理してくれる
8
中で最大のオプション（例えば SGI では-O3 レベル）をつけている。SX-5 はそもそ
も古い f77 はサポートしていないので、old osaka も f90 で処理している。もちろん
並列化などしていないので、処理は 1 CPU だけによる。スーパーコンピューターで
はコンパイラーオプションがあまりにも多いので筆者はそのマシンの性能の限界を
極めているわけではない。とにかく SX5 に関しては、並列化以外にも効率的コンパ
イル方法をもっと詰める必要があると思う。
電子系のエネルギーの収束値のマシンによるバラつき ∆Eel は、10−5 [Ry/cell] 以
下であることを確認しておくことも必要である。
ところでスーパーコンピューターの世界では速度を測るのに浮動小数点演算の速度
GFLOPS を用いて評価されている。SX-5 の例でいえば、阪大のセンターにあるもの
は総合的にピーク性能 1,280 GFLOPS ということになっている。しかし単体の CUP
に限るとその性能は 10 GFLOPS で、それが 16 個集まった１ノードは 128 GFLOPS
の性能であるといわれる（カタログの表面的な数値を拾ってきているだけでちゃん
と理解しているわけではないが）。一方で、Mac に用いられている PowerPC/G4 は
500MHz のもので 3.7 GFLOPS、最新の Dual 1 GHz のもので 15 GFLOPS という数
値が公表されている。なんと単体の CPU ではもはやスーパーコンピュータとたかが
パソコンとでは差が無いということになる（まさか！
？）。筆者はスーパーコンピュー
タの素人であり、これらの数値が同じ土俵の上でのものとなっているのか知らない
（多分違うであろう。一度に扱えるデータサイズとか）。今回のテストの G4/733 の
eroica の結果と SX5 の old osaka との結果には 15 倍の開きがある。この開きがある
ことに少し心が落ち着くのであるが（スーパーコンピュータを使う立場になればだ
が）、
「何んだ、差はその程度か」ということもできる。もちろんスーパーコンピュー
タを使うメリットは単に早いというだけでなく、10 G を楽に越えるメモリー空間の
使用など他にもあるのであるが。しかしスピードという点になると、いよいよスー
パーコンピューターといえども、並列化しない限りそのメリットはだんだん薄れて
来ていることは事実だ。
3.1
使用メモリー
参考のため、今の Si8 を用いた計算例でどれくらいのメモリーを使うのかチェック
しよう。メモリーで一番食う部分は、実空間での波動関数の展開である。今の例で
は k 空間カットオフ半径が 7.65 であるので（つまり逆格子空間で半径方向に７点の
格子点を含む球を取る）、FFT ボックスは正負両方の方向でその２倍間での領域を
取り（NGDIM=7 × 2）、したがって実空間では基本格子を 28 分割（Na = 28）取っ
ている。したがって全空間では Na3 = 21, 952 の実空間点で波動関数が展開されるこ
9
とになる。倍精度を用いているので１つの値には 8 バイト、かつ波動関数は複素数
であるので、その２倍のメモリーが必要である。さらにそれをバンドの数 Nb だけ
用意するので、したがって全部で、2 × 8 × Nb × Na3 = 5.6 (MB) の容量を使うこと
になる。この他、やはりこの空間で展開している密度は k 点の数だけ取っているの
で、k 点の数が大きいときはこちらが支配的になる。
さて実際にコンピュータで動かしてどれくらいメモリーが消費するかを確かめた
いが、そこで問題となるのが使用メモリーを見るには何を見れば良いのかというこ
とだ。あるいは、使っているメモリーを調べる方法はいろいろあるがいったいそれは
あるいは何を見ているのかが問題だ。さらに困ったことに多くにシステムでは単位
が書かれていない、あるいは分かりにくい。システムの設計者にとってはそれは当
たり前のことかもしれないが、あれやこれやのシステムを使う我々一般的ユーザー
には非常に困る問題だ。
Mac では ps コマンドでは
UID
501
PID
528
PPID CPU PRI NI
310
0 28 0
VSZ
94328
RSS WCHAN
26448 -
STAT TT
R
std
TIME COMMAND
4:05.52 pwm
となっている。man によると常駐メモリーは 1,024 B 単位で表示されるとなってい
るので、26 MB ということになる。3 top コマンドだと
PID COMMAND
451 pwm
%CPU
80.4%
TIME
#TH #PRTS #MREGS RPRVT
4:32.16
1
16
79 24.9M
RSHRD
1.23M
RSIZE
25.8M
VSIZE
92.1M
のように詳細が表示されるが RSIZE が全常駐メモリーということになっているので
ps の結果とだいたい合っている（top との結果が少し違うのは違う時間に調べたか
らである）。
SGI/Origin2000 では top コマンドより
user
pid pgrp
koun 17159 17159
%cpu proc
99.65
0
pri
20
size
2571
rss
1702
time
19:38
command
pwm
このメモリー数値は man によるとページ単位と書いてある。しかし素人にはページ
単位といってもどれだけかわからない。SGI の膨大なマニュアルのどこかに（どこか
は忘れた）１ページは 32 ビットモードの時 4 KB、64 ビットモードの時 16 KB 相当
だそうである。Origin2000 は 64 ビットチップを使っているので常駐メモリー（rss）
は 1.7 (K) × 16 (K) = 27 (MB) ということになる。
IBM では ps コマンドより
F S UID
200001 A 1110
PID PPID
4760 12066
C PRI NI ADDR
SZ
73 96 20 f92f 24964
WCHAN
TTY TIME CMD
pts/0 10:13 pwm
3
この分野に不慣れな筆者も、あいまいさを防ぐため急いで単位を明確にしよう。このＢはビット
でなくバイトを表す。
10
このメモリー数値 SZ は man によるとコアイメージサイズで 1 KB 単位と書いてあ
る。コアイメージサイズとはどのようなものかわからないが、まぁメモリーサイズ
を示すものと考えて 24 (MB) ということになる。以上、Mac、SGI、IBM ともほぼ
同じ使用量となっている。
SX5 では qstatr コマンドより
==================================================
REQUEST ID
NAME
OWNER
QUEUE
PRI NICE MEMORY TIME STT JID
--------------- -------- -------- -------- ---- --- ------ ------ --- -----54889.sx54
nqpwm
g62045
P1
31
0 68788 17.452 RUN
149
という結果を得る。この単位は KB である。つまり全部で 68 (MB) ということにな
る。これは Mac、SGI、IBM とくらべて２∼３倍の大きさである。これが何を意味
するものは筆者は知らないが、スーパーコンピュータでは高速になる分、余計なメ
モリーを取っているようである。
3.2
FFT ルーチン
計算を速めようとするならば FFT ルーチンの選択が非常に重要である。なぜなら
全体の計算時間の 60 %以上はこの FFT ルーチンの実行に使われている。将来並列
化を企てるとき、この部分に働かせるようにしないとだめである。FFT ルーチンの
選択については「eroica のインストレーションマニュアル」を参照されたい。
MacG4/400 の場合に FFT ルーチンの効用を見てみよう。表（2）からわかるよう
に、新しい eroica を使った場合、自前の FFT ルーチンと IMSL ライブラリーを使っ
たときでは 2 倍強の速度差が出る。自前のものをつかったときは FFT ルーチンに
3691 (s)（全体の計算時間の 76 %相当）かかっている。それが IMSL を使うと 1092
(s)（51 %相当）までに逓減されている。FFT ルーチンの 3.4 倍の高速化は計算全体
の 2 倍程度の高速化として反映することがわかる。
4
結論と今後の展望
今回のロードテストで eroica のパフォーマンスは、旧バージョンのものと同等と
いうことが示された。それだけを聞くと、
「なんだ前と同じなのか。それではアップ
デートする意味がないではないか」という批判もできよう。しかし、今回のアップ
デートは計算速度の向上にあるのではない。計算速度に関するアルゴリズムは既に
旧バージョンで極限を達しているのである。繰り返すが今回のバージョンアップの
差し当たりの目的は、プログラミングデザイン、スタイルの見直しである。それは、
その数学的構造は別として形式的なコードとしては全面的な書き直しである。その
11
ような全面的書き直しが、速度の点で最適化された計算アルゴリズムを崩していな
いければ合格なのである。
プログラミングスタイルの観点からは、統一的視点を保持し、トップダウンの設
計思想でプログラムコードを全面的に書き直すことは成功している。結果のコード
は以前のものに比べて格段に読みやすくなった。
したがって今回のアップデートで、直接ユーザーの受ける恩恵は少ない。しかし、
やがて達成されるこのプログラムの更なる発展の基礎を築いたことで、長期的には
恩恵を受けることになるのである。またこのプログラムをもとに自分でプログラム
開発をしようとする野心的な人には、大変な負担軽減になっていると信じる。
これ以降の発展は、例えば並列化を導入する例でいえば、新しくプログラミング
スタイルを書き直したおかげで、並列化を導入する上でより書き換えやすくなった
と信じる。
参考文献
[1] S. J. Chapman, Fortran 90/95 for Scientists and Engineers, (McGraw-Hill,
1998, USA)
12

Download Report