«前の日(02-02) 最新 次の日(02-04)» 追記

Matzにっき


2004-02-03 節分

_ [Ruby]VMの高速化手法

いつまでたってもRite VMの開発に取り掛かれないし、 そうこうしているうちに笹田さんがyarv(yunoだっけ?)を始めちゃったりしてるので、 今までサーベイしたことをメモしておこう。

Rubyのような型情報が一切なく、最適化が行いにくい言語のための仮想機械で有効そうなテクニックは以下の通り(全部ではない)。

  • word code(バイト単位ではなくそのマシンでもっとも扱いやすいサイズの整数で命令を表現する)
  • indirect branch(GCCの拡張機能を使いアドレスに直接ジャンプする)
  • branch prefetch(メモリからアドレスをloadするのに時間がかかるので、先にレジスタにフェッチしておく。パイプラインが短かったりレジスタ数がタイトな場合には効果がないかも)。
  • super operator(頻繁に連続して登場する複数の命令を融合して新しい命令を作る)

基本的なアイディアは、仮想機械の実行のうち、 もっとも多く時間を消費するのは、命令のフェッチとジャンプであるので、 ここを改善しようというもの。ソフトウェアによる仮想機械ではCISCな発想が良いみたい。 yarvはこれらの多くをすでに実現している。

これらでVM部分の実行時間が半分以下くらいになるんじゃないかと期待している。

後、残りは

  • メソッド検索の高速化
  • メソッド呼び出しの高速化

だが、これはなかなか良いアイディアがない。

メソッドキャッシュの高速化について考えると、 現在のメソッドキャッシュはなかなか効率的ではあるが、 グローバルなテーブルルックアップなのがスレッドには嬉しくない。 とはいえ、インラインメソッドキャッシュはなかなか難しいし。

メソッド呼び出しの方はスタックのデザインで少し変わるかも。 vmgenのサンプルにあるminiとかが参考になるかもしれない*1。 それと、演算子呼び出しなどで、条件が成立している時には、 直接計算してしまうことでメソッド呼び出しを削減できる。 lightningのようなものによる JITも考えられるけど、移植性を犠牲にする割にどれだけ嬉しいかは検討しないとな。

JITに限らずVMの高速化は面白いテーマではあるが、 所詮スクリプト言語なので報われるかどうかわからない分野である。

*1  もっともminiが速いのはチェックがないからかも

_ [METI]ハッカー甲子園(2)

明日は経済産業省による「高度IT人材早期発掘のあり方検討会」の第二回である。

しかし、はっきり言って私には画期的なアイディアはないのだよなあ。

  • IT分野にとんがった人材を早いうちから発見する
  • かつ世に数多くあるプログラミングコンテストに埋没しない
  • プレゼンスを獲得するため世の注目を集められる

ような企画ってのはどんなものがあるのか。 「未踏ユース」でいいじゃんって思いも一部あったりする。

[]

2005-02-03

_ おわび

先日来のアクセス増加のため(スラッシュドットの影響が大きいらしい)、 昼休みや深夜などには負荷が高くこの「にっき」をはじめ boron.rubyist.net 上のたくさんのページが閲覧できないことがあったようだ。

調べたら日に何度もロードアベレージが30とかになっている。まあ、boronはもともとかずひこくんのマシンだったものをrubyist.netやmodruby.netなどが間借りしているのだが、 どうもマシンパワーが不足しているようだ。先日、全面的にmod_ruby化を行ったりしているのだが、焼け石に水らしい。

マシンリプレースが必要か。しかし、原資はどこから?

_ [特許] 一太郎の敗訴 自由な開発環境の整備も必要

ソフトウェア特許の危険性について触れた社説。こういう「一般向け文書」はありがたい。

_ デブサミ2005 (1日目)

朝、道が凍結していたが、心配したほどではなく、無事に飛行機で東京に。 そのまま表参道の青山ダイアモンドホールへ。

