2006年06月30日
Core 2 Duo
Conroe、Merom、Yonah、FX、X2、Turionなど全30種類のCPUベンチ
パイ焼き爆速でConroeは速いと聞いているけど、こうやって比較するとそのダントツさが際だつなぁ。
Yonah買おうかと思ってたけど64bitに対応していないしマザーが高かったりで見送り。
MeromはCPU単体で売ってくれるんかな。
Meromで自作PC作れたら開発機はMeromでファンレス、ゲームマシンはConroeで爆速って感じにしたい。
あと意外にTurionが速かった。
TurionはCPUファンレスが実現できるのでイイかも。
まぁMerom出るまでの命だけど。
MeromはTDP 0.5Wの超低電圧版も出るという話だけど恐ろしいな。0.5Wって・・・。
ヒートシンクレスもできるんじゃないか？
Conroeの発売は7月末というコトで8月に新しいマシン買うことにしよう。
Yonahでは特定のマザーで酷い不安定さだったらしいので一応その辺様子見と言うことで。
Dellのモニタの件でもそうだったけど初物に飛びつくといろいろ大変なこと多いしなぁ。
2006年06月29日
Vista
Microsoft、WinFSの開発中止を表明
やっぱり OS 開発はネイティブコード?
次期WindowsのVistaで実装予定だった機能というか新要素がどんどん無くなっていく気がするな・・・。
詳しい話は知らないけど記事を読む限りWinFSは、今までメールソフトならメールソフト、エディタならエディタで別々に検索用インデックスを持っていたのを、OSが提供するインデックスに統一しましょと言うモノらしい。さらに一つの項目を変更するとそれを参照している別のアプリ側でも変更が有効だという。う～ん、すごい便利な気がするけど実装間に合わなかったんかなぁ。
VistaではOS自体にマネージドコードが使われるという話も結局無くて、マネージドなプログラムはOS全体の1%らしいし。きれいなUIのAeroはグラフィックカードのメモリが512M無いとまともに動かないとか書かれてたし大丈夫なのかVista。
普通に使うぶんにはVistaイラネ、っていうか2000で十分って話になるよなぁ。
まぁ新しもの好きだから発売されたら買うが。
Windowsが足踏みしてる間にLinuxががんばってくれたらうれしいがどうなることやら。
2006年06月27日
初同人誌
友達にデスノートを貸していたんだけど、それを返してもらうときにデスノートの同人誌を貸してもらった。表紙はデスノコミック版のようにサラサラの紙で、タイトルが金色でピカピカしててすごい気合い入ってる。絵も似てるしうまいなぁと思いながら、俺にとっての初同人誌を読んでみる。
内容はと言うと、Lが月に執着するのはなぜか。それはLが月に一目惚れしていたから。
・・・・ってBLモノじゃねーかっ！！
と言っても18禁じゃないので、ガチエロホモシーンは無く結構面白かった。
最後のコマだけは二人がからみ合ってて（´д｀;） うへぇと思ったが・・・。
一目惚れは冗談としても、話の序盤でこれと言って理由もないのにLが月にこだわるのはなんか違和感あるな。話の都合上、月が完璧に殺人を行いつつ、Lが月に興味を持たないと話が進まないので仕方ないんだろうけど。
それともやっぱりLは月に一目惚れしてウホッなんだろうかｗ
やばい、そのようにしか見えなくなるｗ
貸してもらった友達に聞くと、死神のリューク×月とかも普通にあるらしい。
死神は萌えるのか？まぁ確かにリュークは外見怖いけどかわいいところあるしな・・・。
参考:Googleイメージ リューク
男には知らなくていい世界があり、またその世界の底は深そうだった・・・。
2006年06月22日
わくわく
仕事をしていると、突然部屋の照明が切れた。
あれ？と思うと同時に、足下のUPS(無停電電源装置)がけたたましく警告音を鳴らし、電気が途絶えたことを叫ぶ。
おおおっ!?停電だっ!!
部屋のあちこち、部屋の外からもUPSの警告音の大合唱だ。
薄暗くなったフロアで、他の研究員の方も「何事だ」とばかりに外に出てきた。
暗いフロア、鳴り響く警告音、慌て走る人たち。
そんな非日常な風景はなんかわくわくした。
なんだか「総員!!第一種戦闘配置っ!!」などと叫びたくなるｗ
結局、原因はわからず数分後に復旧。どうやらうちの部屋の周辺だけ停電になったようだ。
誰かが大事なコンセントにつまずいたか、押してはいけないスイッチに触れてしまったんだろうか。
俺は、数分で終わった"敵襲"にﾂﾏﾝﾈと思いながら席に着き、仕事に戻るのであった・・・。
2006年06月21日
Javaでリモートデバッグ
プログラミングするときにデバッガでのデバッグは必須だ。
ログを出力して動作を確認するなどもできるが、やはりデバッガでステップ実行や条件一致のブレークポイントなどの方がデバッグしやすい。
しかし、サーバ上で動かしているプロセスに対するデバッグはログでのデバッグが中心になってしまい、面倒だ。
が、Javaだと別のマシン上で動いているプロセスに対してもデバッガでのデバッグが簡単にできて、とてもナイス。
この辺を参考にする
エクリプス リモートデバッグ
Eclipse Platformを使用したデバッグ
実行はとても簡単で、デバッグ対象のプログラム起動時にVM引数として
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
などを指定して、いつも通りに実行。
その後、デバッグするマシンでEclipseの「debug」から「Remote Java Application」を新規作成し、接続先を指定する。
ポートはaddressで指定した値を設定。
接続すると後はいつも通りのデバッガなのでステップ実行や変数の値の読み書きなどやりたい放題だ。
HotSwapも使えるので実行途中にソースを書き換えるなんて事もできる。
2006年06月16日
LinuxでHD吹っ飛んだときのために
Partition Rescue mini HOWTO
Linuxを使っていてパーティションがぶっ飛んだときの復旧方法など。
去年ぐらいから家のファイルサーバの400GのHDが吹っ飛んで使用不能になってたので復旧してみる。
と思ったがパーティションが吹っ飛んだのではなくファイルシステムの方でエラーになっているようで上のドキュメントでは復旧できなかった。
使用しているファイルシステム名+復旧とかでググってみるといろいろ復旧方法が出てくるけど、めんどくさいのでファイルシステムを作成し直した。どうせ保存されてたのは録画しっぱなしであんまり見ない番組ばっかだし。
後から調べてみると、結構読み込めなくなった状況からでも復旧できるのね。
家で使っているファイルシステム、ReiserFSだとファイルシステムのメタデータのバックアップが取れるようだ。
これをバックアップしておけばファイルシステムが飛んでも戻せるらしい。
もちろん実際のデータ部分が飛んだ箇所は戻らないだろうけど。
debugreiserfsでググるといろいろ情報が出てくる。
1.4Tのファイルシステムのメタデータをバックアップしてみた。
debugreiserfs -p /dev/vg/share | gzip -c > metadata.gz
のような感じで実行。
1.4Tあるのでさすがに時間がかかる。7時間ほどかかった。
圧縮された結果のメタデータは8Mほど。
思ったより小さい、これならバックアップも楽だ。
cronで毎週バックアップを取って別マシンに保存とかすると、万一の場合に役にたつかもしれない。
HD自体の不良ブロックのチェックは
e2fsck -c /dev/hda3
みたいにしてチェックができる。マウントしているファイルシステムだと警告が出るのでunmountしてから実行する。
2006年06月08日
WindowsでEmacsキーバインド
Emacsのキーバインドは、いちいち手を遠くに伸ばさなくてもいろいろ操作できるので、手元を見る必要がない。
EclipseではEmacs風キーバインドにして使っていたけど、補完候補を選択するときなどはWindowsのキーバインドになってしまう。
つまりカーソルキーで選択、エンターキーで決定だ。
が！コーディングしているときはEmacsで、補完の時や別のテキストエディタを使ってるときだけWindowsってのは混乱する。
と言うことでWindows全部をEmacs風キーバインドにする。
XKeymacsの出番だ。
これを使えばキーバインドを設定できないアプリでもEmacs風キーバインドになる。
カーソル移動、デリート関連、エンターキーをEmacs風にしてみた。
これで混乱無く使える。
作者様に感謝。
これを使うときはCapsキーもControlキーにしてしまえばもっと楽になる。
Controlキーを3つにする技はこのブログの過去ログにある。
と思ったらこのソフトでも自由にキー配置を換えることができるようだ。スバラシイ。
2006年06月06日
N-gramでインデックス
形態素でインデックス作ったのでN-gramでもやってみる。
ユニグラムだとインデックスサイズは原文の5倍。
バイグラムだと13倍。
トライグラムだと55倍。
(原文はEUC-JPなのでJava内部のUTF-8形式にするだけで1.5倍になっている)
ちゃんと圧縮を考えないとダメそうだ。
そもそもインデックスの配列としてArrayListを使っているので、これをintの配列にするだけでも結構減りそうだ。インデックスはしょっちゅう変更するものじゃないし、配列を作り直すコストはトレードオフってコトで。
ちなみにバイグラムにしたら「吾輩」でヒットする箇所が10カ所ぐらい増えた。
やっぱN-gramにした方が良いかもしれない。
2006年06月05日
パトリシアツリー
全文検索をするためにインデックスの作り方など勉強してみる。
んでパトリシアツリー(Patricia Tree)がイイ感じらしい。
なんだか情報が少ないので、完全に理解できているか不安だけど、簡単に言えば検索キーワードをビット配列とみてインデックスを作る感じ。
「検索」と言う単語で検索する場合、「01010010101・・・」と言ったビット配列として考え、その配列をそのままツリー構造にする。
コレにより理論上Googleサイズの膨大なデータでも速度が低下することなく全文検索が出来る。
と言うことで全文検索プログラムを書いてみた。
例により「吾輩は猫である」を検索してみる。
「吾輩」を全文検索すると全部で475カ所、検索に掛かった時間はわずか80マイクロ秒。0.08ミリ秒だ。スバラシイ。
そして理論上どんなに検索対象が大きくなっても検索に掛かる時間は変わらない。
書いてみてわかったけど、全文検索ってムズカシイかと思ったけど意外と簡単だったなぁ。
インデックス作成のプログラムも合わせて1時間ぐらいで書けたし、内容をきちっと理解して書き始めたら10分ぐらいで書けるかも。肝心の検索部分も再帰を使って10行ぐらいのプログラムで検索できてしまう。
このプログラムで一番悩んだのはビット演算の部分だｗ Javaプログラミングしてたらビットを直接いじるなんてこと無いからなぁ。
しかしこの方法も万能ではない。今回は形態素解析し、分かち書きの結果をインデックスにしたので、この検索方法では形態素単位の検索しかできない。つまり「吾輩」で1形態素なので「吾」の1文字で検索しても引っかからないのだ。まぁ前方一致に対応させるのは楽に出来そうだけど。
あとインデックスのサイズが結構大きい。
パトリシアツリーをシリアライズしてファイルに出力したところ、原文の約8倍ぐらいのサイズになった。
Javaの仮想マシンにロードされた状態ではもう少し大きくなるだろう。
32bitマシンの環境じゃ2Gぐらいしかメモリが使えないので、現状だと200Mぐらいのテキストしか検索できない。一応ビット列を圧縮したりしてインデックスのサイズを小さくできるようだけどそれでもやっぱり限界はある。
そういう場合はツリーを分割して、結果をマージするのがよさげだ。
リアルタイム性を重視するならJavaのRMI(リモートメソッド実行)で簡単に別マシンのメソッドを呼び出せるので、マシン毎にツリーを分割して検索すれば大きいコーパスでも一瞬で検索できそうだ。
研究所にはメモリが18Gと言うすごいランニングマシンもあったりするんだけどそのうちこれぐらいのモンスターマシンが普通になる時代が来るんだろうなぁ。
10Gぐらいメモリ使いたい！ってコトはなかなか無いけどとりあえず2Gの壁は何とかして欲しい。
ちょっと大きいテキスト扱うとすぐメモリ足りなくなるしなぁ。そもそもテキストのサイズが10Gを超えることが珍しくないし・・・。
まぁWindows Vistaから64bitになるし、64bit環境が普通になってきたら窮屈さも無くなるでしょう。
2006年06月04日
形態素解析器いろいろ
ブログの検索をすると言うことで、全文検索の手法などをいろいろ勉強中。
検索キーワードは名詞がほとんどなので、形態素解析し、内容語だけ取り出してインデックスを作ろうかと考えてる。
コレは限られた資源を節約と言うことで、N-gramよりはマシだろうと言う考えでこうなった。
形態素解析器はChaSen、JUMAN、MeCabの3つを候補に。
ChaSenは仕事でいつも使ってる使い慣れたツール。
みんな使ってるけど、更新履歴を見る限りもうツールのメンテナンスはされていないようだ。
JUMANは今でもガンガン更新されているツールで、代表表記を出力することが出来るので表記の揺れを吸収できる。
JUMANを作ってる黒橋先生は最近まで月一でミーティングしていて、その研究に対するパワフルな姿勢はいつも「見習わないとダメだなぁ」と思ってしまう。
MeCabは最近のツール。
速度、精度ともに良いらしい。デフォルトで品詞体系がChaSenと同じIPA品詞体系。
最近仕事先でChaSenからMeCabに乗り換えようという動きがある。もしかしたら今後MeCabが主流になるのかもしれない。いろいろカスタマイズしやすいというのが理由だそうだ。
とりあえず速度重視で3つのツールの速度を調べてみた。
解析データは青空文庫の吾輩は猫であるのテキスト版。768kb。
欲しいデータは分かち書きされた結果と品詞だけなので、表示するデータを減らせば解析速度が速くなるかもしれないけど、とりあえずデフォルトで計ってみた。Linuxのtimeコマンドで計ったので辞書のロード時間とかも含まれてる。
結果は速いものから
MeCab 1.1秒
ChaSen 1.3秒
JUMAN 1分53秒
だった。
JUMANがやけに遅いのが気になる。辞書サイズやら代表表記の有無やらで速度が変わるだろうけど、無難にココはMeCabでイイか。
そして分かち書きの結果でインデックスを作って・・・と思ったけど、いろいろ読むとどうやらN-gramでインデックス作ってしまうのが今時のやり方らしい。漏れが少ないからかな。
まぁどっちみち重要語でクラスタリングするには形態素解析しないとダメなので、形態素解析はMeCabで行こう。
2006年06月01日
ブログ検索エンジン
- kenji
- 21:01
- コメント (2)
- トラックバック (1)
- カテゴリー:Diary
なんだか急にブログ検索エンジンを作りたくなった。
と言っても、もちろん作る時間も根性もないので妄想して楽しんでるだけだけど。
世の中にはブログ専用の検索エンジンが大小いくつもあるけど、どれもたいていエントリーを対象にした全文検索的なモノばかりだ。(中にはYahooみたいなディレクトリ型な登録型検索サイトもあるけどこういうのは例外)
しかも割と最新記事を検索できるって事を売りにしているところが多い。
これはブログが日記的なものなので、検索対象の最新情報を速報的な形で記事にしているところを探したいという要求があるからと言うことかもしれない。
が、俺的にはそんな速報はググったり２ちゃんねるを見た方が早いので必要ない。
"ブログ"を検索するのだから、検索対象により多く言及しているブログがヒットして欲しい。
なぜ既存のブログ検索エンジンがダメかというと、ある事柄が話題に上るのが数週間から数ヶ月なのに対して、ブログのエントリーはその連続した情報の内の1日分しか情報を持たない。
そんな細切れの情報が検索されるのだったら最初からググった方が良い。
たとえば「YUKI」を検索すると、「YUKIの新曲買った」とか「TVでYUKIが出てて」とか「友達のYUKIちゃんが」とか出てくる。欲しいのはこんな結果じゃない。
欲しいのはYUKIのファンが過去にさかのぼってずっとYUKIについて書いてるブログだ。
つまり、検索結果のエントリーを表示した後、そのブログの「最新の日記から10件」とか表示したときに、検索対象について書いてある記事がいくつも出てきて欲しい。
なぜわざわざブログで検索するかというと、エントリーが読みたいわけではなく、ブログというメディアの向こう側にいる「検索対象に対して興味を持っている人物」を探したいわけだ。
そんなブログを見つけることができれば、きっと今後も検索対象についてエントリーを書いてくれるし、同じ興味を持つ人だからコメントにいろいろ書いてコミュニケーションをとれたりするだろう。つまりこれはハッピーだ。
で、問題はどうやってそんなエントリーを見つけるかと言うことだ。(ブログを探すのが最終目的だけど、入り口=直接の検索結果はやっぱりエントリー)
過去にずっと同じキーワードを書いてるって言うのは、エントリーに対する出現頻度ですぐ計算できそうだ。
でもこの場合は「友達のYUKIちゃん」や「書いてる本人がYUKIって名前」も上位に上がってくる。
こういうのを排除するには検索対象にどんな単語が共起しているかってのを調べれば解決しそう。
たとえばYUKIには「CD」とか「ライブ」とかそんな単語が共起しやすいだろう。
共起頻度が高かった単語を多く含むブログをクラスタリングして、そのクラスタの大きいモノほどスコアをあげれば「友達のYUKIちゃん」とかを排除できる。
さらに、検索結果一覧画面とかで、その「クラスタを表示する」とか言うリンクがあって、それを押したら同じジャンルのブログが一覧表示されたりするとさらに便利でハッピーかもしれない。
YouTubeで言う「Tags」みたいなモノをブログの記事から自動生成するような感じ。
今までブログ間のコミュニケーション手段がトラックバックだけだったけど、このエンジンでは書いてる内容によって勝手にクラスタリングされて、勝手に周りが同じ趣味の人ばっかりになると言う新しいコミュニケーションの手段になったりするかもしれない。
ちょっと想像しただけで楽しそうなモノができる予感がするけど、ホントに完成したらこれだけで何か商売ができるかもしれないな。
