次期MPACK: 新しい環境変数の導入した。環境変数で、実行時に精度指定を行えるようにした。
ちょっとこの話は曲がりくねっている。
OpenOffice.orgがFreeBSD上でフリーなツールのみを用いてビルドできるようになるまでの軌跡だが、話の流れは
というふうになっている。
LinuxよりFreeBSDの方が、フリーに関する実質的な利害が大きい(あくまで実質的だが)。なぜならば、Linux版のソフトでバイナリでしかリリースされないソフトについてはLinux ABI(Application Binary Interface;互換機能)を用いて動かす。それでも動かないソフトについて動かす必要があれば、Linuxに乗り換える必要がある可能性があるからだ。Linuxは広く認知されたからかもしれないが、バイナリ配布のみのソフトも多いし、カーネルも様々に進んできた。
FreeBSDではjavaのサポートが弱かった、といってもずいぶん前の話だが。一番ふるい話で私に関係がありそうなのは、FreeBSD 4でJava 1.4が動いたとかそういう話である。ここから苦悩(ずっと移植し続ける)と喜び(OpenOffice.orgが動く)がはじまるわけだ。もちろん私が移植に関わったわけではないが、openoffice.org1.1以降をビルドするにはJava 1.4が必要だったのだ。(語弊がある。OOo 2.0近くまで、1.3でもビルド可能のはずで、パッチを送ったらokだったはずだが、結局開発スピードには全然ついてゆけず、1.4でビルドせざるを得なかった。手伝ってもらったこともある。そして Issueも書いて#i42305#となったが、今度はFreeBSD側の問題でペンディングになって諦めた)
FreeBSDでの状況は、公式版が2006/4/5にJava1.5が出たことで「公式バイナリ」が出たためかなり好転したが、それまでの状況は良くなかった。
それを説明しよう。公式サポートがないと、ソースからコンパイルせねばならない。まあその手間はよいとしても、致命的な問題がある。
という状況であった。
Java 1.5の公式サポートがあったとしても所詮好転であった。なぜならば、バイナリパッケージのみの配布で
などの理由があるからだ。
したがって、Richard Stallmanをして、一般的にJava trapといわしめるほど、OpenOffice.orgには問題があったのだ。また、この点については、Richard Stallman自身からメールをもらったこともある。
ということで、フリーのJava実装には興味があった。もちろんOpenOffice.orgをやりながら、というのは不可能なので見守っているだけだった。またFreeBSDはリソースが少ない。Linuxコミュニティの皆さんの仕事を待たざるを得なかったのだ。
続く。
OpenOffice.orgがFreeBSD上でフリーなツールのみを用いてビルドできるようになるまでの軌跡だが、話の流れは
- FreeBSDでのJavaサポート、苦難と喜びの始まり。
- FreeBSDでのJavaの公式バイナリ配布で好転。
- FreeBSDでのGNUによるjavaでのコンパイル、ビルド、これが苦労の割に酬われず。
- FreeBSDでのopenjdk6でのビルドで救われた。
というふうになっている。
LinuxよりFreeBSDの方が、フリーに関する実質的な利害が大きい(あくまで実質的だが)。なぜならば、Linux版のソフトでバイナリでしかリリースされないソフトについてはLinux ABI(Application Binary Interface;互換機能)を用いて動かす。それでも動かないソフトについて動かす必要があれば、Linuxに乗り換える必要がある可能性があるからだ。Linuxは広く認知されたからかもしれないが、バイナリ配布のみのソフトも多いし、カーネルも様々に進んできた。
FreeBSDではjavaのサポートが弱かった、といってもずいぶん前の話だが。一番ふるい話で私に関係がありそうなのは、FreeBSD 4でJava 1.4が動いたとかそういう話である。ここから苦悩(ずっと移植し続ける)と喜び(OpenOffice.orgが動く)がはじまるわけだ。もちろん私が移植に関わったわけではないが、openoffice.org1.1以降をビルドするにはJava 1.4が必要だったのだ。(語弊がある。OOo 2.0近くまで、1.3でもビルド可能のはずで、パッチを送ったらokだったはずだが、結局開発スピードには全然ついてゆけず、1.4でビルドせざるを得なかった。手伝ってもらったこともある。そして Issueも書いて#i42305#となったが、今度はFreeBSD側の問題でペンディングになって諦めた)
FreeBSDでの状況は、公式版が2006/4/5にJava1.5が出たことで「公式バイナリ」が出たためかなり好転したが、それまでの状況は良くなかった。
それを説明しよう。公式サポートがないと、ソースからコンパイルせねばならない。まあその手間はよいとしても、致命的な問題がある。
- ソースの入手可能性、ライセンスの問題ソースはライセンス(比較的厳しい)をアクセプトする必要があった。再配布は当然できない。ソースも突然消されて文句は言えなかった。これは厳しかったのだ。
- ビルドの問題:JavaはJavaでかかれており、卵が先か、鶏が先かというbootstrapの問題を抱えている。つまり、ソースのみの状態でビルドできないのだ。従って、Linux版のjavaを使ってビルドせねばならなかった。
- めんどくさいのでどうしても利用者が減ったりする。まあLinux版のJavaやOpenoffice.orgをFreeBSDでそのまま使えば良いのだがこれも倒錯してる気がする。
という状況であった。
Java 1.5の公式サポートがあったとしても所詮好転であった。なぜならば、バイナリパッケージのみの配布で
- 比較的複雑な手法でダウンロードしなければならない。
- OSのバージョンアップとバイナリが必ずしも追従しない、また新しいまたは古いバージョンのOSを使えなくなるかもしれない。特に前者は開発者にとっては致命的である。
などの理由があるからだ。
したがって、Richard Stallmanをして、一般的にJava trapといわしめるほど、OpenOffice.orgには問題があったのだ。また、この点については、Richard Stallman自身からメールをもらったこともある。
ということで、フリーのJava実装には興味があった。もちろんOpenOffice.orgをやりながら、というのは不可能なので見守っているだけだった。またFreeBSDはリソースが少ない。Linuxコミュニティの皆さんの仕事を待たざるを得なかったのだ。
続く。
OpenOffice.orgの品質保証には、VCLTestToolというのを使うこともできる。なぜ興味を持っているかというと、自動的に品質保証できるからだ。Thosten Zihemも、色々述べている。
私はMacOSX版のマイルストーンビルドも行っているがも参照のこと。これをSUN HamburgのThorsten Bosbachさん採用していただいたことがある。実際、VCLTestTool2.4のページからも確認できる。
> Binaries are taken from Sun StarOffice builds, exept:
> MacOS X PPC: this is based on Nakata Maho's builds
これは、毎回マイルストーンビルドを行うという安定した仕事の上に、他の人が安心して乗っかれるという好例であろう。論文では引用されたというのがあたるかもしれない。とてもうれしいものであった。
私はMacOSX版のマイルストーンビルドも行っているがも参照のこと。これをSUN HamburgのThorsten Bosbachさん採用していただいたことがある。実際、VCLTestTool2.4のページからも確認できる。
> Binaries are taken from Sun StarOffice builds, exept:
> MacOS X PPC: this is based on Nakata Maho's builds
これは、毎回マイルストーンビルドを行うという安定した仕事の上に、他の人が安心して乗っかれるという好例であろう。論文では引用されたというのがあたるかもしれない。とてもうれしいものであった。
(4/23 19:35大幅加筆修正)
次世代スパコンは二種類の4倍長精度演算をサポート：IEEE754R及びdouble-double形式。
多倍長精度計算に興味を持っている人間としてはうれしい限りである。
藤澤さん経由で次世代スパコンのページを見た。横川さんのプレゼンのp.10が私にとって興味深い。
> プログラム言語，コンパイラ
> Fortran 2003，XPFortran，C，C++
> GNU C/C++拡張仕様
> 4倍長精度演算をサポート：IEEE754R及びdouble-double形式
double-doubleは富士通やIBMのコンパイラは昔からサポートしていたと聞いたことがある。しかし富士通のは、情報しらないのよね...
IEEE 754RはIEEE 754 2008が発効された現在、言葉としてあまり良くわからない。多分binary128のことなんだろうか。Sparc64は四倍精度サポートしているが、次世代スパコンはどうなんだろうか。昔、姫野先生には、四倍精度入れたかったけど入らなかったんだよねとか聞いたことがあるが...実際は入っていた。命令をみよう。SPARC64TM VIIIfx Extensionsにそれらしきことが書いてある。どうやらquad precisionの命令のいくつかはSIMDにはできないようである。p.61 (p.71)参照。FADD, FMUL, FSUB, FDIVなど加減乗除はそうなっていた。従ってIEEE 754rの四倍精度はかなり遅いだろうと予測される。かといって
double-doubleは速いのだろうか? あまりそうとは思えない。FMAを使うから
速いのかもしれない、ただ、後藤和茂さんは、クロックは押さえられるかもしれないが、キャッシュに対するインパクトが大きく使うのが難しいといってたきがする。
なぜ二つあるのかは理解には苦しむ。FORTRANでREAL*16として使うのだろうか。危険である。書き出したとき、double-doubleで書くか、IEEE 754rの四倍精度(?)で書くか、でまた、読み出しはどちらで行うかで、実装のパターンも含め予期せぬ結果が出てしまうと考えられる。
正当的なのは、double-doubleを止めることだろう。double-doubleはpoor man's solutionとしては有効だし、我がMPACKでもdouble-doubleは使っている。ただあまり有効な数値計算としてはお勧めしない。
たとえば、IEEE 754の規格策定に関わった、W. Kahan教授をしてgrubby (p.5; 汚い、ウジが湧いたの意)
> A Fused MAC also speeds up a grubby “Doubled-Double” approximation
> to Quadruple-Precision arithmetic by
> unevaluated sums of pairs of Doubles.
と言わしめたし、C99のlong doubleとしても使えない
。
Intel Pentium, Coreなどハードウェアでサポートのないものに関して、速い安いちょっとまずい、ということで使わざるを得ないなどと微妙、複雑な気分で実装している。
トップページに平尾先生。どっちも上司だった、であるが、中田はスパコンのことは素人並みにしか知らない。
数値演算は難しいね...
次世代スパコンは二種類の4倍長精度演算をサポート：IEEE754R及びdouble-double形式。
多倍長精度計算に興味を持っている人間としてはうれしい限りである。
藤澤さん経由で次世代スパコンのページを見た。横川さんのプレゼンのp.10が私にとって興味深い。
> プログラム言語，コンパイラ
> Fortran 2003，XPFortran，C，C++
> GNU C/C++拡張仕様
> 4倍長精度演算をサポート：IEEE754R及びdouble-double形式
double-doubleは富士通やIBMのコンパイラは昔からサポートしていたと聞いたことがある。しかし富士通のは、情報しらないのよね...
IEEE 754RはIEEE 754 2008が発効された現在、言葉としてあまり良くわからない。多分binary128のことなんだろうか。Sparc64は四倍精度サポートしているが、次世代スパコンはどうなんだろうか。昔、姫野先生には、四倍精度入れたかったけど入らなかったんだよねとか聞いたことがあるが...実際は入っていた。命令をみよう。SPARC64TM VIIIfx Extensionsにそれらしきことが書いてある。どうやらquad precisionの命令のいくつかはSIMDにはできないようである。p.61 (p.71)参照。FADD, FMUL, FSUB, FDIVなど加減乗除はそうなっていた。従ってIEEE 754rの四倍精度はかなり遅いだろうと予測される。かといって
double-doubleは速いのだろうか? あまりそうとは思えない。FMAを使うから
速いのかもしれない、ただ、後藤和茂さんは、クロックは押さえられるかもしれないが、キャッシュに対するインパクトが大きく使うのが難しいといってたきがする。
なぜ二つあるのかは理解には苦しむ。FORTRANでREAL*16として使うのだろうか。危険である。書き出したとき、double-doubleで書くか、IEEE 754rの四倍精度(?)で書くか、でまた、読み出しはどちらで行うかで、実装のパターンも含め予期せぬ結果が出てしまうと考えられる。
正当的なのは、double-doubleを止めることだろう。double-doubleはpoor man's solutionとしては有効だし、我がMPACKでもdouble-doubleは使っている。ただあまり有効な数値計算としてはお勧めしない。
たとえば、IEEE 754の規格策定に関わった、W. Kahan教授をしてgrubby (p.5; 汚い、ウジが湧いたの意)
> A Fused MAC also speeds up a grubby “Doubled-Double” approximation
> to Quadruple-Precision arithmetic by
> unevaluated sums of pairs of Doubles.
と言わしめたし、C99のlong doubleとしても使えない
。
Intel Pentium, Coreなどハードウェアでサポートのないものに関して、速い安いちょっとまずい、ということで使わざるを得ないなどと微妙、複雑な気分で実装している。
トップページに平尾先生。どっちも上司だった、であるが、中田はスパコンのことは素人並みにしか知らない。
数値演算は難しいね...
多倍長精度のクラスを二つ混ぜて使っている。両者を引き算したらdoubleになってしまった。明示的にキャストしたらなおったが、怖い。当然実装が悪いのだが気づかない可能性がある。