参加したセッションは以下の通り。

  • XP事例カタログ

    「dRubyの方から来ました」の咳さんをはじめとしたXP実践の事例紹介。 「忍者式テスト」とか「スタンダップミーティング」とか、実際にうまくやっている例は参考になる。 もっとも、私はうちのチームで一番XPを実践していないので、 他のチームメンバーには常識なのかもしれない。

  • Web-DBシステムチューニングの方法

    割とフツーのDBチューニング。私はDBに関しては素人以下なのだが、 みなさん、日々こんな苦労をしているのね。

  • 軽量Javaへの潮流

    「Struts + Spring + JSP」でJ2EE5.0を先取りって話。 「新しい技術で楽ができる」ことが強調されるが、 それはつまり「今のJava技術者」がめちゃめちゃ苦労していることを意味するような気がする。 これらがオープンソースソフトウェアであるのは確かだが、 この内容は「オープンソース」トラックではないような。

  • なぜ「オープンソース」でうまくいくのか(前編)

    副題が『オープンソース的開発手法の秘密をさぐる』。 Linuxの開発体制をベースに「オープンソース的開発手法」 あるいは「バザール手法」について解説。 私(とその周辺)には物足りなかったけど、 今日の聴衆の大半にはちょうどいいレベルだったのかも。 ビジネス的な話はあえて避けたみたい。

    聴衆における「スーツ族」の割合がめっぽう高いのも印象的だった。

  • なぜ「オープンソース」でうまくいくのか(後編)

    後半。副題は『まつもとゆきひろが語る「オープンソース的開発手法の現実」』。 後半になるとスーツ族とギーク族の割合が変化しているような気が。

    風穴さんが質問して、私がそれに答えるというスタイル。 私のバックグラウンドやらRubyの開発動機やら開発体制やら。 風穴さんの意向でオープンソースの思想やらビジネスやらの話は避けて、 開発スタイルや開発者の気持ちなどにフォーカス。 当たり前だが私にとってはなにも新しい話ではないので(みんなどこかで話したような気がするし)、 これを聞いた人たちがどう思ったのかはよくわからない。 私の周辺にいる人たちにとっては新規性は無かったみたいだし。

    最後の質疑応答でややビジネス的な話が。うち(netlab.jp)が差別化にオープンソースを使っている話を紹介した。あと、時節柄、特許の話が。それに対する答えは

    • オープンソース開発者は個人だったり零細だったりすることが多いので事前に特許検索とかしていることは期待できない。よって、特許侵害の可能性が高いように思えるかもしれない。
    • しかし、月間2万件(情報分野のみ)も申請される特許から自分の開発しているものに重複する特許を発見することは専門家でもほぼ不可能だ。
    • 現実にIBMやマイクロソフトのようなしっかりした法務を持つ会社でも特許訴訟の対象になっている。いや、むしろそういう会社の方が標的になっている(お金を持っているから)
    • よって、オープンソースが特に危険ということはない。
    • もっともソースを公開しているからばれやすいということはあるかもしれない。 逆にお金を持っていないから訴訟の対象になりにくいということもあるかも。

    結局、ソフトウェア特許はオープンソースに対する脅威というよりは、 ソフトウェア産業全体に対する脅威だと思う。良い機会なのでもっと議論を深めるべきだ。

その後、有志と表参道(から渋谷方面にちょっと移動した)インド料理店で食事。

参加者は、(私の席から時計まわりに)Shelacyさん、 naruseさん、かずひこくん、tellmeさん、 えとーさん、風穴さん、くろももさん(名前、間違ってないよね)。

今回はRuby関連の集まりとしてはありえない男女比であったような気がする。

えー、個人的にはおなかが空いていたのでがつがつ食べることばかりで(カレーおいしかった)、 あまりお話できなかった人もいましたが、私は楽しかったです。

参加表明してたのに、来れなかった人は残念でした。またの機会に。

本日のツッコミ(全5件) [ツッコミを入れる]

_ えとー [うーん、Opteron Dual で Mem4GB 、RAID5 くらいは欲しいですよねぇ。どなたか、寄贈とかあれば..]

_ うえだ [うちのバナーを半年〜一年くらい張っていただけるなら、少し協賛できそうですがいかがでしょうか :-)。 http:/..]

_ Skirnir [昨日セッションの後に質問させて頂いたものです。以前から一度お話ししてみたいと思っていた夢がかないました。どうもありが..]

_ 斎藤ただし [日本Rubyの会などで、寄付の枠組みとかがあるといいんじゃないでしょうか。将来自分も収入が安定すれば、微力ながら資金..]

_ たかはし@日本Rubyの会 [寄付については以前からの課題になっています。近くはないけど遠くもない将来にはなんとかしたいです。]

[]

2006-02-03

_ [Ruby] ruby_class削減

メソッド定義の対象となるクラスを指すruby_classと、定数参照の対象となるクラスを 指すruby_cbase(その実態はruby_cref)は、非常に似通っている。というか、このふたつ って本来は統一した方がわかりやすいんじゃないだろうか。きっとユーザーもそれを期 待してると思うし。

ということで、統一する。今回はruby_classを全削除して、 ruby_cbaseに置き換えるこ とにする。

で、思い立ったら30分で作業が終了してしまった。今まで10年以上これらスタック と格闘してきたのは一体なんだったんだろう。

というわけで、1.9ではスタックを3本削減。残るは以下の5本。

  • prot_tag
  • ruby_frame
  • ruby_scope
  • ruby_cref
  • ruby_dyna_vars

