まあ、タイトルは煽りすぎたかもしれない。しかし、ウケ狙いとしか考えられないのだ。
AMD joins The Document Foundation Advisory Board to accelerate LibreOffice | The Document Foundation Blog
via [Phoronix] AMD To Exploit OpenCL Potential In LibreOffice
AMDが、LibreOfficeのドキュメント財団に、相談役として加わったという事が発表された。発表では、AMDの次世代HSAがどうたらこうたら。AMDの革新的なコンピューティングアーキテクチャーがなんちゃらかんちゃら、GPUによる並列性が云々、AMD APUユーザーはより大きな表をより高速に計算できる等々、営業がひねり出したような文句が並んでいる。
これがよくわからないのだ。LibreOfficeは主に、一般人でも使える文書レイアウトとか、表計算とか、プレゼンテーションなどのソフトウェアだ。それなのに発表では、GPGPUに言及し、また文字通り「より大きな表をより高速に計算できる」と書いてある。
LibreOfficeのような表計算ソフトウェアにGPGPUがどう役立つのだろうか。GPGPUが必要なほどの大規模な計算は、もっと数値計算に特化したソフトウェアとか、プログラミング言語などでやるべきではないのか。
追記：phoronix.comのコメントに、まさにこのことをキャプション付き画像で表現したものが貼られていた。
AMD To Exploit OpenCL Potential In LibreOffice - Page 3
「スプレッドシートが重すぎる・・・動かすのにOpenCLが必要だ」
スプレッドシートが重いという事は、その問題を解くためにはクソ間違ったツールを使ってるんだよ。
ましてや、移植性の高い方法でGPGPUを実装となると、OpenCLを使うことになるが、AMDのOpenCL実装は、公式の不自由バイナリブロブ、非公式の自由ドライバーともに悲惨だ。AMDはLibreOfficeのまえにやることがもっとあるのだ。
例えば、まともなOpenCL実装をするとか。
BlenderはGPGPUを使う理由のあるソフトウェアである。BlenderのGPGPUを使ったCyclesレンダラーは、AMDのGPUでは動かない。これはBlenderのせいではなく、AMDの不自由なドライバーのOpenCL実装が極めて貧弱なためである。AMDの不自由なドライバーのOpenCL実装は規格に対応していると宣伝しているが、AMDのコンパイラーは、ちょっとでも大きな、つまり現実的なコードをコンパイルをさせるだけで、メモリ不足のエラーをだしてクラッシュするそうだ。実行以前の問題である。
nVidiaの不自由なCUDAは、個人的にとても残念なことに、とても使いやすいそうで、残念なことに広く使われている。またnVidiaの不自由なドライバーのOpenCL実装も、AMDの不自由なドライバーよりまともだそうだ。
とはいえ、現状ではOpenCLはどうも実装が未熟だそうだ。結局、nVidiaのCUDAのようなnVidiaのGPUでしか動かない独自のプロプライエタリな実装が使われている。例えば、BlenderのCyclesレンダラーも、デフォルトの実装はCUDAだ。OpenCL実装もあり、nVidiaの不自由なドライバー環境ならば、一応は動くそうだ。ただ、OpenCLの実装はどこも未熟なので、結局CUDAのような独自スタックに囲い込まれる。哀しいことだ。
追記：それなりに対応はしているようだ。
What's wrong with this file? | AMD Developer Forums
AMDはLibreOfficeのような有名ソフトウェアに席だけおいて宣伝に勤しむより、もっと根本的なソフトウェア実装をまともにする必要がある。どんなにハードがよかろうと、ハードを操作するソフトウェアが動かなければ、単なるヘアドライヤーにすぎない。ヘアドライヤーならもっと高機能なものがいくらでもある。もっと熱発生の電力効率がよくて、奇妙な電源コードを必要としたりしない。
ただし、発表にOpenCLの文字は一度も出てきていない。あるいは、AMDの独自スタックでやるのかもしれない。
せっかくLibreOfficeについて書いたのに、AMDのウケ狙いのことしか書かないのは残念なので、LibreOffice 4.1について紹介している以下の記事から、特に興味深いものを、いくつか紹介する。
LibreOffice 4.1では、ビルドシステムが劇的に向上する。従来、LibreOfficeではdmakeを独自に改良したものを使っていた。dmakeとは、makeの実装の一つで、まあ大半のmakeと同じような機能をそなえているそうだ。
LibreOfficeは、GNU makeへの移行を進めてきたが、まだ移行が完全に済んでいないので、gnumakeとdmakeを併用しなければならず、またとてもおかしなシェルスクリプトを実行しなければならない。
このおかしなシェルスクリプトは、コンパイルに必要となる環境変数群を設定する。そのため、このシェルスクリプトは環境変数をシェルに留めるため、sourceで実行しなければならない。環境変数をビルドのために変更するので、笑えることに、一度ビルドしたシェルで、再びビルドすることが不可能なのだそうだ。もう一度ビルドしたければまっさらなシェルを起動しなければならない。さらにPerlで実装された独自ビルドシステムで2レイヤー式の並行ビルドを実現したりとか、わけのわからないことになっている。
ビルドは以下のような感じだそうだ。
# old and awful autoconf ./configure --enable-this-and-that source LinuxIntelEnv.Set.sh ./bootstrap cd instsetoo_native build --all
LibreOffice 4.1では、126000個のターゲットと1700個のmakefile、つまりすべてを完全にGNU makeに移行させた。
新しいビルドの感じ
# LibreOffice configure & make as of now: ./autogen.sh --enable-this-and-that make
単純だ！
LibreOfficeのソースコードには、ドイツ語で書かれたコメントが多数あるそうだ。国際的な貢献を得るためには、コメントは全て英語で書かれていることが望ましい。そのため、今ドイツ語のコメントをすべて英語に翻訳する作業が進められている。LibreOffice 3.3では5万件以上あったドイツ語のコメントが、LibreOffice 4.1では、あと１万6千件強といったところまで減らせたらしい。ドイツ語の分かる貢献者を募集中なのだとか。ドイツ語のコメントを探すためのツール、bin/find-german-commentsも用意されている。
LibreOfficeは、Javaへの依存度を減らすべく努力してきた。これはすばらしいことである。特に、Javaランタイムを宗教上の理由で排除している私のような人間にはとても好ましい。LibreOfficeでいまだにJavaを使っている部分としてよく言われるのが、一部のウィザードとデータベース関連だ。LibreOffice 4.1では、Javaで書かれたウィザードを、すべて完全にPythonで置き換えたそうだ。
No comments:
Post a Comment