メソッド定義の対象となるクラスを指すruby_classと、定数参照の対象となるクラスを 指すruby_cbase(その実態はruby_cref)は、非常に似通っている。というか、このふたつ って本来は統一した方がわかりやすいんじゃないだろうか。きっとユーザーもそれを期 待してると思うし。
ということで、統一する。今回はruby_classを全削除して、 ruby_cbaseに置き換えるこ とにする。
で、思い立ったら30分で作業が終了してしまった。今まで10年以上これらスタック と格闘してきたのは一体なんだったんだろう。
というわけで、1.9ではスタックを3本削減。残るは以下の5本。
これらも手を入れる余地はありそうな気がする。たとえばprot_tagを一つ一つジャンプ しながらチェーンするのではなく、目的の場所までいっきにジャンプするとか。 ruby_dyna_varsをリンクではなく各レベルごとの配列にするとか。
昨日の高速化パッチは高速なんだけど、どうやら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でそんな問題起きたことがない(あるいは問題と意識する前に復旧できる)んだけどなあ。
えーと、結局文法変わっちゃったんでしょうか。
「文法」は変わってませんね。parse.yには手を入れてないから。
あ、ruby_blockを消したときにNODE_POSTEXEだけ変えちゃったけど。
で、セマンティクスですが、make test-allが修正無しで動く程度には互換性があるようです。
DepotもCuriaもページ管理はせずに、個々のレコードの読み書きでlseek+read/readする方式です。
VillaとVistaではページ管理をしています。Hyper Estraierでは、Cabin(CBMAP)でキャッシュしたデータを、キーでソートしてから、一気にVillaに書き出すようにしています。ソートしてから書き出せば、B+木はハッシュ表より更新速度が出ます。しかもページングと圧縮のおかげで記憶効率は数倍になります。
似たような事が以前あり、最近もありました。
~/.fonts.cache-1/
を消してログインし直したら戻りました。
Priusのネットワーク関係のエラーは、単純にハードウェアの
故障じゃないでしょうか。
PriusのLANアダプタの部品が故障しかかっているか、Priusを
接続している先のモデムなりルーターなりハブのポートもしくはポートだけじゃなくて(IPアドレスを発行する)中のチップが以下略ではないかと思います。
WinXPの「ネットワークの修復」でどういうことをやっているかは
http://www.atmarkit.co.jp/fwin2k/win2ktips/355netrepair/netrepair.html
を見ればよろしいかと。
はじめまして。
ネットワークのトラブルはケーブルの接触不良の様な気もします。
ツメが折れているケーブルなどではこんな感じになった記憶があります。
無線LANなら、電子レンジを疑いますけど・・・
それが無線LANなんですよねえ。電子レンジも関係なさそうです。
さほど近くもない隣家で使ってるのが影響するとかありえるのかなあ。
接続ポイントの設定をしていないと、近所のアクセス制限皆無な
アクセスポイント(往々にしてYahoo!BB)に優先的に接続するように
なってしまい、接続ぶち切れで利用者もぶち切れというケースは
あります。
Xのフォントの件は、
単にXの設計が古くて
- 問題の発生場所の確認が難しいのと
(これはWindowsもそうか)
- 不適切なフォントデータやフォント選択を
事前に弾く安全策がとられていないから
じゃないかなぁ。
アプリ単位で落ちるだけまだマシな気がしますよ。
昔はXサーバ丸ごと落ちることも頻繁にあったような・・・(初期の*BSD時代)