中田真秀(なかたまほ)のブログ

1/4くらいのMBLASの品質保証プログラムを更新。まぁあと1-2ヶ月かかるというところか。
がんばります。
応援よろしくお願いします。

前エントリからの続き

そうこうしているうちに、GNUのフリーなJava実装のひとつ、gcj, gijなどが出てきて、それでOpenOffice.orgがコンパイルできるようになった、と聞いたので私もやってみたことがある。ここらへんは、二通りあるかなと思った。ひとつは、gcj, gijでダイレクトにビルド。もうひとつは、
java-gcj-compatという、Java互換環境としてまとまっていているのを使う方法。パッケージもRedHatやDebianにあるわけで、これのFreeBSD版などを構築するかな、と思った。OpenJDKはまだ移植が始まってなかったのでIcedTeaという選択肢はなかった。

しかし努力の割には、まったく酬われず、OpenOffice.org向けパッチも作ったがインテグレートされなかった。まぁこれには技術や努力の投入が足りないとか、あるのだが。とにかく残念なことに、無駄であった。

まず第一歩としてやってみたことだが...
gcc41-withgcjawtのportsの作成である。これでとりあえずgij, gcjなどで、java awt peerをもったものが作られる。

なんでこんなことするかというと、
gcc41以降は、javaのawtというものをgtkで実装していて、java awt peerと呼ばれているものがある。これでアプレットを出す(正確なことは知らない)ことをやっている。ただ、こうするとjava awt peerがgtkなどに依存するため、X11やGNOMEなどをインストールしてしまう。依存関係が無駄に大きくなるので標準のgcc41ユーザーは要らない。だからsecondary portsを作ってそっちで処理した、ということだ。gccのメンテナーはGeraldという紳士で(メールのやり取りしただけで素敵な人だとわかる。彼はSuSEで働いていると聞いたことがある。FBSDも好きなんだそうだ)さまざまなアドバイスを受けた。たった一つのファイル、ライブラリを作るためだけ非常に無駄なことをしている。これはFreeBSD portsのインフラ的限界である。Debianなんかは、ひとつのports(?)からいくつかのパッケージを派生させるという手法があるそうだが、FBSDではそれをしないという考え方だそうだ。

さらにgcc41とgcc41-withgcjawtは共存できない。したがって依存関係を作るのは危険だった。当時FreeBSDのベースのgcc3からgcc4にあがったとき、FORTRANは入らなかったから、gcc41をインストールする必要がある。そして、gcc41-withgcjawtとは衝突する。FORTRANなんて使わないという人はいるかもしれないが、BLAS, LAPACK経由で知らないうちに使っていることは多い。最終的には実際はCONFLICTを入れなかったので、混乱が局所的には生じてたかも知れない。少なくとも私のところではあった。コミッターとしてはマナーが悪かったと思っている。

では、gcc41-withgcjawtはawt peerだけインストールすればいいのではとおもうのだが、これもgcc41のバージョンと正確に一致させねばならないし、インストール先が微妙だった。そしてMakefileが異常に複雑になる...

ということで、シンプルにgcc41-withgcjawtができてしまったのだ。Makefileのコミットログ汚い。さらにgcc41のMakefileも汚くなってしまった。

といいつつ、gcc42-withgcjawtにまでつくっちゃったんだけどね...

続く

小島政和先生のところの加藤健太さんが私の書いたSDPA-GMPを使ってくださっていた。。部分行列に制約を持つSDPですか。正確な値をレファレンスとして出すにはSDPA-GMPが必要だね。ご利用ありがとうございます。そろそろ7.3.0ベースにしないとなぁ...

私は高精度版BLAS, LAPACKの開発を行っているので、高精度演算のハードウェアの存在にも興味を持っている。しかし四倍精度の規格が定められたのもごく最近、つまり2008年754-2008
IEEE Standard for Floating-Point Arithmeticであって、まだハードウェアで四倍精度を実現しているプロセッサはない。このことを調査中である。

IEEE 754Rなどとして呼ばれていた2008年正式版のドラフトにもあったようであるのでハードウェアサポートはあるのではと思っていたが。特に理研次世代スパコンには、CPUとしてはSparc64の拡張が採用されて、また、Sparc64には既にインストラクションレベルで、binary128をサポートしているのだが(リンク先のp.10を参照)、ハードウェア実装ではないようだ。

後藤さんからも既にご指摘いただいたが、

> 命令レベルでのサポートで、実際にはカーネルによるソフトウェアエミュ
> レーションではないかと思います。この処理は極端に性能が悪いので、
> double- doubleによる処理も用意したのではないでしょうか？

ということだった。一応クロスチェックしてみると...

他の調査でも今もbinary128のハードウェア実装をサポートしている
プロセッサはないようである。
Handbook of Floating-Point Arithmeticのp.105によると、

As we write this book, no processors have full hardware support for binary128 format(註:いわゆる四倍精度). Some instruction sets (SPARC, POWER) have instructions operating on binary128 data, but on, current hardware these instruction trap to software emulation.

ということであった。トラップしてとなるとそりゃ時間かかるからdouble-double入れてるのだろう...

IA-64 (Itanium)は、実はサポートさえしてない(1976年にW. Kahan教授がIntelのコンサルとして雇用されていたのを思うと、ショックである)。しかしIEEE 754 2008ではなくなってしまった、80bitの拡張倍精度はサポートするという倒錯ぶり...

やっぱり高価なのかなぁ。30年前って倍精度は高価で、みんなfloatを使っていたことを考えると、またあと10-20年したらむしろ四倍精度が普通になるのかもしれない。

行革刷新会議を高く評価する。

まだまだ稚拙な議論が多い気がするが、少しずつポイントを抑えてきた気もする(昨年のは本当にひどかった)。これやるの大変だよなぁ。どっちも...
一番重要なのは、公開のもとで、ちゃんと説明責任を果たすことである(政権も、官僚も)。問題は我々が議論を軽視してきたこと、成果をオープンにすることを拒んできたこと、であろう。象牙の塔にこもっているだけではダメで、公開して初めてなんぼなんだろう。

毎年やってどちらも議論の質を高めることが重要だと思う。
おつかれさまです。