これらも手を入れる余地はありそうな気がする。たとえばprot_tagを一つ一つジャンプ しながらチェーンするのではなく、目的の場所までいっきにジャンプするとか。 ruby_dyna_varsをリンクではなく各レベルごとの配列にするとか。

_ [OSS] Rastが遅いわけ

昨日の高速化パッチは高速なんだけど、どうやらN-GramのインデックスになっているBDBの更新に問題があるようで、検索結果に大きな漏れがある。morqのようなタイプのメールリーダーでは検索以外にメールに到達する方法が無いので、漏れは致命的だ。

しばらくソースを眺めてみたが、かなり大規模な修正で、どこに問題があるのか発見することはできなかった。

しかたがない。このパッチは当面断念しよう。

で、パッチを当てる前のRastのソースを眺めてみる。とりあえず遅いのはsyncする部分のようなので、そのへんを重点的に。

まず、明示的なfflush(3)とBDBのsyncはおそらく不要なので外すことにする。 stdioの方はfseek(3)を呼んでいるのでそのタイミングでflushされているはずだし、 BDBの方も明示的にsyncする理由はなさそうだ。BDB自身に任せた方が賢いsyncをしてくれるだろう。

次にソースをよく読むと、データファイルの書き出しで、各N-Gramごとに fseek+fread+fwriteを繰り返している。

デバッガで実行してみると、 syncの遅さはどうやらここに由来しているようだ。プロファイラまで動かせると確実なんだが、 Rubyで書いてあるmorqからRast部分だけのプロファイルを取る良い方法を知らないのだ。

というわけで、できればここをページ単位での書き出しにしたいところ。

だが、なかなか良いアイディアが思いつかない。

いっそ、現在の「BDBによるインデックス+データファイル」という構成から「全部QDBM」にしてしまうってのはどうだろうか(QDBMS好き)。

Curiaを使えば、データ容量の問題もさほどではなさそうに思うし、素朴に要素ごとにfeek+read+writeするよりは、 (ページングしてるから)速度的にも、(圧縮してるから)容量的にも有利だと思うんだけど。

でも、確かRast設計段階でこのアイディアはボツにされたんだよな。ま、単なる「上司の思いつき」だったので、その時は強くは出なかったんだけど。自分が作業するわけじゃないから、当事者の意見の方が重要だしね。

でも、担当者が忙しい今のうちに、こっそり試してみるか*1

はっ、...もう2月か。原稿の〆切が近づいているぞ。もうちょっと先まで我慢したほう がよいか。

追記:

後でQDBMのソースを読んだら、DepotやCuriaはデータ圧縮してなかった。容量的な利点 は無いようだ。

*1  ここに書いたら全然「こっそり」じゃないなあ

_ 英会話

教会の宣教師による英会話を手伝ってくる。

今日は「英語によるスキット」。我々の班(6名)は、即興で「三匹の子豚」を演じたの だった。急だったわりには全員ノリノリだったという。

確かに結構楽しかった。

_

降ってきたよ。7時前に帰宅したときには降ってなかったのに、 7時10分に英会話に出発 しようとしたら、わずか20分ほどで地面が真っ白になっていた。

明日の温泉は大丈夫かな。寒い方が風情が出るけど。

そして、明日こそは安来苑の温泉に入ろう。古くからインターネット接続完備の温泉旅 館として(知る人には)知られている安来苑では過去数回宴会を行っているのだが、私は いずれもハックに熱中していて、温泉に入りそこねているのだ。

明日こそは。明日の「Ruby温泉ミーティング」こそは。

_ コンピュータは難しすぎて使えない

今日になってからFirefoxを始めとするいろいろなプログラムが起動に失敗して coredumpするようになる。どうもフォントに問題があるらしい、と気がつくまでずいぶんかかった。

strace付きでFirefoxを起動して、フォントファイルの読み込みあたりで落ちていることでようやくわかった。その後、fc-cacheも落ちるので、これもstrace付きで実行させ、原因がttf-arabeyesというTrueTypeフォントであることを突き止めた。

そういえば何日か前にdselectでチェックを入れたような気がする。

もともと不要だったので、さくっと削除。やっと通常通りに動作するようになった。しかし、こんな問題が起きるようでは、まだまだ「コンピュータは難しすぎて使えない」ものだよなあ。普通の人がこんな問題に直面したら、対処しようがないじゃん。

答え: 「普通の人」はDebianを使いません。

