«前の日記(2005年02月20日) 最新 次の日記(2005年02月22日)» 編集

Matzにっき


2005年02月21日 [長年日記]

_ [言語] Minimizing Row Displacement Dispatch Tables

ちょっと古い論文。だけど知らなかった。

静的言語ではダイナミックディスパッチの実現にC++のVirtual Table(VTABLE)のような ディスパッチテーブルを用いる手法が使われることが多い。 これは「高速である」、「コンパイル時の情報が豊富」などの性質が有利に働くからだ。

上記の論文はこのようなディスパッチテーブル手法をSmalltalkのような動的言語に適用する、 というもの。動的言語特有のクラスやメソッドが動的に追加された時にどう対処するかという点についても 考察されている。

目新しい点は

  • 二次元(クラス×セレクタ)のテーブルを一次元に圧縮する。まず、疎なテーブルをソートし、 大きいものからfirst hitで一次元の配列に格納する。取り出しはオフセットを使う。
  • テーブルを圧縮する時、 通常は表をクラスごとに分割するが、セレクタごとに分割することを推奨している これによりセレクタの追加が行の追加ですむので更新時の効率が上がる。
  • クラスが追加された場合には複数のディスパッチテーブルを持つ(method_missingで第二のテーブルにフォールバックする)ことで対応。新しいクラスは少々遅いが全体としては速い実装が可能。 暇な時にディスパッチテーブルの再構成を行う。

なかなか効率は良さそう。しかし、この手法はRubyのようなオープンなクラス(既存のクラスにメソッドを追加できる)ではテーブル再構成が増えて効率が悪くなるかも。ここをどう解決するか。

_ [特許] CAもオープンソースへの特許公開を確約

Computer Associates(CA)は自社の特許ポートフォリオの一部をオープンソースの開発者に公開し、すでにこうした動きに出ている他社を追従する計画を進めている。

同社関係者によると、CAは自社の特許を利用して、オープンソース製品に対する法的攻撃からユーザーや開発者を守る考えもあるという。特許の公開時期やライセンス条件の詳細については今後決定されると、この関係者は述べた。

とりあえず素直に歓迎したい。望むのは、どうせ公開するなら(Sunのようにではなく)IBMのような上手な方法で行われることだ。

「自社の特許を利用して、オープンソース製品に対する法的攻撃からユーザーや開発者を守る考え」というのは、IBMのアナウンスよりも一歩踏み込んでいるように思える。

もっとも、そもそもソフトウェア特許に運用に問題があるからこんなことが必要なんだ、 ということは忘れないようにしたい。なにか良い解決策はないものか。

既得権者には受け入れられそうもないが、「特許の有効期限は2年」というのが 一番「産業振興に利する」ように思えるなあ。

_ [OSS] フリー/オープン・ソース・プロジェクト管理の要諦

Perl, Apache, Linuxの各プロジェクトリーダー(「元」も含む)の言葉。

まあ、一言にフリーソフトウェア/オープンソースソフトウェアと言ってもあり方はさまざまだ。

たとえば私が関わるものだけでも、 Rubyはよくも悪くも私が始めた「私のもの」で、いろんな人の意見を反映するとは言え、 最終決定するのも、責任を取るのも私だ。 逆にcmailは私はオリジナルの作者ではなく、引き継いだ保護者であり、 そして集団管理体制に移行した(が、最近は衰退しているんだろうなあ)。

どれがいいとは断言できないが、 参加しやすいコミュニティを持つものは長続きしそうな気がする。

ところで、この記事のタイトル「要諦(ようてい)」って知らない言葉。 辞書によると「肝要なさとり」あるいは「肝心の点」ってことらしいけど。 原文タイトルの「The paradox of free/open source project management」とはずいぶん印象が違う。

ここで言う「paradox」とは

フリー/オープン・ソースプロジェクトを立ち上げ大成功に導きたいのなら、時機をあやまたずに手放す計画を立てよ。

ということらしい。上記のインタビューのどこからそういう結論を引きだしたのかよくわからないけど、 まあ全く嘘というわけではない。

でも、同じインタビュー(と自分の経験)から、私が教訓を引き出すとしたら、

  • OSSの成功にはリーダーシップが必要
  • リーダーの必要条件は「コミュニティから尊重されること」。 そしてそれは「正しい判断を行うこと(行い続けること)」、 「失敗しても適切に対応すること」、 「権利を保持しつつもそれを乱用しないこと」で得られる。
  • プロジェクトが大規模化すると組織化が必要になる。 全部自分ではカバーできない。

くらいかな。上記の「結論」は最後のものだけを強調し過ぎているように思う。

_ How NERDY are You?

Overall, you scored as follows:

6% scored higher (more nerdy), and
94% scored lower (less nerdy).

What does this mean? Your nerdiness is:

Supreme Nerd. Apply for a professorship at MIT now!!!.

だそうだ。そんなに?


«前の日記(2005年02月20日) 最新 次の日記(2005年02月22日)» 編集