Fortran プログラムの移植における問題点

English version is here.

前提条件

Shared Library 環境のセットアップ

DR2.1update4(+shared library support) 環境下で、 RPM パッケージ (gcc 版の C、C++、Objective C、FORTRAN の一そろい) を 用意しました。 従って、これを使うには DR2.1update4(+shared library support) をインストールする必要があります。
Update4 のインストールに関しては ここ に私の場合の記録があります。

コンパイラーのセットアップ

ひとたび DR2.1update4+shared library がインストールできたならば、 後は比較的簡単です。 まず、次の RPM をローカルディスク上の <どこか> に用意して下さい。
$ cd <どこか>
$ ls
gcc-2.7.2.fu.1-1C.ppc.rpm
gcc-c++-2.7.2.fu.1-1C.ppc.rpm
gcc-g77-2.7.2.fu.1-1C.ppc.rpm
gcc-objc-2.7.2.fu.1-1C.ppc.rpm

これらの RPM の作り方に興味のある方は、 ここ をご覧下さい。

これらの RPM のインストールは

$ su
# rpm -U <somewhre>/gcc*-2.7.2.fu.1-1C.ppc.rpm

で終わりです。
注意：インストールは Update4 についてきた gcc の三組み (C, C++, and Objective C) を上書きする形になります。 結果として、標準コンパイラー環境を壊す危険があります。 インストールは自己責任でお願いします。 事前に これ をお読み下さい。

G77 事始め

簡単なテスト

おめでとうございます。ここまでくればとりあえず g77 を試す環境が出来たはずです。 そもそも g77 が動くものか否かを確かめるために、簡単なものから始めましょう。
$ cat simple.f

	  real*4  a, b, c
	  a = 1.
	  b = 2.
	  c = a + b
	  print *, ' a, b, c = ', a, b, c
	  end
	

$ g77 simple.f -o simpletest
$ simpletest

何か問題があったら

もし、このテストがうまくいかなかったらさっそく問題に出くわしてしまったわけです。 エラーメッセージが

simpletest: error in loading shared libraries
libf2c.so: cannot open shared object file: No such file or directory

のようなものだったら、あわてずにまず /etc/ld.so.conf があるかどうか 確かめます。

$ cat /etc/ld.so.conf
/lib
/usr/lib
/usr/X11/lib
/usr/local/lib

なかったら、例えば次のようにして作ります。

$ su
# cat > /etc/ld.so.conf
/lib
/usr/lib
/usr/X11/lib
/usr/local/lib
/usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux
^D

ここで "^D" は CTRL+d の事です。 ひとたび /etc/ld.so.conf ができたら

# /sbin/ldconfig -v
......
libf2c.so => libf2c.so
......

として、システムに libf2c.so を認識させてあげればいいわけです。 本来は RPM に/usr/lib/libf2c.so へのシンボリックリンクを含めるべき だった（実は大阪大学の松村さんに指摘されるまで含めていたつもり だった）のですが、忘れました。すみません、今度のバージョンでは忘れずに 入れます（12/07/97: 2.7.2.fu.1-1C では入れました）。 libf2c.so を認識させることが出来たら、 ここでもう一度 simpletest を試して下さい。

残念ながらこれが失敗したら、あるいは、そもそも最初のエラーメッセージが全然別の ものだったならば、深刻な問題です。
この場合には、 とりあえず、もとの gcc 三組み (gcc-2.7.2.1-2J.ppc.rpm, gcc-c++-2.7.2.1-2J.ppc.rpm, gcc-objc-2.7.2.1-2J.ppc.rpm) を、DR2.1update4 の RPMS/ppc ディレクトリーから復旧します。 その上で、g77 を以下の手順で ソース(SRPM). から作りなおしてみて下さい。

$ su
# rpm --rebuild gcc-2.7.2.fu.1-1C.src.rpm

こんなことしなくて良いことを、願っております。また、これには 相当時間がかかります。

さて、この簡単なテストにパスした場合には、もっと複雑なプログラムに 挑戦できるわけです。 すると、私の場合そうであったように、色々問題もでてくると 思われます。

MkLinux での g77 の経験

Linux 用のソースがある場合

もし、誰かがあなたのひいきの FORTRAN プログラムをすでに Linux に移植している場合は、ラッキーです。 何故なら、そのソースは高い確率で g77 でコンパイル可能だからです。 しかしながら、ビットや、バイト、また I*4 に埋め込まれた I*2 を 扱う場合には特別の注意が必要です。 Intel のチップと PPC ではバイトオーダーが違うからです。 CERNLIB の場合でも、あちこちでこの問題がありました。 たとえ MkLinux にソフトを移植する際に必ず起こるいくつかの 比較的単純な問題を除き、g77 で素直にコンパイルできても バイトオーダーの問題があると移植は骨の折れるものになります。 ただし、難しいことではありません。ただバイトスワッピングを しているところや、I*2 と I*4 を equivalence しているような部分を 一つたりとも見逃さない忍耐と注意深さがいるだけです。

