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

昨日ある研究者と議論していて、自分が(も)書いているコードをオープンソースにするかどうか、迷っているといわれた。私は利益が多いと思っている。以下に研究用のパッケージコードはオープンソースにすべきだという理由を挙げてみる。

* 研究者は税金で養われているので広く社会に還元すべきだということ。
今後、10年20年の単位で考えると、研究者の研究はコンピュータを非常に高度に、複雑に使い、簡単には再現出来なくなってくるだろう。ありえないだろうが、もし、今後、研究者のコードの商用性が主流に成るならば、税金の使い道として、特定の利益者に与する研究者に税金を支払う機会は減ってくるだろうと思われる。従って、優秀なプログラムをオープンソースで書き、リリースできる研究者は社会に還元し、社会にあらゆる意味で役に立っている、分かりやすいシグナルを発している訳で、当然より生き残りやすくなると考える。

* あなたの研究が、より信頼性の高い研究と認知される。
高度にコンピュータを使うと、再現も困難になると上で指摘したが、再現が困難な研究の信頼性はどのように担保すべきなのだろうか。オープンソースならば、再現してもらえる可能性は非常に高くなるし、その上で、同じ結果がだせるのであれば、信頼性が高い研究と第三者が認知出来る。また、あなたのプログラムにはバグがないのだろうか。バグがあるからよい結果として見えているだけかもしれない。他人に試してもらう機会はオープンソースだとぐっと増える。

* 必要なお金はファンドの充実やユーザーサポートで賄うことができること。
ファンドは充実してきたし研究実績としても扱えるので、お金を細かく稼ぐより効率が良くなる可能性も高い。さらに近年ソフトウェアの価格は下がってきたので、ソフトウェア自身で稼ぐのは難しくなるだろう。実際、これらはユーザーサポートなどで金銭的なフィードバックを得て開発費などにあてている(Apple storeなどをみよ)。

* 研究に関して広くフィードバックを受けられること。　
　フィードバックは意外と様々な分野の人から受けられる。それはアカデミックの分野にとどまらず、産学民から国を超えて様々なフィードバックがくる。世界中のいろんなところに優秀な人はいる。確かにライセンス契約をすると、自分の目の届く範囲で密なフィードバックを得られるが、そこで広がる人間関係は限られる。全く違った分野から、全く気づきもしなかったより良いフィードバックは、オープンソースにした方が機会が増えるため、得やすい。上とも関連があるが、バグも指摘してもらえる。自分の経験からも明らか。

* 自分の名前を売ることができること。
サポートメーリングリストを立ち上げるのは普通だが、そこで開発者である研究者が直接対応することで、自分の名前を売ることができるようになること。これは研究者だと当然ありがたいことである。
よくあることだが、偉い教授の下で開発していると研究者コミュニティでは実際の開発者である助教、ポスドクだと名前を売りにくい。だが、偉い人たちは今度は時間もなくメーリングリストなどで議論出来る時間も限られるし、開発からはなれるに従って議論もできなくなる。実際にサポートされた側は意外とよく、実際に開発している人の名前を覚えている。

* 転職に有利。
(上に続けて)名前が売れたら当然であろう。

* 長く続けられる可能性がでること。
　企業にいると、倒産したり、買収されたり、転職したりすると、自分が開発したにもかかわらずコードの開発ができなくなることがある(特に困るのは、権利関係がうやむやになることだろう)。しかしオープンソースならばその可能性を消すこともできる。sourceforgeなどにコードを置き、オープンにすることでどのように人生の転機を迎えても自分の意志のみで開発を続けることができる可能性が高い。

* 後継者が見つかるかもしれない。
　後継者問題はどの世でも問題である。ただオープンソースだと様々な立場で参加出来る可能性があるため、参加者もより多くなるだろう。従って、後継者を見つける可能性は増える。後はあなたの人徳次第となる。

* 友達が増える。
　オープンソースに限らないが、開発していると、学会などで全く知らない人から「使ってます、ありがとうございます」といってもらえることがある。それをきっかけに友達が世界中にできる可能性がある。オープンソースだと商用ソフトより名前も出やすく、利用者も多いので、その機会はより多くなるだろう。

以下はオープンソースにするリスクに関する疑問とそれに対しての答えを考えてみる。

* 盗用されないか？
商用だとしても、もし、ソースコードを限定的に開示していても、盗用される時はされる。オープンソースならば盗用されやすいか、というと、この質問にあまり意味がないということがわかる。コードのプライオリティや著作権の問題はソースコード管理用のログなどでクリア出来る。

* 自分のコードをもとにして、別プロジェクトが立ち上がるのではないか。
　開発している人は自分のプログラムが盗用されたらすぐ分かるものである。従って、全くの第三者があなたのコードをもとにして別プロジェクトをさも、じぶんがやったことのようにして立ち上げるとすぐわかるだろう。これを心配する気持ちはよく理解するが、ただ、やはり偽物は偽物で、それ以上、超えてコードを書くようになるのはかなり難しい。また、そうならなければ、別プロジェクトは、あなたのプロジェクトのサブプロジェクト程度しか認識されないであろう。人はアクティブなところにあつまり、アクティブなプロジェクトを信頼する。ただそれだけである。自分自身のモチベーションが切れないかぎり、別プロジェクトはマイナーなフォークと見られるだけである。

* オープンソースは死んだプロジェクトが多い。自分のプロジェクトも死ぬのではないか。
あなたが生きていてそのプロジェクトへの情熱を失わない限り、プロジェクトは死なない。死ぬはずもない。これはオープンソースだろうがそうでなかろうが、関係はない。

