フリーでソースコードが公開されているツールは多々あります。
『これがコンパイルできれば、Macで使えるのに・・・』そう思ったことはありませんか？
ここでは、MOPAC for PowerMacを例に、作者の種部さんからうかがった苦労嘆を掲載してあります。
これからチャレンジしようと思っているみなさん、参考になさってください。
MOPACコンパイル記 種部 哲朗
平成６年初頭、当時私は東北大学薬学部の合成化学系の研究室に修士課程の１年として在籍していた。
その時はおりしも実験結果の考察や合成ストラテジの考案に計算化学的手法を取り入れようという機運が高まっていた時期であり、私もMM、MC、そしてMO計算というものに初めて出会った時でもあった。
しかし、当時研究室にあった計算機といえば、それまではプレゼンテーション専用に使われていたMac SE/30、Mac IIcx、そしてすこし前に購入したばかりのQuadra840AVだけであった。
当然Quardaは先生が独占使用するため、学生が使えるマシンと言え ば、非力な68030マシンのみ。そんな状況だったから、学生は自分用のMacを自費で購入しなければなくなっていた。しかし、どうせ買うなら計算速度の速いマシンの方がいい。
そんな折り、MacはPowerPC搭載化の道を歩もうとしていた。PowerPCは、浮動小数演算において68KMPUの10倍もの性能を発揮するというから、４月発売のPowerMacには、多大な期待を寄せたものだった。
そうして発売後喜び勇んでPowerMac 6100/60を購入した私だったが、発売当初は主だった化学関連ソフトが何もなく、しばらくは寂しい思いをさせられた。
しかし、その冬にはSerena softからPPCネイティブのMOPAC Ver.7が発売になった。これはノーマルの6100/60でQuadra840AVの実に５倍もの計算速度を誇り、当時の私はこんなに速いものかと驚愕に近い感動を覚えたものだった。
Serena softはPC-MODELやGMMXといった低分子解析用のソフトを販売している会社であり、MOPACもここで扱っている。
周知の通り、MOPACはPDSなのだが、マニュアル代とコンパイル手数料ということで、300ドルの価格を付けている。このSerena softのMOPAC Ver.7 for PowerMacはそれまで扱っていたMOPAC Ver.6for 68KMacに比べて大幅に速くなっているのは結構なのだが、いろんな点で、逆に使いにくくなっていた。
列挙すると、
(1) デフォルトの最大計算時間が3600秒であった
(2) EFのMaxStepが100回に設定されており、キーワードCYCLES=が使えなかった
(あとから考えてみれば、この時キーワードにDEBUGを指定していなかったからかも知れない)
(3) EF使用時、リスタートファイルは作られているのに計算のリスタートが出来なかった
といった感じである。
このうち、最も我慢のならなかった制約はMaxStep100回というもので、これがある限り少々複雑な分子は皆計算不能になってしまう(今考えれば、DEBUGを付けていれば大丈夫だったのかも知れない)。
そこで、なんとかこれを打開する方法を検討することになるのだが、1.6Mバイトほどあるプログラムコードの中からこの設定値を見つけだすのは、大海原から金鉱を探すような大変な作業だ。
そこで、EF関連のメッセージが埋め込まれている部分をASCII文字列検索で探し当て、その付近で16進で0064hがある箇所をサーチした。そして見つけた約30箇所の0064hを一つひとつ違う値に変えていき、プログラムの動作の変化を調べた。
地道な作業であったが、私はその中からMaxStepの設定箇所を見つけ出し、その値を増やすことに成功したのだった。
この時ついでに、アイコンやバルーンヘルプなども付けた。実用上どうと言うことはないのだが、少しはMacらしくなるだろうと、趣味で付けてみたのだった。
このSerenaのMOPACを特に不満なく使っていた私だが、その計算速度のことをNiftyの掲示板に書き込んだところ、どうしてそんなに遅いのかというコメントが付いた。
ペンティアム機に比べて、かなり遅いというのだ。
私は特に気にしていなかったのだが、ある時Fフィルム(株)のUさんという方が「Serenaが用いたソースをSerenaがコンパイルに用いたAbsoft f77で最適化オプション-Oを付けてコンパイルし、従来の４倍の速度で動く実行モジュールを作ることに成功した」旨をメールで知らせてきた。
Serenaが売っていたモジュールは最適化オプションを付けずにコンパイルされていたため、著しく遅くなっているというのだ。
今までの速度で充分満足していた私だから、突然また４倍の速度になったなどと言われてもにわかには信じられない。私はUさんにお願いして、Uさんの作った実行モジュールを郵送していただいた。
なるほど、これは速い。今までの速度とは比較にならない。しかし、動作に不審な点がいくつかある。
まず、Hessian行列の計算をさせようとすると、無限ループに陥ると見え、計算が終わらなくなる。
それから、計算時間の計測が出来ない(これはUさんがsecond.fをダミー関数で置き換えたからであるが)。
私はこの際だからバグがなく、時間計測もできる完璧なモジュールを作ることをUさんに提案した。
私がソースを手直しし、Uさんがコンパイルするという格好での共同作業をしようと言うのだ。
かくして、この距離を隔てた共同作業は始まったのだが、しかし、なにせ効率が悪い。
お互い電子メールでのやりとりの上、双方がFORTRANをろくすっぽ知らないという状況だから、作業は遅々として進まない。
まずやることはsecond.fの自作だ。しかし、このようなコンパイラ依存の箇所はコンパイラ付属のサンプルプログラムでも見ない限り、分かりようがない。
Serenaの方で作ったルーチンを貰えるようSerenaに何度か交渉したものの、返事が一向に貰えない。
結局いろいろなサンプルプログラムを参考に試行錯誤し、何とかFUNCTION SECONDを作ることができたが、何度も諦めようと思うくらい時間がかかった。
さて、次はHessian行列の計算で無限ループに陥る現象の手直しだ。
opt-command-escでの強制終了が出来ることから、プログラムがハングアップしているわけではなさそうだ。また、コンパイル最適化オプション-Oを付けないと同一のソースでも無限ループにはならないから、-Oを付けることによって不具合が出ていることになる。
要するに、コンパイラのバグだ。聞けば、-OはDO LOOPの最適化オプションだという。それなら、問題のあるループをDOを使わないように置き換えてやれば事態は解決するかも知れない
。
で、怪しいところを一つ一つあたっていると、見事、問題のあるループを同定でき、当該箇所のソースをいじって、見かけ上無限ループの不具合を取り除くことに成功した。
しかし、その他の修正も含め、一応(その時点で)満足のいくモジュールを作るのに実に半年近い期間を要したのだった。
Absoft f77を用いたコンパイル作業が終わらんとしていたちょうどその時、米Motorola社からFORTRANコンパイラfor PowerMacが発売されたというニュースをNiftyで得た。
それには、各社のコンパイラとの性能比較が記載されており、Motorolaのそれは他社のものに比較して著しく高速な実行モジュールを作り出すことが示唆されていた。
ついでに言えば、Absoftのはとても遅いと酷評されていた。
価格面においてもAbsoftやLanguage Systemsのコンパイラが軒並み７万円以上の高価格を付ける中、Motorolaのそれは349ドルと、個人的にも購入しやすい設定になっていた。
「買うしかない」と私は即座にこれを購入、当コンパイラを用いた「最強MOPAC for PowerMac」(Ver.6、Ver.7)の作成に取り掛かったのであった。
ところが安価な製品はやはりそれ相応の構成でしかなく、MPWベースのMotorola FORTRAN SDKの使用感は自分にとって劣悪そのものであった。
過去にMPWを使用した経験があればこれほど不便を感じることはなかったのであろうが、マニュアル(しかもオンライン)がMPWの使用法に全く内容が割かれていないため、その操作法が徹頭徹尾分からないのだ。
MPWを知らないと、当然Macのコンソールの概念も、SIOWも分からない。
私は試しにこのコンパイラでキーボードから入力された２つの数を足し合わせて画面に表示するだけの簡単なプログラムを作ってみた。
しかし、それを実行してもアプリはすぐ終了してしまい(コンソールウィンドウは開かない)、代わりにと言ってはなんだが、stdin、stdout、stderrなどといった訳の分からないファイルが作られている。
何なんだ、これは。
ちょっと調べて分かったことには、機番５に入力される文字列をstdinに入れておくとプログラムはそれをきちんと理解して実行し、機番６への出力をstdoutに行うようだ。
しかし、こんなんじゃ、不便で仕方がない。
Motorolaに何とかしてくれと頼んだところ、SIOW関連のライブラリをリンクすればAppleのStandard I/Oアプリフレームを用いたモジュールが作れると教えてくれた。
しかし、そのような記述はマニュアル中には一切見られなかった。
さすがに、DR2.0のマニュアルではその旨明記されているが。
また、このコンパイラにはToolBoxルーチンを利用する方法が提供されていなかった(これはDR2.0になってからもそう)。
計算時間の計測にはFUNCTION GetTimeなどのTBルーチンの利用が不可欠だ。
そう重要なことではないのだが、自分としては出来ればMOPACには計算時間計測機能を持たせたい欲望があった。
まあそれはいいとして、早速MOPAC Ver.6をコンパイルしてみる。
取り敢えずFUNCTION SECOND(CPUタイム取得ルーチン)はダミー関数にしてある。
オブジェクトファイルの生成までで約25分という、非常に気の長いコンパイルだ。
続いて各種ライブラリとのリンク、アプリ形式への変換、リソースの付加を経て、実行ファイルができる。
makefileの作り方が分からないため、全てコマンドラインでの操作だ。
さて、とにかくモジュールができたので喜び勇んで実行してみると、爆弾。
「存在しないシステムトラップです」。
なんだそれは。
キーワード0SCFを付けて計算させると爆弾は出ないから、SCF計算のどこかでこけていることになる。
ソースプログラムには問題はない筈だから、コンパイラにバグがあるのだろう。
やれやれ、349ドルどぶに捨てたかなと思ったが、一応こういう事例もあるということで、報告がてらMotorolaにソースを送っておいた。
それから約一ヶ月、Motorolaから「コンパイラのバグが解消され、MOPACはFORTRAN SDK 2.0できちんとコンパイルできるようになった」との連絡が。
正直このような展開になるとは想像だにしなかったので、いささか驚いた。
しかし、これで最高速のMOPAC for PowerMacで作れる。
Motorolaのコンパイラは購入後一年間は無償バージョンアップのサービスがあるので、私はそのSDK 2.0の到着を鶴首して待った。
SDK 2.0は配送の手違いなどもあって、随分遅れて、しかも２つやって来たが、とにかく到着後すぐさまコンパイルの作業に取り掛かった。
しかし、2.0でのコンパイルし直しの結果は、爆弾。
またもや「存在しないシステムトラップです」だ。
期待していただけに、落胆もひとしおだった。
しかし、その旨をすぐMotorolaに問い合わせてみると、或るコンパイルオプションを付けることでそれは解消されるとのこと。
その指示に従って作ったモジュールは見事にbomb-free、ようやくmotorolaコンパイラでの「落ちない」MOPACを作ることに成功したのだった。
で、この実行モジュールだが、前述のAbsoft f77によるものの約1.4倍の計算速度を誇る。
やはり、優秀なCPUには優秀なコンパイラは不可欠なのだ。
余談になるが、Motorola FORTRANによるコンパイルは、多大な時間と共に、多量のメモリを必要とする。
MOPAC Ver.6をコンパイルする場合、重原子10、水素原子10、計20原子までのモジュールを作るのにシステムソフトの分を含め、約30メガのメモリを要する。
重原子20、水素原子20、計40原子までのMOPAC Ver.7をコンパイルするのには、実に55メガものメモリが必要になる。
そこでそれなりの大きさの分子を扱えるモジュールを作成する際には、休日に知人宅に出かけ、メモリをふんだんに積んだMacでコンパイルをさせてもらわなくてはならなかった。
どうにか計算のできるモジュールが出来たので、あとは使用性の向上を目指すこととした。
まずは構造最適化の経過のログをコンソールウィンドウ上にも表示するようにし、Ver.7では新機能をキーワードDEBUGなしでも使えるようにし、計算終了時にはBEEP音を鳴らすようにした。
他にも数々の改良を施し、まあそれなりの実行モジュールを作り上げた。
ところでこのmotorola FORTRAN、Macのツールボックスルーチンが利用できないため、通常のやり方ではBEEPを鳴らしたり時間計測をしたりすることはできない。
これについては、Cで書いた関数をリンクすることで解決の途を見出した。
少々、裏技っぽいやり方である。
その後、Ver.7でのCOSMO法の計算値がおかしいとの報告があり、調べたところ確かにめちゃめちゃな値になることが分かった。
コンパイラが悪いのかと以前のAbsoft f77のMOPACモジュールでもCOSMO法計算を試してみたが(実はそれまで使ったことがなく、気付かなかった)、こちらもおかしい。
どうもソースがおかしかったようで、オハイオの計算機センターから別途にVer.7のソースを仕入れて、全面的に作り直した。
これにより何とかまともな値を出すようにはなったが、テストファイルでの理想計算値と実際の本モジュールを用いるときの計算値がわずかながら異なっている。
ただ、これ以上の計算値に対する最適化の検討は控えている。
コンパイラやOS、CPUなど様々な要因で計算精度は異なり得るのだ。
精度を重要視したい方はVer.93などの市販品を使用されると良いだろう。