先日、
現在のトラックバックは使いにくい。permalinkを出して、そこからping URLをコピーして、 自分のページにペーストするなんて、なんか人間の労力の無駄使い。 bookmarkletもBlogツールによって使えたり、使えなかったり。 ping URLの表示形式を統一するか、HTMLヘッダに埋めこむかすればツールが処理できる。 近藤さんが「はてな」で対応して、たださんを説得してtDiaryも対応すれば、 日本のBlogっぽい分野では十分トレンドを発生できそう。
Trackback Auto-Discovery という仕様がありますが不十分でしょうか？
え？
あわてて調べたらなんとそんなものはもうとっくに存在しているのね。 RDFでTrackback Ping URLを埋めこんでおくと。 Ping URLを抽出するCGIも存在するし、手元でも Bookmarkletを適切に使えば、ちゃんとTrackback Ping URLを見つけてくれる。
単なる無知でした。お恥ずかしい。(_ _)
お笑いだったのは既にMatzにっきも対応済みだったこと。
「はてな」は対応してないんだけど、あそこのTrackbackはちょっと違うみたいだからなあ。
日経ITproより。
北海道はもともとオープンソースに積極的であったが、 マイクロソフトもベンチャー企業や人材の育成に協力するというニュース。
地方自治体の中でもオープンソースに関心のあるところは多い。 財政改革とやらで地方に回る金は極端に減額されているので、 自主財源の少ない、いわゆる田舎では死活問題だ。TCOを削減するためならなんだって検討するだろう。
とはいえ、本当にオープンソースが有効なのか不安を感じる自治体も多いようだ。
そこでこういうのはどうだろう。
自治体には「オープンソースの全面的な採用を検討する」とプレス発表してもらう。 すると、危機感を感じたマイクロソフトが企業やその自治体の人材の育成に協力してくれる。 どっちに転んでも自治体はハッピーというのは。
Rubyのバグ修正をいくつか。
本当は1.9の文法をいじろうと思ったのだが、 構想がまとまりきらなかった。
考えていたのは
などだ。しかし、後者はlambdaに相当する新しい文法を考えなければならないようだ。 現在の「|x|」のような形式ではメソッド引数リストと同じ文法を使えない(省略時の値としてbit-or演算子としての「|」がくる可能性があるから)。
なやましいものだ。
私が中学生の頃、技術・家庭科と言えば、 男子が技術科として工作などの技術を、女子が家庭科として裁縫や料理を習うものであった。 しかし、娘に聞くと、今の中学生は男女分け隔てなく同じことを習うようだ。
しかも、技術科の内容のかなりの割合がコンピュータの取り扱い方だったりする。 娘の教科書の巻末の用語集はほとんど「IT用語集」の様相を呈しており、 「コンパイラ言語」とか「バグ」とかの用語が解説されているのを見ると 時代の流れを感じる。
キルギスという国をご存じだろうか？
Wikipediaによれば、
キルギス共和国（キルギスきょうわこく）、通称キルギスタンは、中央アジアにある旧ソビエト連邦の共和国。首都はビシュケク（旧名フルンゼ）。クルグズスタン、クルグズ共和国ともいう。
なのだそうだ。
で、キルギスでIT技術者要請プロジェクトを実行中の、 JICAから要請を受けて、キルギスの技術者に対して、Rubyの紹介をすることになった。
とはいえ、中央アジアまで行くのは現実的ではない。 聞くところによると、以前キルギスまで人材を派遣して一日のセミナーを行ったところ、 移動などを含めて足かけ9日かかったということだ。勘弁して。
ということで、新宿にあるJICAの施設からテレビ電話で講義を行うことになる。 朝一の便で出雲空港から東京へ移動。
昼食後、会場へ。 簡単な試験をしたが、無事に通信もできそうだし、 CRT出力も完璧。
トラブルといえば、原稿表示用に持っていった2台目のラップトップがUSBメモリを認識せず、 しかたなしに原稿表示には、現地にあったPCを借りたくらいか。 が、数分の作業で対応できたので、ぜんぜん問題なし。
で、途中まで、スムーズに話は進んだのだが、 途中、突然通信が途絶する。
先方で停電があったのだそうだ。まだまだ電力事情は厳しいらしい。
しかし、向こうもそのくらいのことは予想している。 発電機を利用して通信を再開するということになった。
数分後、通信再開。
しかし、発電機の性能のせいか、 たびたび通信が中断するようになる。 こちらからは伝えたつもりの内容が実は伝わっておらず、 「2枚ほどスライド戻って、もう一度説明してくれ」というようなことが 頻発して、ちょっとつらい。
この調子で進んでいると、通信が完全に中断してしまった。 どうも、電力不足でブレーカーが落ちてしまって、 発電機が作動しなくなってしまったらしい。 あとで聞くところによると、今日はたまたま発電機担当の技術者が病欠で、 よくわからないまま無理をしてしまったらしい。
「プレゼンの呪い」は健在であった。
しかも、今回は発電機まで壊してしまったし。
まあ、自分のせいじゃないからいいか、と自分を慰めることにする。 中断後、向こうのセミナー参加者は大変興味をもって、活発なディスカッションが行われたらしい。 「後で、まつもとも交えてディスカッションできたらいいね」という話になる。
本当に。
発表用スライドはこちら。 以前のものの使いまわしなので、新味はない。
出張やらなにやらどたばたしている間に届いていた論文誌を読む。
ささだくんの論文「Ruby用仮想マシンYARVにおける並列実行スレッドの実装」が 掲載されている。私と前田敦司先生、並木先生も共著者に名前が載っている。
で、前から読んでいたこの論文はおいといて、 発表概要だけで論文掲載にいたらなかった「世代管理を保守的に行う世代別GCアルゴリズムの提案およびRubyへの実装と評価」というのが非常に気になる。
アブストラクトによれば、
本発表のアルゴリズムの特徴として、ライトバリアが必要ない、 メジャーコレクションとマイナーコレクションが一体化している、 および生きているオブジェクトの移動を必要としない ことなどがあげられる。
のだそうだ。うーむ、どうやって実現しているのだろう。 アブストラクト中でのヒントはこれだけ。
先頭側の領域をold領域、末尾側の領域をnew領域に分断し、 old領域に属しているオブジェクトはすべて古いオブジェクトと見なす 新しい世代別GCアルゴリズムを提案する。 本発表のアルゴリズムでは、old領域ではnew領域へのポインタが存在するかを検査し、 new領域ではGCを行う
のだそうだ。うーん、オブジェクトの移動を伴わないのに どうやってnew領域とold領域を分断するのかな。
そうか、アレか。木山版みたいにリンクリストで世代を管理してるのかな。 で、old領域のオブジェクトにはマークビットを立てたままにしておけば、 old領域のそれぞれのオブジェクトから 再帰マークするだけでold領域からnew領域のリファレンスを検出できるよな。 後は普通にルートから再帰マークを行い、 new領域に属するオブジェクトだけをスイープすればよい。
メジャーコレクションしたい場合には事前にold領域のマークビットをクリアしてから GCすればよいことになる。 もちろん、メジャーとマイナーの切り替え戦略とか、 検討すべき点はいくつかあるだろうけど、そんなに悪くないアイディアのように思える。 意味があるかどうかわからないけど、複数世代への拡張も可能だし。
では、このアイディアが論文掲載に至らなかった理由はなんだろうか。
まあ、GC時間が30%近く改善されたらすごいと思うけどな。 もっとも、ここで示した方法では「メジャーコレクションとマイナーコレクションが一体化」は 達成できていないような気がするので、また違うアルゴリズムなのかもしれない。
とか書いてると、作者からコンタクトがあるかも。 神奈川工科大の五百蔵(いおろい)さ〜ん、見てますかぁ？
さらに考えてみた。
あるGC時点で存在するすべてのオブジェクトの総数をm、 old領域に所属するオブジェクト数をo、 new領域に所属するオブジェクト数をnとした時、
m = o + n
であるが、ここで、old領域で「生きている」オブジェクト数をoL 「ゴミになった」オブジェクト数をoGとする。 new領域でも同様にnL、nGがある。
o = oL + oG n = nL + nG m = (oL + oG) + (nL + nG)
さて、ここでマークフェーズとスイープフェーズのコストを考える。 従来のGC方式ではマークのコストは、生きているオブジェクト数に依存するので
oL + nL
になる。また、スイープは全部のオブジェクトをスキャンするのでコストは
m (= o + n)
である。
この「世代別」方式でのマークのコストは、 (old→new参照を検出するため)旧世代オブジェクトから全部マークした上、 主にnew領域を対象に通常のマークを行うので、
o + nL
となる。スイープのコストはnew領域のオブジェクトのみになるので
n (= nL + nG)
である。
さて、これを元に旧方式と新方式のコストを比較すると、 マーク時のコストは
旧方式: oL + nL 新方式: oL + oG + nL
で、oGぶんだけ新方式の方が増加している。 経験則からoGは小さいことが期待されるとは言え、 マークコストの増加は痛い。
一方、スイープ時のコストは
旧方式: o + n 新方式: n
で、old領域をスキャンしなくてもよい新方式の方が優れている。
スイープはnew領域だけスキャンすればよいという点で、 有利だが、実はスイープは一気にやらず遅延するテクニックがあるので、 それを使えば差はほとんどなくなるかもしれない。
正確に結果を知るためには、実装して測定してみるのが一番だけど、 こうやって机上で考える範囲内では期待するほど有効じゃないかもな。
世の中甘くない。
550行のCで実装されたTclサブセット。
Tclってのは小さな言語だが、550行ってのはすごい。 先日の(圧縮された)lisp500とちがってまともなコードで550行ということである。
勉強になる、かも。Tclが変な言語であることは置いておくとして。
picolのページには「Rubyなどで書いたら200行以下で実装できるだろう」とあるが、 Haskellで書いたTclサブセット(hiccup)は 250行だそうだ。
とうとう出た。
自分で最終的な判断をするのは、これからGPLv3がどういう意味と影響を持つのか 見極めてから。それまでは、引き続きRubyのライセンスは独自とGPLv2のデュアル。
今の計画では、
のいずれかを考えている。最後のものは最終手段として、できれば避けたいものだ。
Xtalではインスタンス変数は配列として持ち、オフセットで管理される。 一方、RubyやPythonではハッシュテーブルとして持ち、名前で管理される。
これは純粋にトレードオフで、 配列の方がアクセスは高速だし、インスタンス変数のタイプミスがコンパイル時にわかる というメリットもある。しかし、名前によるアクセスも 動的にインスタンス変数が追加できるので、 オープンクラスや特異メソッドに対応しやすいという利点がある。
で、リンク先のエントリでは、XtalとRubyとPythonでベンチマークを取っている。 インスタンス変数に対して加算するという単純なものだが、 結果は
で、配列方式を取るXtalが一番高速であることがわかる。 っていうか、Ruby 1.8遅いな。
ま、配列アクセスの方がずっと高速だからね。
...と、言いたいが話には続きがある。 実はこの同じベンチマークをYARV(1.9)で実行したら、
となった。つまり、どういうことかというと、 (少なくともこのベンチマークでは)インスタンス変数のアクセスコストは支配的な要因ではない、 ということだ。
パフォーマンスに必要以上に注目してしまうことも、 適切でないベンチマークを選んでしまうことも、 私も含めて多くの技術者が陥りやすい罠だ。
ベンチマークは奥が深い。