プレゼンテーション。11時から最終練習という話だったが 少々遅刻した。ごめんね。
練習後、昼食。ビッグサイトはどこも満席。 かろうじてカレーを食べる。
1時からのSeasarのひがさんのセッションは大混雑。 すごい人気である。
と、思ったら、2時からの私のところも馬鹿にならない人数が集まる。 30分以上前から席を陣取ってる人までいるし。 最初30分弱は私がRubyをとりまく現状について話して、 残り15分くらいを山崎さんにデモしてもらう。
いつも、スライドばかりでおもしろくもないプレゼンだが 今回は趣向を変えて、と思ったのだが、担当になった山崎さんには いい迷惑だったかもしれない。せめて成長の糧にしてね。
デモのある発表は初めてであったが聴衆はどう感じたろうか。 数人に話を聞く限りでは、 おおむね好評だったのではないかと思う。
ただし、難点もあって、
くらいは残念だった。まあ、こんなに人間が来ることを想定した会場設計ではなかったものな。
ほか、風呂グラマー、増井(masuidrive)さんに会ったり、あちこちブースをめぐったり。 増井さんはおととしのOSC札幌で私が英語で質疑応答したのに影響されて アメリカに引っ越すのだそうだ。すげーっ。
思わぬところで他人の人生に影響を与えてしまっている。 なんだか恐いような気がする。
昨日公開された、私・平鍋さん・角谷さんの鼎談。 Linux World会場でもうちのブースで上映されていた。
今回はAgile・オブジェクト系言語の歴史概観。 ホワイトボードに書いていたものをタイムライン化したものも用意した。
うだうだとした話だが、これはこの後もずっと続きます。 ぜんぶで6話くらいになるとか聞いたような気がする。
「Rubyの鍵は信頼である」という話。
信頼については昨年末の福岡での発表で強調した覚えがあるが、 この人はそれを(Google Translateかなにかで)翻訳して読んだのだろうか(スライド公開してないような)、それともRubyを見ていて独自にその見解に到達したのだろうか。
どうも後者のようだが、だとすると、その感覚は非常に鋭い。 まるで言語仕様(とわずかな私の言葉)だけから「Ruby Way」を切り出してきた Hal Fultonのように鋭い。
Enumerableを操作するのに
@stooges.select {|s| s.name == 'Mo'}
と書く代わりに
@stooges.that.have.name == 'Mo'
と書くためのライブラリ、ho_enumerable.rbについて。
非常にRailsというか、ActiveSupportと同じ臭いがするが、 それはそれでアリなんじゃないかと思う。 でも、こういうのをHigher Orderっていうのかなあ。
というわけで、昨日U-20プロコン実行委員会でポロシャツをいただいたわけだが、
なんて書かれた(しかも出かける前にこのエントリを読んでしまった)からには、 着ていかないわけには行くまい。というわけで、Linux Worldでは 関係者でもないのもAsianuxポロシャツを来ている「自称ハッカー」が目撃されました、とさ。
あと、オライリーからも何枚もTシャツをいただいてしまった。 ありがとうございます。
夏時間(Daylight Saving Time - DST)のせいで計算が狂って2004年10月には30日しかないことになってしまったプログラムの話。
もう何年も前の話になるが、RubyのTimeクラスにも面倒なバグがあって 半年に一回1時間ずれるというレポートに対処するのに大変苦労したことがある。 何年かに一回政治家たちが省エネとか訳のわからない理由を言い訳に サマータイム導入を口にするが、冗談じゃない。
夏時間がないのは日本の美徳だと断言したい。 そんなものは要らない。
「今まではハードがどんどん高速化してきたので、ソフトウェアの皆さんは(マシンのアップグレードで)自動的に性能向上を享受できていましたが、これからは諸般の事情でそういうことはできなくなります。ソフトウェアの皆さんもご協力を」という話。
っていうか、最初からそういう風に言ってほしいものだ。
LinuxWorldでゼンドジャパンのブースに行って質問してきた。 あまり嫌みにならないよう、身分は隠して。
で、関心があったのはPHPのスクリプトキャッシング。 これにより実行速度が1.3から3倍になるのだそうだ。 どうにも納得が行かないのでいろいろ食い下がったが 対応してくださったのが内部までご存じの技術者ではなかったので 「理屈はともかく体感では確かに速くなります」とのことであった。 実体験を疑う理由はない。が、技術屋としては「なぜそうなるのか」がとても気になる。
私の理解が正しければ、スクリプトキャッシングは、 プログラムのロード時に構文解析を行い、内部的に用いる中間表現に変換したものを 保存しておくことにより、構文解析のコストを削減し、 高速化を実現する技術である。PHP以外にもたとえばPythonが同様のことを実現している (でも、Pythonは1.3倍とか言ってない)。
しかし、これにより実行速度が1.3から3倍になるということは、 単純に計算してアプリケーションの実行時間の23%から67%が 構文解析で消費されている必要があるのではないか。 Rubyではよっぽど特殊なケース以外では構文解析時間が 実行時間に対して大きな比率を占めたことはない。 各種プロファイルを行っても構文解析関係が上位に来たことは 私の経験では一度もない(ので、通常の感覚ではチューニングの対象にならない)。
にもかかわらず、PHPではこの結果というのはどういうことなのだろうか。 ソースも見てないので、断言はできないのだけど、いくつか考察してみる。 間違いがあれば(きっとある)、遠慮なく指摘してほしい。
構文解析が予想以上にコスト高
普通に考えたら、構文解析はそんなに重い処理ではないのだが、 実はそれは思いこみで、なんらかの事情でPHPでは構文解析のコストが非常に高い。
構文解析が予想以上に頻繁に実行される
普通に考えたら、mod_phpやfastcgiを使えば、構文解析はほとんど行われないと 思ってしまうが、実はそれは思いこみで、なんらかの事情でPHPでは構文解析の頻度が 非常に高い。あるいは実行速度が改善されたというのはCGIモードであった。
実は単なるキャッシングではない
スクリプトキャッシングは単なるキャッシングではなく、 同時になんらかの最適化も行っている。 キャッシングされて何度も実行されることが期待されるので、 かなり頑張って最適化しても、時間消費に見合う。 とはいえ、PHPのような言語でそんなに最適化が効くような気はしないけど。
謎は深まる。