そうでない場合

あなたはパイオニアです。 この場合の移植における問題点には次のようなものがあるでしょう。

適切な FFLAGS の設定

コンパイルがうまく行かない場合、あるいは、コンパイルできても バイナリーが正しい結果を出さない場合には、 まずコンパイラーフラッグをいじってみることです。
• -fno-automatic: を指定すると、変数を static にアロケート します。これは、全てのルーチンに SAVE を付けるのと同値です。ディフォールトでは SAVE してくれないので、ローカル変数の 値が保持されていることを前提としていると 全くでたらめな答えになります。
• -fdollar-ok: を指定すると $ が特殊文字として解釈 されなくなり、FORTRAN のシンボル用の 文字として許されるようになります。 もちろん、ディフォールトでは $ は禁止です。 Unix 用でないプログラムにときどき見られます。
• -fno-backslash: も同様で、指定すると '\' がエスケープ シーケンスとして解釈されなくなります。 例えば、これを指定しないと、'A\nB' は、３文字となります（二番目は改行）。
• -fno-underscoring: を指定すると、g77 はサブルーチンや ファンクション名にアンダースコアーを 付けなくなります。 ディフォールトでは、 元々の名前にアンダースコアーがなければ アンダースコアーを一つ、あれば二つを 名前の最後に追加します。 これは、C の関数を FORTRAN にインターフェース する場合に便利なフラッグです。 例えば、foo_(bar) という FORTRAN 関数を C の foo(bar) から作る場合のように。
  サブルーチン名が foo_bar の場合、 ディフォールトでは foo_bar__ と言う名前に なる点に注意が必要です。foo_bar_ とは なりません。

G77 Fortran77 の実装の不十分な部分

• 仮引数の文字型変数とローカル文字変数を "//" でつなぐことは出来ません。
  --->いったん、仮引数の文字型変数をローカルなものにコピーしてからつなぐ。
• "Char(39) 等は許されないようです。
  -fno-backslash をはずして、Char(39) は '\'' に、 Char(34) は '\"' に、Char(92) は '\\' にというように逃げました。 もっといい手があるはずですが。
  --->info ページを見る必要があります。
• 　"IMPLICIT NONE" は "ENTRY" 文とは矛盾するようです。
  --->ENTRY 文がある場合には IMPLICIT NONE をはずしました。
• IF ( INTEGER ) 型の IF は許されません。
  --->IF ( INTEGER .NE. 0 ) と書き直しました。
• INTEGER = LOGICAL あるいはその逆の代入は許されません。
  --->この場合には、LOGICAL の代わりに BYTE を使いました。
• EXTERNAL な関数には型宣言が必要です。

UNIX 特有の組み込み関数 (U77)

７月３０日現在、これはもう大した問題ではなくなりました。 新しい libf2c には Dave Love <d.love@dl.ac.uk> 氏作成のフリーな libU77 が組み込まれたからです。これは、 ftp//ftp.dl.ac.uk/pub/fx/libu77/ がプライマリーサイトですが、とてもつながりにくいです。 日本では、ミラーサイト ftp://ftp.u-aizu.ac.jp/pub/lang/fortran/libU77/ がお勧めです。 この貴重な情報は Hiroshi Futami さんが (mklinux-jp 4802) の中で指摘されたものです。 libU77 に興味のある方は、オリジナルの README をご覧下さい。

ただし私の場合、この情報を入手した時にはポーティングをほぼ終了していました。 data_、time_、等々の組み込み関数は適当にでっち上げました。 例はここにあります。

最適化の誤作動

"-O" 等の最適化フラッグを立ててコンパイルした場合、 G77 は（他の有償のコンパイラーでも結構しばしばあることですが） 誤ったコードを生成する場合があります。 深い IF や DO のネスティングをしている場合です。 長時間ジョブを走らせる前に "-O" の有り無しで 結果が変わらないことを確認することをお勧めします。

最適化の誤作動その２（97/10/15）

"-O" 等の最適化フラッグを立ててコンパイルした場合、 必ず起こる G77-0.5.19 のバグを発見しました。 複素数の Statement Function を含むプログラムで最適化を行うと、 誤ったコードを生成します。次の例で再現できます。

complex x, y, a, b, add

add(a,b) = a + b

x = (1.,0.)

y = (0.,1.)

print *, 'x = ', x

print *, 'y = ', y

print *, 'add(x,y) = ', add(x,y)

print *, 'x + y = ', x + y

end

