プレゼンテーション。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のような言語でそんなに最適化が効くような気はしないけど。
謎は深まる。
Rubyでネイティブスレッドに対応する予定はあるんでしょうか?
デュアルコアが普及してもパフォーマンス上がらないのは困ります。
dRubyで分散プロセスだとオーバーヘッドが多いですしね。
「対応」というのはどのレベルを考えていらっしゃるんでしょうね。
YARVではnative threadに「対応」していますが、それは
* native threadを使っている
* native threadを使っているライブラリとリンクしても落ちない
というレベルです。global interpreter lockを使っているので、native threadを使ってもさほど並列性はあがらず性能もあがりません。
というのも、オブジェクトアクセスひとつひとつを排他制御しなければならないので、コンフリクトは無視して問題が起きそうなら自分で対処というようなC++のような対応はスクリプト言語では難しいでしょう。
ささだくんは将来Multi-VMとかでnative threadを使った並列性の活用について構想しているようです。あるいはTermite[http://toute.ca/]のようなアプローチもありえるかもしれません。
また、PythonのGuido van Rossumはスクリプト言語の並列性について
http://mail.python.org/pipermail/python-3000/2007-May/007414.html
という(むしろforkを活用すべきという)意見を述べています。
> 身分は隠して
きっとバレてる
> 普通に考えたら、mod_phpやfastcgiを使えば、構文解析はほとんど行われないと 思ってしまうが
たしか、標準状態の PHP はリクエストの度に構文解析を行っていたかと思います。mod_php でもそれは同じだったはずです。
phpの中身を何にも知らないでコメントしますが、「内部的に用いる中間表現」が何かによってかなり変わって来るでしょうね。単なる構文木ならホントに節約されるのは構文解析だけですが。
Gaucheの場合、「構文解析」に当たるのはreadで、このコストは無視できます。その後のコンパイルステージは3パスに分かれていて、パス1でリストから変数束縛情報などを追加した内部表現に、パス2で最適化、パス3でコード生成を行うんですが、実はこのパス1がコンパイル時間の6割を占めています。なので、中間表現がある程度の解析を含むものなら、キャッシュすることでかなり速くなっても不思議は無いような。
PHPは毎回構文解析するみたいですね。
(PHPからRailsに来た人だとそれではまるらしいです。
productionで変更が反映されなくて。)
実は毎回環境を全部リセットしたりするんですかねえ。
毎回リセットのはずです。PHP の基本は高級 SSI ですから、いきなりキャッシュされると困るケースの方が多いんじゃないでしょうか。それと PHP 界隈ではアクセラレータという表現が一般的だったりします。