ＳＸ４の並列化 [Top]
- 目次
- 筆者の並列化の現状
- ＳＸ４とは
- 何故、並列化が必要か？
- ＶＰＰからＳＸ４への移植
ここでは日本電気のＳＸ４関連を中心とした、並列化及び、エンドユーザー
の立場からの並列化に関しての意見を述べていきたいと思います。但し、現時
点で他機種への移植は完全には成功しておりません（５／１５、１／２７、１
９９７）。まず最初はＶＰＰ以外の並列化の現状から話して行きたいと思いま
す。
取り敢えず、筆者の所有する第一原理分子動力学計算プログラムの並列化が
なされている環境は、現状では富士通（ＦＡＣＯＭ）のＶＰＰ３００、５００
上しかありません。ＶＰＰ７００は使用したことはありません（ＶＰＰ３００、
５００と互換性があると思われますが、フォートランコンパイラのオプション
の使い方などに若干の違いが〔主にコンパイラのバージョンの違いに起因しま
す〕あるかもしれません）。
ＶＰＰ以外の使用経験ですが、titan3000というマシンを少々いじったこと
があります。但し、このマシンの製造会社は既に潰れています。性能もＣＰＵ
数が４で、メモリーも全部で１２８ＭＢ程度で、一応自動並列コンパイラーも
備わっていました（何とベクトル化もできた）。筆者のプログラムではコンパ
イル時に、自動ベクトル化と自動並列化を同時に行なうと、どうしても正しい
計算結果を得られませんでした。これにアプローチしていたのは既に３、４年
（計算機の世界では大昔？）前で、その頃はまだ並列化にそう熱心ではなかっ
たので、titan3000用の並列化コードを作ることは全く考えていませんでした。
ベクトル化を行なわないで、スカラーの最適化を行なわずに自動並列化させ
た時のみ、正しい結果を与えました。但し、何の最適化処理も行なっていない
ので、計算そのものは大して速くなりません。１ＣＰＵ（最適化処理していな
い）のみでの計算との速度比較すると、４ＣＰＵで約１．５倍程度速くなった
だけでした。その後、製造会社は潰れ、マシンそのものも故障してしまい、現
在は全く使用していません。
一時期、防災研のクレイ(CRAY Y-MP）を共同研究で使わせてもっていました。
２ＣＰＵしか搭載していなかったので、並列化計算は意識的には行ないません
でしたが、クレイのマシンも自動ベクトル化、並列化コンパイラーが備わって
いました。
そして現在、原研と金材技研のスーパーコンピューター（含む並列計算機）
を共同研究等で利用しています。
特に、原研とは並列化コード開発をも踏まえた上での共同研究を行なってい
ます。原研（中目黒）にはＶＰＰ３００、ＳＸ４、ＣＲＡＹ Ｔ９４、ＳＲ２
２０１、ＩＢＭ ＳＰ２などがあり（どれも個々の計算機としての規模は大き
くない）、筆者は主にＶＰＰ３００を利用し、原研側では並列化されたＶＰＰ
コードを元に、他機種（まずはＳＸ４用）への移植を担当して貰っています。
ＳＸ４の並列化に関しては最近（５／１５現在）、若干の進展がありました。
詳細についてはいずれ報告できると思います。
これはＮＥＣの共有メモリー型ベクトル並列スーパーコンピュータです。共
有メモリー型（分散メモリー的な取り扱いも可）であることが、ＶＰＰ（分散
メモリー型）と異なります。共有メモリー型だからと思いますが、ＳＸ４では
自動並列化（先に述べたクレイのマシンも共有メモリー型です。）コンパイラー
が備わっています。筆者も自動並列化を行なってみましたが、原研ではこの自
動並列化で並列動作させることができるＣＰＵ数が２つまでなので、実際の並
列化性能についてのテストが行なえていません（２ＣＰＵで動かした方が、む
しろ１ＣＰＵの時より遅くなってしまう）。
金材技研には２０ＣＰＵを搭載したＳＸ４があり、筆者もそれを利用するこ
とができますが、諸々の事情で現在本格的な利用を行なっていません（第一の
理由としては、ＶＰＰの利用〔原研、物性研〕で手一杯ということが挙げられ
ます）。また、いままで得た感触では、自動並列化では性能を出すことは難し
く、実際には並列化を考慮したコードを自前で用意する必要があると思われま
す。ＳＸもＶＰＰと同じく、並列化指示行形式でのコードの並列化が可能です。
ＳＸ上でのスカラー用コードの並列化は、コンパイル時に自動並列化した中
間コードをソースコードとしてファイルに出力することが可能で、これを利用
すると効率的かもしれません。つまり、一応並列化のための指示行がついた形
でのコードを出発点として、それをチューンアップして行くという方法です。
ただし、筆者もまだ試していないので、どの程度実用に耐え得るかは定かでは
ありません。
ＳＸに関しては、まだ筆者も知識が大変不足しているので、並列化に関して
の話しはこのくらいにしたいと思います（いずれより詳しい話しをすることが
あると思いますので、御期待下さい）。
ここでは並列化について考えて行きたいと思います。
第一に並列化する理由として、高速化と大規模問題への対応の二つが挙げら
れます。この二つの理由は普通、互いに深く関わっていますが、全く独立して
いることもあります。
例えば、プログラムによってはメモリーは消費しないが、計算時間は大量に
消費するもの、逆に、計算時間は大したことはないが大量のメモリーを必要と
するものがあります。一方、バンド計算では普通、計算時間もメモリーも大量
に必要とします。一番最初のケースは並列計算機で各ＣＰＵに搭載すべきメモ
リーを少なくすることができます。これはコスト的な面から（最近メモリーは
どんどん安くなっていますが）非常に都合のよいものなのですが、バンド計算
プログラムでメモリーを消費しない場合というのは、余程小さな系以外はほぼ
有り得ないと言えます。
バンド計算は計算時間も大量に消費します。電子状態の部分の収束のみに話
しを限定しても、系が大きくなれば、大変な量の計算時間を消費します。更に、
それに動力学計算が加われば、計算時間は電子状態のみの場合の、数倍、数十
倍にもなってしまいます。基本的にバンド計算はＣＰＵ資源もメモリー資源も
どちらも沢山必要だと結論付けられます（どうしてかは筆者のＤ論等参照、と
言うより、実際バンド計算を実行してみるのが一番明解に分かる〔思い知る〕
と思います。）。
バンド計算（特に第一原理分子動力学計算）では、より大規模化と高精度化
の方向に向かいつつあります。大規模化はそのものずばり、より大きな系の計
算ができるようにすることで、従来、せいぜい１００原子程度の系を取り扱っ
ていたものを、今後は１０００原子あるいはそれ以上のものへ拡張して行くこ
とです。
一方、高精度化は、より精度の高い計算を目指すものであり、単純にエネル
ギーカットオフを上げたり、ｋ点数を増やしたりする（当然、これらの計算パ
ラメーターの変更によって、計算精度は向上していく）ことだけに留まらず、
ＬＤＡ（局所密度近似）を越える試みや、非断熱過程を取り扱うことや、動力
学計算での長時間シミュレーション（計算時間ではなく、動力学における経過
時間のこと）の実現などが挙げられます。いずれも、計算規模の大型化に通じ
大量の計算時間とメモリーを消費すると考えられます。
一方、計算機の側でも単一のＣＰＵの速度にそろそろ限界が来ようとしてい
ます。どんなに細分化しても原子より小さくすることは不可能（それ以前に、
量子効果が顕著になってまともに動かなくなります）で、情報の伝達速度も光
速以上にはできません。そして何よりもその前にコスト面で限界が早晩やて来
ると思われます。たった１つのＣＰＵの高速化のために莫大なコストを掛ける
くらいなら、個々の能力としては劣っていても、数で勝負すれば、明らかに並
列化の手段によって高速化を達成する方に軍配が上がります（本当？）。
現在（１２／１６、１９９７）、ＶＰＰ用に並列化されたコードのＳＸ４上
への移植作業を試みています。これは日本原研との共同研究でもあります。
今のところ原研（中目黒）にあるＳＸ４を主力として、ＳＸ４上で、バンド
計算プログラム（revpe_d.f）の並列化を行なっています。最初、ＳＸ４もＶ
ＰＰと同じ並列ベクトル型のマシンなので（分散メモリ、共有メモリの違いは
あるが）、比較的簡単に作業は進むかと思いましたが、実際はなかなかうまく
行きません。作業そのものは原研の共同研究者渡部氏の助けも借りて、半年以
上も前から始まっていますが、移行作業はあまり進んでいません。
現在（１２／１９、１９９７）、一進一退の作業を進めています。ＶＰＰ
（富士通の並列ベクトル型スパコン）の時は、講習会や、ＳＥさんとのやりと
りである程度ＶＰＰでの並列計算の原理や特徴を理解した上で並列化した（ま
た時間もかけた）のですが、ＳＸの場合、ＶＰＰの場合と勝手はさして変わら
ないだろうと鷹をくくっていました。しかし、そうは問屋が卸さないようです。
共同研究先（原研）の渡部さんのみが頼りです（新年以降、詳しいレポート公
開予定）。
（１／５、１９９８）まず最初は、原研の渡部さんにプログラムrevpe_d.f
の一部（主にサブルーチンMSD）
に関して並列化を行なってもらいました。その作業内容の概要は、
- PACVPP内の作業用COMMON配列変数を
COMMONからDIMENSIONへ切替える。
- メインルーチンにおいてＰＥの確保を行なう。
- 冗長で意味のない出力ルーチンをコメントアウト（注釈に）する。
- MSD
内で使用されている配列変数CWL（PACVPP
内で定義）をMSD内でのみ定義（DIMENSION文で）するように変更する。
- MSD
内の最初の部分は冗長に実行されるだけなので、*pdir serial ----- *pdir
endserial文で１ＣＰＵでのみ実行させる。
- MSD
内の最大のループ、DO 100 NNN=1,KV3（ｋ点に関してのループを*pdir pardo
並列化指示行で並列実行させる。
- 上記DOループ内のSTOP文をコメントアウト（注釈に）する。そうしない
と並列化用のコンパイルができません（エラーで実行用ファイルを作らない）。
- ＭＦＦＴサブルーチン（高速フーリエ変換部分）で、一部の変数に対し
てLOCAL COMMONによる定義に切替える（これに関しての詳細は後述）。
となります。
ＳＸ４でもＶＰＰと同じように並列化指示行を使って、並列実行させます。
ここで使用した並列化指示行は、*pdir reserve = 2 ----- *pdir release、
*pdir serial ----- *pdir endserial、*pdir pardoの３つです（-----は間に
何らかのルーチンが存在することを示しています）。
- （１）ＣＰＵの確保
-
*pdir reserve = 2
ルーチン部分
*pdir release
これは、このプログラムではメイン文中（の最初と最後）にあり、ＳＸで使
用するＣＰＵ数を確保する（この例では２ＣＰＵ）並列化指示行です。但し、
これは確保のみで、この指示行に挟まれた領域（ルーチン）全てが並列実行さ
れる訳ではないです。
- （２）１ＣＰＵのみでの実行
-
*pdir serial
ルーチン部分
*pdir endserial
これは、並列実行（または冗長実行）されている場合に、１ＣＰＵのみの逐
次実行を行なわせる指示行です。
- （３）並列実行
-
*pdir pardo
ルーチン部分（普通ＤＯループ）
これは、並列実行を行なわせる指示行です。従って、ＤＯループの直前に置
かれることが一番多いかと思われます。これに関しては、*pdir endpardoのよ
うな閉じるための指示行は存在しません。
サブルーチン内に*pdir pardo指示行があると、そのサブルーチンの全てが
並列実行対象になるようで、*pdir pardoで直接指示したＤＯループ以外の部
分も並列実行されてしまいます。但し、この並列実行は冗長実行と言われるも
ので（ＶＰＰでの冗長実行と同じと思ってよい）、各ＣＰＵで同じ計算が（冗
長に）行なわれます。従って、場合によっては*pdir serial ----- *pdir
endserialで、１ＣＰＵによる逐次実行を強制的に行なわせてやる必要があり
ます。
この段階で、実質的に並列化が行なわれたのは、サブルーチンMSDだけです
（と言っても、MSDはこのプログラムにおいて中心的な部分で、並列化すべき
筆頭のサブルーチンです）。この並列化されたプログラム（revpe_d.f）をＳ
Ｘ上でコンパイルする場合は、
f77sx -A dbl4 -multi -tasklocal micro revpe_d.f
です。これでコンパイルした実行ファイルは、ＳＸ上で並列に実行されます。
因みに並列ではなく、１ＣＰＵのみで実行させる場合は、
f77sx -A dbl4 revpe_d.f
です。-A dbl4は、精度拡張に関してのオプションで、-multi -tasklocal
microが並列化に関してのオプションです（詳細は、ＳＸ上でman f77sxで、説
明を参照して下さい。いろいろな細かな指定が可能です）。
（補足）-tasklocal microが、LOCAL COMMONを有効にさせるオプションです。
本プログラムは既に、富士通のＶＰＰ上で実行させるために並列化されていて、そのための並列化指示行
（他のマシンでは注釈として解釈される）がプログラム中に書き込まれていま
す（ＳＸ上では注釈として解釈されるはずで、影響はないはずです）。ここま
でで、ＶＰＰでの並列化とＳＸでの並列化の違いは、上の（並列化作業）リストから（ａ）配列の定義（データ分割）の仕方の違い。
（ｂ）ＳＸではSTOP文を注釈にして無効にする。（ｃ）LOCAL COMMONの存在
（ＳＸの独自仕様、このためこれは他のマシンでは動かない）、などが挙げら
れます。
まず、ＳＸは共有メモリー型のため、並列化のための配列の定義の仕方がＶ
ＰＰと異なります。ＶＰＰは分散メモリー型で、グローバル配列、分割ローカ
ル配列とういう概念が必要でしたが、ＳＸではそのような明示的な形での（特
殊）な配列定義方法は（LOCAL COMMONを除いて）ありません。
但し、ＳＸでもＶＰＰと同じようにグローバル的なものと、ローカル的なも
のの概念は存在します。それは共通領域（スタティック領域と言う、グローバ
ル的）とスタック領域（ローカル）です。
原研の渡部さんによると、スタティック領域に取られる変数は、
（１）common文、data文、save文に現われる変数
（２）実際の並列化指示行（*pdir pardoなど）で並列実行を指定したルーチ
ンの引数に現われる変数
です。これら以外の変数はスタック領域に確保されます。スタティック領域
に確保される変数は共有メモリ上に１つしかなく、各マイクロタスク（ＣＰＵ）
が自由に読み書きできます（ＶＰＰのグローバル配列に似ている。但し、ＶＰ
Ｐは分散メモリ上に確保されているため、特殊な定義が必要でした）。スタッ
ク領域に確保される変数はＣＰＵ（マイクロタスク）数分だけあり、各ＣＰＵ
で独立しています（場合によって異なる値を持つこともあります）。またこの
スタック領域に確保された変数は、ＣＰＵ間での相互参照はできません（他の
ＣＰＵからの読み書きができません）。
第一段階の最後に、LOCAL COMMONについて説明したいと思います。これは、
ＳＸのフォートランコンパイラ独自の拡張のため、他のマシン（システム）で
はコンパイル時にエラーとなってしまい実行用ファイルを作りません。これは、
並列化指示行が注釈として解釈されることと矛盾してしまいます。ただ、ＳＸ
上における並列化にとってどうしても必要なものと言えます。
前述の通りCOMMONで定義された（配列）変数はスタティックな領域に確保さ
れ、各ＣＰＵ（マイクロタスク）に共用的に使われます。ところが、場合によっ
ては並列計算において、共用的に使いたくない状況（但し、各サブルーチン毎
の局所的なものではなく、プログラム実行中にずっと存在している必要がある
場合。各サブルーチン毎で独立かつ局所的に必要ならLOCAL COMMONを使う必要
はない）があります。このためにLOCAL COMMONという拡張が必要となります。
LOCAL COMMONによって定義された（配列）変数はスタティック領域（スタック領域ではない）に並列実行されるＣＰＵ数分だ
け確保され、プログラム実行中（COMMONと同じように）、ずっと存在し続けま
すが、各ＣＰＵに対応した領域以外の変数の参照、書き込みはできなくなって
います。つまり、あるＣＰＵで定義されるLOCAL COMMON変数は、他のＣＰＵか
ら参照、書き込みできません。また当該ＣＰＵから他のＣＰＵの領域のLOCAL
COMMON変数への参照、書き込みもできません。
その意味で、サブルーチン内で並列実行が行なわれる場合では、並列計算用
の変数としてLOCAL COMMON変数はＣＰＵ間での相互参照、書き込みができない
ので使用できません。
LOCAL COMMONの存在は、並列化指示行が注釈として解釈され、非並列マシン
でもそのまま動作するという大きな利点を喪失してしまいます。但し、LOCAL
COMMONは、既存のCOMMONで定義されたもの（配列変数など）を再定義したもの
である可能性が高く、単純にLOCAL COMMONをCOMMONに書き換えるだけで、非並
列マシン（ワークステーション、ＰＣ等）で動かせる可能性は高いです（UNIX
上の場合、シェルプログラムで、自動で書き換え後コンパイルさせることが可
能）。
ここで、原研の渡部さんによって並列化されたサブルーチンMSD
を示したいと思います。基本的には従来のMSD
とほとんど変わっていません。ＳＸのための並列化部分はCADETBLUE色で示してあります。
*pdir reserve = 2 ----- *pdir release文はメインプログラム
部分の最初と最後にそれぞれ置かれています。これは、ここではＣＰＵ数
の確保のために使われているだけです。
（補足）プログラム内でＣＰＵ数を確保しないで、実
行時にＣＰＵ数を確保することが可能であることが判明しました（１０／１３、
１９９９、原研の渡部さんの情報、感謝）。但し、この場合にはコンパイル時
に以下のオプションを付けてコンパイルする必要があります。
-Wf"-fopp res=whole"
そして、２ＣＰＵを確保したい場合、実行前に環境変数、F_RSVTASKを２に
する必要があります。
F_RSVTASK=2; export F_RSVTASK
この定義の仕方は、シェルの種類によって異なると思われます。
因みに注釈cGENは、ここにＳＸ用の並列
化指示行があると知らせるためのもので、別になくても一向に構いません。
この第一段階でどのくらい並列化による高速化がなされたかについては、原
研の渡部さんがベンチマークを行なってくれました。それによると、
ケース１（比較的大規模な系）
（オリジナルのCPU TIME）587.1sec
↓
（２並列のELAPSE TIME） 411.5sec
ケース２（小規模な系）
（オリジナルのCPU TIME）969.9sec
↓
（２並列のELAPSE TIME） 683.0sec
という結果となりました。計算したマシンは原研（中目黒）にある、ＳＸ４
で、電子状態のみの計算を行ないました。大体、２並列で1.5倍弱の高速化が
なされています。今のところ２ＣＰＵより多い場合でのテストは行なっていま
せん。
大体これで第一段階としての並列化作業は終了し、次にMSD以外のサブルー
チンの並列化作業に取り掛かりたいと思います。
第一段階で、バンド計算プログラムrevpe_d.fにおいて最も主要なサブルー
チンMSD
のｋ点に関してのループに対して並列化を行ないました。次は、それ以外のサ
ブルーチンのｋ点に関してのループ部分の並列化です。
revpe_d.f内のサブルーチンで、ｋ点に関しての並列化が可能で、ＶＰＰに
おいて並列化されたものは、KBMAT、MSD、FERMI、
FORCE、
FOZFB、
CHAVER、
ENERGY、
STRNL
の各ルーチンです。これらの中で、現在ＳＸ用に並列化できたのは、MSDを除
くとCHAVER、ENERGY、FORCEとFORZFBです。
今（１／３０、１９９８）のところFERMI,KBMATは並列化を試みましたが、
失敗しています。STRNL（非局所ストレス計算部分）にはまだ手を付けていま
せん。
それでは、並列化に成功したサブルーチンを公開したいと思います（CHAVER、
ENERGY、
FORCE、
FORZFB）。
ここで出てくる新しい概念として、ＶＰＰでのグローバル和の方法が、ＳＸ
では異なることが挙げられます。グローバル和が必要なサブルーチンはCHAVER
とENERGYです。これら二つではバンドとｋ点に関しての和が必要な変数が存在
します（それぞれ電荷と全エネルギーが対応）。並列で計算する場合、各ＣＰ
Ｕ毎に計算した値を足さなければなりません。それを行なうためにＶＰＰでは
グローバルサム（和）がありました（ＶＰＰでの並列化、手続き分割参照）。これは、対象となるＤ
Ｏループの終りのEND SPREAD文で!XOCL END SPREAD SUM(TTT)とすることで、各ＣＰＵで計算されたTTTの
値が、まとめられます。
ＳＸで、このグローバルサムに相当することを行なわせる場合、ちょっと面
倒な作業が必要になります。まず、TTTという変数が和のための変数とし、こ
れが並列実行されるＤＯループ内で、足し込みを各ＣＰＵ毎に行ないます。各
ＣＰＵ毎で計算された和の値が格納された変数TTTを、そのＤＯループが終っ
たあとで排他的に足し挙げます。これを行なうのが*pdir critical -----
*pdir endcritical指示行です。以下に例を示します。
TTT = 0.0D0
cGEN
totsum = 0.0D0
cGEN
*pdir pardo
DO 2 I=1,KV3
DO 100 IBAN=NBD1,NBD2
TTT = TTT + OCCUU(IBAN,I)*
& EKK(IBAN,I)
100 CONTINUE
2 CONTINUE
!XOCL END SPREAD SUM(TTT)
cGEN
*pdir critical
totsum = totsum + TTT
*pdir endcritical
cGEN
*pdir serial
TTT = totsum
ETOTAL = ETOTAL + 2.D0*TTT/FFF
これは全エネルギーを求めるサブルーチンENERGY
の一部を抜き出したものです。新たに、ＣＰＵ間で排他的に和をとるための一
時的変数totsumを導入します。これで各Ｃ
ＰＵのTTTの値をtotsumに集め、これを再びTTTに（全ＣＰＵの和を）戻します。
CHAVER
でもやり方は同じです。変数がTTTという単純なものから、配列CHGB1になって
いるところが違います（CHGSUMという一時的な配列変数が定義されます。
CHGSUMはＳＸ用PACVPP
内の作業用COMMON変数として定義されています〔totsum〕も同じ）。
他の並列化作業としては、MSDの場合とあまり変わらず、並列化したいルー
プ（ここでは一番外側のｋ点に関するループ）の前に*pdir pardoを付け、冗
長で実行してはいけない部分を*pdir serial ----- *pdir endserialで１ＣＰ
Ｕのみの実行にしてしまうだけです。
（２／１７、１９９８）さて、この段階での並列化効果について調べてみま
しょう。上に挙げた、MSD,CHAVER,ENERGY,FORCE,FORZFBを並列化したコードを、
原研のＳＸ４上で、２ＣＰＵのみの並列化で実行した場合と、単独のＣＰＵで
実行した場合の実行時間を以下に示してみましょう。
まず、２ＣＰＵ並列の場合
****** Program Information ******
Real Time (sec) : 1036.253643
User Time (sec) : 1776.454182
Sys Time (sec) : 10.677822
Vector Time (sec) : 1348.065699
Inst. Count : 81378594204.
V. Inst. Count : 22236659419.
V. Element Count : 1930052915880.
FLOP Count : 701910670120.
MOPS : 1119.755787
MFLOPS : 395.118927
MOPS (concurrent) : 1936.175820
MFLOPS (concurrent) : 683.202285
VLEN : 86.795992
V. Op. Ratio (%) : 97.026841
Memory Size (MB) : 32.000000
Max Concurrent Proc. : 2.
Conc. Time(>= 1)(sec): 1027.383376
Conc. Time(>= 2)(sec): 750.466766
Event Busy Count : 0.
Event Wait (sec) : 0.000000
Lock Busy Count : 0.
Lock Wait (sec) : 0.000000
Barrier Busy Count : 0.
Barrier Wait (sec) : 0.000000
MIPS : 45.809565
MIPS (concurrent) : 79.209569
I-Cache (sec) : 23.080716
O-Cache (sec) : 140.064823
Bank (sec) : 231.893724
real 17:29.53
user 29:36.46
sys 11.00
次に、１ＣＰＵのみの場合
****** Program Information ******
Real Time (sec) : 1529.758616
User Time (sec) : 1455.313306
Sys Time (sec) : 15.084813
Vector Time (sec) : 1342.811137
Inst. Count : 74585935353.
V. Inst. Count : 22172194600.
V. Element Count : 1924921508757.
FLOP Count : 700244727682.
MOPS : 1358.700728
MFLOPS : 481.164245
VLEN : 86.816914
V. Op. Ratio (%) : 97.349274
Memory Size (MB) : 31.031250
MIPS : 51.250775
I-Cache (sec) : 28.519145
O-Cache (sec) : 27.772930
Bank (sec) : 231.203216
real 25:38.41
user 24:15.31
sys 15.65
実行時間としては、real時間、１ＣＰＵのみで２５分３９秒弱が、２ＣＰＵ
並列では、１７分３０秒弱となっています。但し、この程度の高速化は、以前
MSDのみ並列化した段階でのものとほとんど向上がみら
れていません（並列化による高速化において、計算時間が７０％に短縮されて
いたのが、６７、８％程度になっただけ）。
（６／１、１９９８）更に、自動並列化によって実行
させた場合について以下に示したいと思います（２ＣＰＵ並列）。
****** Program Information ******
Real Time (sec) : 1396.346163
User Time (sec) : 2762.584602
Sys Time (sec) : 11.614916
Vector Time (sec) : 1330.233884
Inst. Count : 98163463377.
V. Inst. Count : 22159055477.
V. Element Count : 1921338743232.
FLOP Count : 701429312535.
MOPS : 722.998003
MFLOPS : 253.903288
MOPS (concurrent) : 1432.644989
MFLOPS (concurrent) : 503.117949
VLEN : 86.706708
V. Op. Ratio (%) : 96.194725
Memory Size (MB) : 31.000000
Max Concurrent Proc. : 2.
Conc. Time(>= 1)(sec): 1394.164756
Conc. Time(>= 2)(sec): 1370.091759
Event Busy Count : 0.
Event Wait (sec) : 0.000000
Lock Busy Count : 0.
Lock Wait (sec) : 0.000000
Barrier Busy Count : 0.
Barrier Wait (sec) : 0.000000
MIPS : 35.533197
MIPS (concurrent) : 70.410232
I-Cache (sec) : 28.066820
O-Cache (sec) : 59.329245
Bank (sec) : 233.938944
real 23:47.86
user 46:02.59
sys 11.94
コンパイルのオプションは、
f77sx -fopp par -A dbl4 -multi -tasklocal micro revpe_d.f
です（原研の渡部さん情報感謝）。結果を
みれば分かるように、ほとんど並列化による効果は出ていません。手動（並列
化指示行挿入）並列では、約３０％計算時間が短縮されていますが、自動並列
では１０％弱しか短縮できていません。
原研のＳＸでは共有メモリーで並列実行可能なのは２ＣＰＵまでなので（全
部で６ＣＰＵあるが、メモリー共有な２ＣＰＵのノードが３つで６ＣＰＵ分と
なっている。そのためノード間を跨って並列化させるためには、指示行形式で
は駄目で、ＭＰＩ等に頼らなければならない。これは当然原研特有の問題で、
金材技研では２０ＣＰＵが全て共有メモリーであり、ジョブクラスとしては８
ＣＰＵまでの並列実行が可能である〔２０ＣＰＵまでの並列実行もやろうと思
えば可能のはず〕。）、それ以上での自動並列化による性能に関しての情報は、
今のところない。
やはり自動並列化コンパイラでは手動ほどの高速化は望めないことが判明し
ました。
（補足、１０／１９、１９９８）
上記並列化効果及びベクトル化に関するリストで、項目VLENの値（平均ベク
トル長）は２５６に近いほど良い値であることが判明しました。ただこの２５
６の値は、システムに依存するので他のバージョン、機種では異なる可能性が
あります。
また、リストの最後のBankの値は、バンクコンフリクトによって消費される
ＣＰＵ時間となっています。この値は、経過ＣＰＵ時間（Real Time項目）に
対して５％程度くらいまでが許容値で、１０％以上では明らかに問題があるこ
とが判明しました。但し、並列計算でのこのBankの値が、総ＣＰＵ数分なのか、
１ＣＰＵ分のみなのかは現在不明です。
筆者の計算では、明らかにバンクコンフリクトによる計算時間の無駄が生じ
ています。バンクコンフリクトは、メモリーが最大で１０２４（システムによっ
て値が異なる場合あるが、大抵２の累乗のはず）のバンクから成り、例えばＡ
（１０２４、１０２４）のような配列をメモリー上で扱う場合、特定のバンク
にアクセスが集中（競合）するため、計算時間にその分無駄が生じるというも
のです。バンクコンフリクトの回避手段としては、定義する配列の大きさを奇
数にするのが最も手っ取り早い方法です（特に２の累乗にならないようにする）。
例えば、Ａ（１０２４、１０２４）をＡ（１０２５、１０２４）とする（両
方１０２５にする必要はないが、Ａ（１０２４、１０２５）では効果がない
〔ちょっと自信がない、調査中〕）とバンクコンフリクトは起こりません。
（３／２０、１９９８）とうとうサブルーチンFERMIの並列化ができるよう
になりました。この作業は原研の渡部さんによるものです。
これが並列化されたFERMI
サブルーチンです。
並列化される前のルーチンFERMI
との違いはsave文で定義されたtotsum2配列変数の存在です。そしてこれはｋ
点（ブリュアンゾーンのｋ点数）に関しての配列になっています。ENERGY
で使っているtotsumは単なる変数です。最初、FERMIでも配列でないtotsumで
和を取ろうとしたのですが、どのようにしてもＳＸ上での並列化はうまくゆき
ませんでした。
そこで、原研の渡部さん並列化に関してのアドバイスを求めると共に、最終
的には並列化作業そのものもお願いした次第です。結局、totsum変数では駄目
で、totsumをtotsum2（totsumはCOMMON変数のため別名で定義）というｋ点に
関する配列変数とし、save文で宣言して、スタティック変数として共有メモリー
に一つしか領域をもたないものにすると、うまく目的のＤＯループが並列化可
能になることを付き止めてもらいました（渡部さんに感謝）。
totsum2をｋ点に関する配列変数にすることにより、並列化するのがｋ点に
関してのループなため、各々のＣＰＵによる変数の書き換えも矛盾なくできる
ようになり、totsum2のｋ点に関しての和（tot =
tot + totsum2(k)）を別ループで行なうようにさせたことが、このサ
ブルーチンでの並列化（成功）の重要な点と言えます。
FERMIに関して、現在（３／２４、１９９８）、原研の渡部さんから、問題
点ありとの指摘を受けて、再度テスト計算中です。
ただ、サブルーチンFERMIでのＣＰＵ消費時間は、計算全体から考えると、
極く小さなもので、正直に言えば並列化による利点はあまりありません。しか
し、並列化作業の中では最も困難なものの一つでありました。最終的には自力
での並列化に断念し、人に頼るところにまで至りました。
しかし、筆者としてはこの一連の作業は、ＳＸ上での並列化を理解する上で
大変参考になりました。
[先頭][総目次
][最初に戻る][ＶＰＰ並列化][Ｖ
ＰＰ並列化２][OpenMPによる並列化
][並列化情報]