ま、それは冗談としても。うちの妻のマシン(OSS貢献者賞でもらった日立のPrius)は、ネットワークが接続しているのに、「サーバーが見当たりません」というエラーをしばしば出す。どうやら、DNSがおかしいように思うのだが、ネットワークの仕組みはわかっていても、 Windows XPの仕組みがわからないので直しようがない。ネットワークの「修復」を行うと再接続をして、一時的には状況は改善するのだが、すぐに再発してしまう。

Debianでそんな問題起きたことがない(あるいは問題と意識する前に復旧できる)んだけどなあ。

本日のツッコミ(全9件) [ツッコミを入れる]

_ ささだ [えーと、結局文法変わっちゃったんでしょうか。]

_ まつもと [「文法」は変わってませんね。parse.yには手を入れてないから。 あ、ruby_blockを消したときにNODE_..]

_ mikio [DepotもCuriaもページ管理はせずに、個々のレコードの読み書きでlseek+read/readする方式です。 ..]

_ 通りすがり [似たような事が以前あり、最近もありました。 ~/.fonts.cache-1/ を消してログインし直したら戻りました..]

_ Ono [Priusのネットワーク関係のエラーは、単純にハードウェアの 故障じゃないでしょうか。 PriusのLANアダプタの..]

_ うすあじ [はじめまして。 ネットワークのトラブルはケーブルの接触不良の様な気もします。 ツメが折れているケーブルなどではこんな..]

_ まつもと [それが無線LANなんですよねえ。電子レンジも関係なさそうです。 さほど近くもない隣家で使ってるのが影響するとかありえ..]

_ Ono [接続ポイントの設定をしていないと、近所のアクセス制限皆無な アクセスポイント(往々にしてYahoo!BB)に優先的に..]

_ chaki [Xのフォントの件は、 単にXの設計が古くて - 問題の発生場所の確認が難しいのと  (これはWindowsもそうか)..]

[]

2007-02-03

_ [Ruby] RailsConf 2007 May 17, 2007 - May 20, 2007 Portland, Oregon

とうとう申し込みオープン。今年はいったいどれくらいでチケットが売り切れるか。

まず今年の会場は(OSCONの会場でもあるくらいだから)バカ広い。 さらに受け入れ人数も昨年の倍を予定している(ということは800越えか?)らしい。 となると、3日で売り切れた昨年よりはマシであることが期待できる。

とはいえ、Railsの話題性を考えると楽観はできないな。

「行きたい」と叫んでいた後輩のKくんはすでに申し込みをすませたらしい。 仕事の調整はつくのかな。費用は会社負担にしたげるから。

_ 仕事中に口笛を吹いて、コンピューターにコマンドを実行させる

音声インタフェースはうるさいので実用は難しい気はするけど(「はどそ〜んっ」)、 一度遊んでみたい気はする。

まわりに誰も居ないところで。

_ [教会] 掃除→食事

何週間かぶりの教会の掃除当番。当初は私一人でやるつもりだったが、 「夕食、外食にして、ついでについていくよ」と家族総出になった。

掃除機かけて、イス並べて、ゴミ片づけて。 いや、人数が多いと仕事が早い。 助かった。

その後、サティで食事と買い物。 末娘が食べるのが超遅いので、 私と末娘だけ置いていかれた。

「口、からっぽになった?」
「あーん(まだ入ってる)」

を何度繰り返したことか。

女性陣はチョコレートと、洋服。息子は靴を買ってもらったほかは本屋へ。

私は子守り。

[]

2008-02-03

_ [教会] 末娘の成長

先々週まで「お母さんといっしょでないとプライマリーのクラスに出ない」と 駄々をこねていた娘は、先週からひとりでクラスに出れるようになった。 ちょっとした動機づけと、それによる「良い行動」をさんざんほめてやったのが 原因のようだ。ポジティブフィードバックが効いた、ということでもあるが、 いずれにせよ、聞き分けのある態度を見せるだけ成長してくれたのがうれしい。

「親にとって都合が良い」ことを喜んでる側面もないではないな。

_ [教会] ゴードン・B・ヒンクレー葬儀および埋葬

先週、教会の大管長であるゴードン・B・ヒンクレーが亡くなったので、 彼の葬儀および埋葬が執り行われた。 その様子は衛星放送で中継された。

彼の生涯のダイジェストも放送されたが、 立派な人をなくしたのだと惜しむ気持ちが強かった。 もっともすでに97歳にもなっておられたので、 これ以上激務を背負わせるのはいかがなものかとも思ってはいたのだが。

いくつかのことを改めて気付かされた時間であった。

本日のツッコミ(全1件) [ツッコミを入れる]

_ 弟2 [大館長→大管長の間違い。 先週風邪引いて休んだからここで初めて知った・・・。ショック。次誰になるんだろ?]

[]

«前の日(02-02) 最新 次の日(02-04)» 追記

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.