朝の第一便で東京から戻る。伊丹に降りるかもと脅されたが、 結局無難に出雲に帰れた。そのまま息子の保育園へ。
保育園の出し物はなんか緊張感がないというか、力が抜けているというかなんというか。 まあ、そこがいいんだろうな。のんびりと眺めていた。息子は緊張しやすいたちなのか、 堅い顔をしていたのだが、なんとか自分の役割をこなせたようだ。
なんか先週あたりから急激に話が進んでいるような。
それに原作とかなり乖離してきている(6巻までしか読んでないけど)。 なんとなくアニメの方ができが良いような。
スピード感はあるし、順番を並べ替えつつもストーリーが破綻していない。
第一日曜なので松江。聖餐会では何人かの方が先日の告別式についてお話をした。 「心のこもった会であった」という印象は共通のもののようだ。 キリスト教式の分かりやすい会であった(素人には意味がわからないお経とかはないし)、 というのもあるだろうが、それよりなにより故人が生涯かけて築いた人徳があるのだろう。 葬儀社の人も「私もこういう式がいいなあ」と言っていたとか。
その他はごく普通。
夕方、先月できなかった長女との面接。思春期の割に素直な娘に育ったものだ。 ありがたいことだ。
告知
知る人ぞ知る(登録会員１名)のMatsue Ruby Meetup Groupは、 3月8日(火)午後6時30分からミーティングを行います。
場所は
松江市学園南 2-12-15 HOYOパークサイドビル2F (株)ネットワーク応用通信研究所 0852-28-9280
です。テーマは「最初なので自己紹介」 あるいは「RubyとWebアプリケーション」 または「Ruby 2.0の仕様について考える」です。 当日の参加者の希望によって決めようと思います。
なんとなく会社のメンバーしか集まらないような気がしますが、 一般の参加者も歓迎します。
朝一の便で東京へ向かう。久しぶりの海外、しかも初のアジア訪問ということで 緊張している。スーツケースを持って、チケット持って、PC持って。 例によってPCの調子が悪くなるといけないから、 予備のPCと(これもビデオ出力がうまくいくとは限らないんだが...)、 USBメモリも忘れちゃいけない。
羽田について、成田に移動しようとしたその時、 カバンにパスポートが入っていないことに気がつく。
がびーん。
うちに電話したら、確かに思った通りの場所にパスポートが置いてある。 すばらしい記憶力、じゃなくて、なんなんだよ、このボケ加減は。 自分にキレそうになる。
大あわてであちこちに連絡する。 会社に連絡するが、都合よく松江からこちらに移動する人はいないようだ。 いずれにしても予約した便には間に合わないので 旅行代理店に連絡して、リスケジュールしてもらう。
その間に出雲への往復チケットを購入。 当日券なのでお高い。ぐすん。窓口のお姉さんには「残念でしたね、でもマイルはつきますから」と慰めてもらう。慰めになってないよ、お姉さん。
羽田から出発直前に旅行代理店から連絡があり、 シンガポール経由の便なら明日の早朝にクアラルンプールに到着できるとのこと。 他に選択肢はないので、その線でお願いする。
そのまま出雲空港へ。 妻(と末娘)に空港まで来てもらい、パスポートを受け取る。 が、戻りの便がないので1時間ほど喫茶店でデート。 しばらく会えないはずだったのに、妻や娘と時間を過ごせるのは幸せなこと、 なんだろうけれども、今しでかしてしまったばかりの大失敗のせいで心は穏やかでない。 こんなにうれしくないデートは初めてだ。
そのまま羽田へ。日に1往復半する事があるとは思わなかった。
羽田からリムジンバスで成田へ。今まで成田への電車使ってたんだけど、 バスの方がはるかに便利だね。速いし。値段はちょっと高くなっちゃうけど。 バスの中で発表原稿を書く。私くらいの英語力だと、英語発表の時には あらかじめ原稿を書いておかないとパニックになるから。
シンガポール空港の窓口でチケット購入。高い...。
そのまま、機中へ。シンガポール・チャンギ空港につくのは夜中の1時半(現地時間)だ。
機内では引き続き原稿を書こうと思っていたが、バッテリが不安だったので、 あまり分量は書けなかった。やっぱり拡張バッテリが必要かなあ。
が、まだ動揺しているのでそのまま寝る気にもなれない。 座席のスクリーンで映画を見ていた。 オンデマンドで巻き戻し・早送り、一時停止など、自由に操作できるのがありがたい。 文明は進歩してるなあ。 見た映画は
「チキン・リトル」は事前の予想通り、全然趣味に合わなかった。 が、できがわるいとかそういう問題じゃないよな。
「イーオン・フラックス」は非常にスタイリッシュな映画。 冷静にストーリーについて考えると腹が立つので考えないことにして、 瞬間瞬間の映像を楽しむとなかなかよろしいのではないかと。 なんか原作付きらしいんで、ダメなストーリーはそっちの責任だよね。 そういえば、まだ国内未公開なんだっけ。 あと、シャーリーズ・セロンってこんな顔だったっけ。
「Shinobi」はあまり見るつもりはなかったのだけど、 前の席の人が見てるのが目に入って、思ったより良さそうだったので。 確かに面白かった。私は山田風太郎の原作は読んでないので、 「バジリスク」と比較しちゃうんだけど、骨格以外は違った話になっていた。 どっちが原作に近いのかな。 いずれにしてもよくできていたと思う。英語字幕で「oboro-sama」とか書いてあったんだけど、 「-sama」は国際語化してきているのか。
知らない人はいないかもしれないけど、 CodeGearは、Borlandから切り離された開発環境を提供する子会社。 最近はDelphi for PHPを発表している。
動的なプログラミング言語では，Rubyに注目している。すでに弊社社長のBen Smithを含む上級役員の間で，CodeGearがRubyによる開発のための製品に取り組むことにコミットしている。ただし，どのような内容の製品になるかは現時点では明らかにできない。現在調査を進めているところだ。2007年中にCodeGearのRuby製品を提供できるものと期待している。
すばらしい。特筆すべきは、私がこのニュースを(どなたかのブログ経由で) 日経ITproで初めて知る点である。まあ、そんなもんか。
Pragmatic Bookshelfの新作。今度はErlangだ。 現時点ではβ版をPDFで入手できる。
もうちょっとRuby以外の言語の勉強に力を入れたいところではあるのだが、 どうしよう、買おうかなあ。
なんか、途中までは普通のことが書いてあるんだけど、 最後の結論がおかしい。
では，今までのデファクトだったシフトJISはどうだろうか。シフトJISを使うと，（英文混じりの）日本語を表現する場合，そのデータ長はUTF-8/16/32 に比べて短くなる。コンピュータを取り巻く通信環境は高速になり，ストレージは大容量化してきたとはいえ，データ長は短いに越したことはない。シフト JISでもデータ長は文字数に比例しないが，必ず英数字は1バイト，日本語文字は2バイトになる。Unicodeエンコーディングよりも良さそうだが，シフトJISの問題は表現できない文字が存在することだ。裏を返せば，「シフトJISで表現できない文字を使わない」ようにすれば良いのだが，それでは進歩がない。日本語文字列を扱うのに，何か良いエンコーディングはないだろうか。
「短いに越したことはない」というごく弱い理由で、さらに別のエンコーディングの必要性をほのめかさないでいただきたい。ただでさえ日本語を扱えるエンコーディングの乱立に迷惑しているのに(日本語だけで４種類なんて異常だ)。もう、新しいデータはUTF-8でいいよ。
以前、「英語ではしりとりできないなあ」と思ったことがあるが、 Homophone Gameはおそらく英語でしりとりに相当するゲーム。
具体的には、同じ(似た)音の単語二つを含む文を交代に思いつく限り並べるというもの。
とか。うーん、やっぱりしりとりの方が面白そうだなあ。
やまぐちでも山口情報産業協会を中心にOSS協議会が設立されるということで、 その発足セミナー講師として井上社長とともに山口入り。 時間の関係で、松江→米子→岡山→新山口。
セミナーの内容は、最初にアシスト社長、ビル・トッテン氏の 特別講演以外は先日の福岡のものとほぼ同じ。 演者も、IPA OSSセンター長、田代さん、 NaCl社長(しまねOSS協議会会長)井上さん、 私。ただし、時間はちょっとずつ短かった。
ビル・トッテンさんの講演内容はそのまんま「不都合な真実」であった。 彼は飛行機に乗らないそうだ。 でも、環境の視点からこれから田舎の重要性が増すという意見は興味深かった。 現在都市に人口が集中しているのは高エネルギー消費を前提にしているからで、 数年後、(自発的または強制的に)エネルギーを消費できなくなったら 田舎に中心が移動するので、今から田舎(たとえば山口)に投資するのだそうだ。
ふーむ。
その後、懇親会など。
楽しかったが、 山口の企業が今後OSSとどう付き合っていくか、 せっかく発足したOSS協議会がどう活かされるか、 今後の課題も大きいように思えた。
テーマは「電子メール」。〆切は昨日なのだが、 どうにも終わらなかった。毎月、見積もりが甘すぎ。
で、今月は、プロトコル(SMTP, POP, IMAPなど)の解説と Rubyで記述されたメール関連ソフトウェアの紹介に終始してしまい、 コードが全然無かった。来月はもうちょっと実践的な記事にしたいなあ。
「ワールドビジネスサテライト」の取材。
Rubyの、ということではなく、「クラウドソーシング」について オープンソース経験者という視点から聞きたかったらしい。
が、そもそもクラウドソーシングなんて言葉を知らない私は 聞かれてからあわてて検索したりして。 役に立つんだか、立たないんだか。
で、あわてて調べたクラウドソーシングについては、 一時「オープンソースにすれば「コミュニティ」が手伝ってくれてどんどん発展する」と 「誤解」されていたのと、同じ臭いを感じるが気のせいだろうか。
一応、インセンティブが重要というコメントを付けておいたが、 最終的にどういう扱いになるんだか不安なものである。
あちこちでRuby(MRI)のGCについてけなされている。
まあ、たくさんのリソースをかけているJVMのGCに勝つのは 最初から無理な相談なんだが、とはいえ問題があるのであれば 改善したいのが技術者魂というものだ。
指摘されているRuby GCの「課題」は以下のようなものがある。
具体的に問題が生じているものもあれば 理論的可能性のものもあるが、まあ、問題がないとは言わない。
それぞれについて、もう少し解説した上で、 考えられる対策についても述べよう。
プログラムの実行時間全体の中で、 GCで消費される時間の比をスループットと呼ぶ。 これはGC全体の性能を意味する。
これを根本的に削減する方法はあまりないのだが、 世代別GCが有効だといわれている。
問題は世代別GCを正しく実装するためには 古い世代から新しい世代への参照を検出する必要があり、 そのためにはオブジェクトの書き換えをフックする「ライトバリアー(write barrier)」を 導入しなければならないこと。
以前のRubyに対して世代別GCを実装した結果では、 このライトバリアーのコストが高くて結果的に性能が低下してしまった。
とはいえ、現在の実装でスループットが悪くて使えないというケースは ほとんど聞いたことがないので、それほど強い動機づけはないかもしれない。
通常の実装ではGC中には他の作業を行うことができないので、 リアルタイム性の高い処理中にGCが発生すると 処理が引っかかったような印象を与えることがある。 ここで重要になるのが「停止時間」である。
停止時間には「平均停止時間」と「最大停止時間」があり、 応答性に重要なのは最大停止時間の方。 またハードリアルタイム領域では、ただ単に短いだけでなく 予想可能である(たとえば最大100msで終了するとか)であることが 重要である、らしい。
世代別GCではスキャンするオブジェクトが減るため、 平均停止時間は減少するが、フルGCにはそれなりにコストがかかるため 最大停止時間は減少しない。
とはいえ、リアルタイム性が必要な領域でRubyを使うというケースは (まだ)あまり多くないので、停止時間が問題になることもそんなにないような気がする。
もし本当に問題になることがあるならば、 まずは現在のGCのままスイープフェーズをオンデマンドで行うことで、 GC時間をマーク時間だけに限定でき、停止時間を削減できる。
これは良く指摘されるのだが、 Rubyは保守的GCを使っているので、 本当は参照されていないはずのオブジェクトが参照されていると見なされて いつまでも解放されない(ので結果的にメモリリークになる)ことが ときどき観測されるのだという。
これは確かに私も見たことがある。 個人的には問題だったことはないけど、 サーバープロセスのような長期間生きるプログラムだと 問題になるかもしれない。
で、そういう問題が起きた時の状態をデバッガで観測した経験からいうと Rubyにおけるリークは保守的GC固有の問題(整数値がアドレスと区別できないのでとりあえず生きていると見なす)というよりも、 Cスタックに参照が残っていて生きていると見なされているようだ。 スタック先頭からスタックボトムまで全領域をルートとして 扱っているのが「無駄な参照」を検出してしまう大きな理由なのだろう。
スキャンするCスタックを減らせばよいのだろうが、 スタックの構造はCPUやOSに依存するので、 移植性が下がることになりかねない。
悩ましい。
可能性としては
がある。時間が取れれば考えてみる価値はありそう。
メモリリークとは別に長時間動き続けるRubyプロセスは肥大化する可能性がある。 これはRubyのメモリアロケータがオブジェクトのための領域をmallocする一方で なかなかfreeしないからである。
現状ではオブジェクトのためにheapと呼ばれる領域を割り当てているが ヒープに存在するオブジェクトがすべて解放された時だけ heap領域をfreeしている。 が、Ruby GCはオブジェクトの移動を行わないため、 現在の割り当て方針ではheapがfreeされる可能性はかなり低い。
現在、10000オブジェクト(2回目以降は前回のサイズの1.8倍)ぶん割り当ててるheapのサイズを もっと小さくすればfreeされるチャンスは増す。 もっともあまりfreeされすぎてもmallocとfreeの輻輳が起きて 効率が悪くなってしまうだろうけど。
あと、heapサイズを小さくすると保守的GCの使うオブジェクト判定のコストが上がってしまう 可能性がある。最近、trunkでオブジェクト判定にbsearchを導入したのは このheapサイズ縮小のための伏線である。
マーク・アンド・スイープGCでは、オブジェクトが生きているかどうかを判定するために 各オブジェクトごとにマークビットを設定している。 現状ではこのマークビットはオブジェクト内部に用意されているのだが、 考えてみるとGCごとにすべてのオブジェクトが(少なくとも1ビットは)書き換えられていることを 意味する。
これはUNIX系OSが備えているCopy-on-writeとすこぶる相性が悪い。 せっかく変更されないデータはプロセス間で共有しようとしているのに、 GCが起きるとオブジェクト領域が全部コピーされてしまう。
これだはfork(子プロセス生成)を多用するプログラムの効率が低下してしまう。 で、これについてはパッチを用意したのだが、 heapサイズ削減と相性が悪いし、それでなくてもGC性能が低下しそうである。 どうしたもんだか。
あと、そろそろ発売される日経Linux 4月号でもGCについて解説している。