最適化をしないと "x+y" と "add(x,y)" は同じ結果を 与えますが、例えば "-O1" を付けると "add(x,y)" は 全くナンセンスな答えを与えます。 同様のコードは単精度及び倍精度実数に関する限り 問題を生じません。

複素数を扱うプログラムでは、Statement Function の 使用を避けた方がよいでしょう。どうしても使いたいときは 最適化をせずにコンパイルしなくてはいけません。

この問題は、g77-0.5.21 以降では解決済みです。 従って、特に DR3 標準の egcs-1.0 以降の場合には解決されています。

その他、また何か有ったら書き足します

G77 の性能について

サンプルプログラムの説明

tt_gen: e+ e- ---> t tbar

TT_GEN は、電子・陽電子消滅反応でのトップ・反トップ対生成
e+ e- ---> t tbar

の断面積を計算するプログラムで、 トップクォークのボトムクォークと他のフェルミオン対への 崩壊までを含めて計算します。

これは、スピンや終状態の選択、始状態の輻射、 ビームストラールング等を含む２１次元積分です。 散乱振幅は HELAS(HElicity Amplitude Subroutines) で、また、モンテカルロ積分は BASES/SPRING で行っております。

BASES の部分では、荷重サンプリング法で 断面積のモンテカルロ積分を行い、 SPRING の部分は、その結果に基づいて 重み１のイベントを発生させます。 モンテカルロ積分は２ステップで行われます。 グリッドの最適化のステップと 統計を稼ぐための accumulation ステップです。 グリッド最適化のステップでは、 アイテレーション毎に 積分空間の中のハイパーキューブと そのサブメッシュ（グリッド）の大きさが 積分誤差を最小にするように 調整されます。 accumulation ステップではグリッドは固定で ひたすら統計をため積分精度を上げます。

この例では、各アイテレーションは 積分空間内での 20000 サンプルからなり、 グリッドの最適化に５回、統計を稼ぐのに ５０回のアイテレーションをしています。

SPRING のステップでは、 JLCの 簡易測定器シミュレーターも含めており、 荷電粒子の飛跡検出や、カロリメータの信号生成 なども行っております。

tth_gen: e+ e- ---> t tbar h

TTH_GEN は TT_BEN と同じようなプログラムですが、 終状態に余分にヒッグス粒子が生成される場合を 扱っています。 このため、積分の次元数が増え、スピンや終状態の選択、 始状態の輻射、ビームストラールング等を含めて ２８次元積分となっています。

各アイテレーションはやはり 20000 サンプルからなり、 グリッド最適化に５回、統計稼ぎに １０回のアイテレーションをしています （TT_GEN と比べて積分精度が必要でなかったので こうなっています）。

tth_anl: e+ e- ---> t tbar h

この反応を選択するためのプログラムで、 SPRING で作られたモンテカルロデータを 解析します。終状態のジェットのクラスタリングや エネルギーの大きいレプトンの検出や 運動学のチェックを行います。

プログラムは、終状態に応じて、 ８ジェット（8J）終状態用と １レプトン＋６ジェット（L+6J）終状態用の ２つの別々のプログラムからなっています。

Results

おそらくみなさんの興味のおありなのは、 結果のテーブルだけでしょう。


	C100 (HP-UX)	8115/100 (MkLinux)
TTH_GEN:BASES	140.73 sec (2.94834 +/- 0.00927 fb)	850.05 sec (2.94811 +/- 0.00927 fb)
TTH_GEN:SPRING	402.19 sec (output data: 35MB)	813.35 sec (output data: 35MB)
TTH_ANL: 8J	218.53 sec	435.08 sec
TTH_ANL: L+6J	166.2 sec	306.2 sec
TT_GEN:BASES	410.27 sec (0.40153 +/- 0.00061 fb)	2485.85 sec (0.40153 +/- 0.00061 fb)
TT_GEN:SPRING	103.62 sec (output data: 5.6MB)	244.45 sec (output data: 5.6MB)

ここで、重心系のエネルギーは TTH(TT) に対して ７００（３４０）ＧｅＶで、トップクォークの質量は １７０ＧｅＶにしてあります。 SPRING のステップでは１０００（２００）イベント生成しました。 TT 生成は、しきい値補正の入った計算なので、しきい値でも 有限の断面積がある点に注意して下さい。

コメント

BASES のステップを除き、差は約２倍で、これはおそらく CPU の実力の差とコンシステントではないかと思います。 BASES のステップではこの差は６倍で、MkLinux の性能が 悪くなっています。これはおそらく、BASES では 大きなアレイにランダムにアクセスするので キャッシュの小さい 8115/100 では キャッシュミスが起きているのではないかと思います。 時間があったら、この点テストしてみたいと思います。

Back to Keisuke Fujii's MkLinux Page