* ライセンスの設定をどうしていいか分からない。
　アプリだとLGPLやGPLが適当だと思う。ライブラリ系だとより緩い2-条項 BSDがいいと思われる。

* 誰かに何も断られず使われるかもしれない。
　それは仕方ない。逆に、あなたもたくさんのオープンソースのプログラムを使っているだろう。それに対して断りを入れたことはあるか。感謝の言葉を一言でもいったことがあるか。寄付したことはあるか。ある人間があなたのプログラムを使って引用しないならば逆にメールを送って引用してくれといえばいい。ここら辺は相手の人間性の話になるだろう。あまり変な人とは付き合わない方がいい。自分の経験では、そこまで変な人は逆に認知されていくし、人間社会って結構犯罪少ないでしょう？それは人間はそれぞれ大変信頼しながら生きているということに他ならない。善意を信頼していただきたい。

* 自分のプログラムが役に立つとは思えない。
　まぁそういわないで自信を持とう。意外とあなたのプログラムを必要としてくれる人はいる。

私の感覚としては、むしろ、今後はオープンソースプロジェクトでより「有用な」プログラムを書くのは誰かという指標が出てくるのではないかと見ている...厳しい戦いは続くはず。

私はオープンソース化をとても応援します。

他にも疑問質問などあればコメント欄にどうぞ。

倍々精度or疑似四倍精度は今後エクサフロップスに向けて欠かすことのできない技術として
認識されつつあるが、IBMも日立も富士通もdouble-doubleを四倍精度として使うことを古くからやっており、コード自体は意外と古くからあるようだ。

たとえばPower系についてのコードはオープンソースの形で見ることができる。

AppleのPower向けMacOSXでは、DD(倍々精度 or double-double)のlibm部分の
ソースコードが公開されている。
* Leopard
* Lion (アレと思う人もいるかもしれないが)

また、もっと直接的に、gccでもコードを見ることができる。
* gcc/config/rs6000/darwin-ldouble.c
である。RS6000(Power系)のgccではlong doubleとするとdouble-doubleとなる。ただし他のアーキテクチャではそのようなコードはない。今はgccではfortranにはlibquadmathが入っており、これらとの整合性は多分ない。

ただこれが将来デフォルトに成るかということだが、これはよくわからない。negativeな意見としては、
倍々精度をlong doubleC99規格にはexplicitに違反する。欧米人はこのようなworkaroundは好きじゃないかもしれない。例えば、かのW. Kahanは嫌っている。positiveな意見としてはIEEE 754 2008が発効されてるが、ハードウェアサポートは著名なプロセッサでは需要がまだなく、今後サポートされないだろう、ということと、double-double程度ならば少しのハードの追加で効率よく計算出来るようになる(と牧野先生に教わった)という点が挙げられる。

AppleのLionのソースコード(libm)を見ると、PowerPCのディレクトリが残っていたり、ARMのディレクトリがあったり。
もしかしてビルド程度はできるのか知らん。もしかして、今後ARMをサポートするのか知らん。

と、思ってみたりした。

リリースアナウンス

これはNVIDIA C2050で行列-行列積を高速に行うルーチンで、BLAS, LAPACKのスタイルを踏襲したMPACKのルーチンの一つRgemmを加速したものです。

だいたい、16GFlopsくらいでて(CPU-GPU転送も含め、精度を落とすと26GFlops程度までさらに高速化する)、CPUの参照実装とくらべると、150倍程度高速です。これ以上、劇的に高速化するのは、アルゴリズムを変えない限り難しいでしょう。チューニングされた倍精度行列-行列積はCore i7 920で42GFlopsなので、なんと、その半分程度の性能が出ます。

プログラムは高雄保嘉と中田真秀で行いました。

これはベンチマークとなっていて、

$ tar xvfz Rgemm_C2050_20111026.tar.gz
$ cd Rgemm_C2050
$ make
...
とするとCSVファイルにベンチマーク結果がかえってきます。

他の研究用の実装とは違い、応用を主眼としているので、Rgemmの仕様にそったものとなり、さらに他のプログラムなどに埋め込み、信頼性などを確かめています。応用については近々発表する予定です。
また、
これを礎にしてさらに様々な線形代数演算ルーチンが加速できます。

自分の職場は何も問題がないが、事務部門について定年制職員が退職すると、
任期制の職員で補充、(または補充無し)になるが、彼ら、彼女らの待遇改善をしてほしいと
いっておいた。派遣、それ自体は就職の機会を増やすため悪くない。しかし、弱い立場なので
苦しい思いをさせられているのは端から見ていてしんどいし、こちらの業務にも支障がでる(いまのところないけど)。

* 定年制をへらすというのは国の方針らしい。公務員を減らすということである。
* ただ、派遣職員は入札と成るため給料が下がりやすい。
* さらに中抜きされるので直接雇用より職員にわたるお金が減るため、より安い賃金となる。
* そうなると苦しくなる部分が出てくる。経験豊富な人がやめた瞬間、ノウハウが消える、長期の雇用がなくなるのでノウハウが消えやすい、引き継ぎが一日もないこともある(やめた次の日に新しい人が入ってくる、など)、

大変使命感を持って働いてくださっている事務の方も多くありがたいのだが、ほとんどが派遣になってきている事務、受付、これ今後まわるのか？疲弊しないのか？と思うこと多々。

むしろ労働組合にいったほうがいいのかね...