« August 2004 | Main | October 2004 »

September 30, 2004

やばいやばいやばい

IBM講義休んでOCaml課題に全力を傾ける。休んで正解だった。なんか一日いろいろやったけど目に見える進歩がない…。

H氏に期待された置換表は、C++のクラス構造でそのまま書くとちょっとまずいことに気づき、あとまわしに。クローズドハッシュがよいとか思っていたが、逆に効率悪いような気がしてきた。クローズドハッシュだと、表が満杯に近くなってきたときに違うハッシュ値系列のものともたくさん比較を行わなければならない可能性が出てくる。簡単のため、単純にフルアソシアティブキャッシュとしてもいいかも。

置換表を放り投げて何をしていたかといえばかねてからやりたいと思っていた定石。座標を回転とかしてf5からの手に正規化する処理は例の本のコードを翻訳(笑)。問題は定石登録と探索部分だが、本のコードに評価値を加えないといけない。(本のコードは評価値を全て0とみなして単純化していた) そこで再び行き詰まってとりあえず後回し。そんなに難しい処理じゃないはずだからぜひ実装したいが。

そこである重大な事実に気づいたのだが、部品とテストコードは書いたが肝心のオセロアプリケーションが未着手だ。さすがにどんな形であれオセロゲームの形はしていないとまずいのでちゃちゃっと作ってしまおう。lablTkなどもちらちら眺めたが……とりあえずはコマンドライン版を出せるようにして、レポートを書いて、問題ない状態にしてからだな。

それにしても眠い。早起きしたというのもあるが、途中昼寝もしたし、なんだろう。なんか熱っぽい。風邪!?

あと22時間半。

| | Comments (0) | TrackBack (0)

September 28, 2004

ICPC国内予選解答

今年のICPC国内予選の解答なんてものが。

後日refineしたものとは言え、解答例のコードが美しい……そして短い!我々もSTL使いまくっているつもりだったがはるかに長かったぞ!?

でも C++ で書くのならこれぐらい STL 使わないと損ですよ。
とあるようにまだまだSTL使いこなせてないのだろうなぁ。開始前3時間にもSTLの新しい使い方を次々と発見していたくらいだしな。

Gokuri-Squeezeはやはり格が違った。

| | Comments (0) | TrackBack (0)

September 27, 2004

遅い…

昨夜は地下室に泊まってLiLF.*。「ここで終わらなければもう後はない」くらいの覚悟で臨んだ甲斐あってめでたく終了。もう二度とさわることもあるまい。

朝帰りしてちょっと寝た後はいよいよ締め切りが迫ってきたOCaml最終課題……が、やはり徹夜明けは何も出来ないと実感。頭がぼーっとしてるし何よりもやる気が出ない。

Move Orderingがあり得ないのは明らか(全階層で1手読みソート)だったので、上の方ではもっと深く読んだり、下の方ではMove Orderingをしないようにしたりしてみた。しかし思ったよりもパフォーマンスの問題は深刻そうだ。中盤はまあなんとかなる範囲だが、終盤がありえない。14手読み切りですら30秒くらい待たされる。中盤は少なくとも7手まで余裕で行けることを確認。学科ノートなら8手も余裕か。

Javaに移植したときにも思ったことだが、C++のコードはかなりインライン展開が効くことを想定してクラス分けしているので、それをそのまま他言語で実装すると大きなパフォーマンス上のロスが発生する可能性はある。あとはOCamlのオブジェクトがどのような機械語に落とされるのか理解していないので、もしかしたらオブジェクトに対して非常に効率の悪い操作をしているのかもしれない(←これを調べればもう一個課題ができるゾ)。

今日はもう眠いので、さっさと寝て明日続きをやろう。明日からIBMの集中講義。一応明日は様子見に行ってみるか。

パフォーマンス向上のためのドーピング策として、movable iterator導入、最終3手展開、最終1手着手せず、あたりをやってみるか。完全にC++版を追いかける展開となってきた。

ちなみに割とGUIは諦めムードで、それよりは速度を何とかする方に注力しようかと思う。コマンドラインのプログラムにするとしてもそれなりに優れたインターフェースにしたいので、Edaxでも研究しておくか。

レポートはそれなりに頑張って書きたいと思っている。評価関数実装の手法とか高速化のためのデータ構造とかいろいろ。どのくらいできるだろうか。

| | Comments (0) | TrackBack (0)

September 25, 2004

今日のOcamell

段々OCamlが好きになってきた。この「何でもあり」感がC++屋にとってはたまらない。関数や演算子のオーバーロードがあったら完璧だったのに。

ようやく探索ルーチンまで書けたので、性能を見てみる。といってもまだmove orderingがいい加減すぎて15手完全読みもできない状況なので、軽くチェックする程度。

6手読みの試合で20手目まで打つにのにかかった時間を計測。マシンはLinux作業環境であるThinkpad X23。CPUはPentiumIII-M/866MHz。

その結果、ocamlrun(バイトコード)において57.252sec、ocamlopt -unsafeで7.333sec。すごいぞocamlopt!ちなみに-unsafeを省いても7.5sec。ほげ。あれほど配列アクセスを多用する俺の実装でもこの程度の違いしかないのか。

目標は、「ocamloptでコンパイルし、学科ノートにおいて中盤9手読み+終盤18手読みがストレスなく行えること」。不可能ではないと思う。そして9手読めば人間には手出しできない領域に達せるはずだ。まずは計算量の削減から。move orderingをしっかりしよう。H氏は遅すぎて諦めたと言っていた置換表だが、俺の実装でもやはり遅いのか?試す価値はある。

| | Comments (0) | TrackBack (0)

September 24, 2004

バックアップ

「バックアップ取るのはあたりまえ」と日々主張しつつ実はあまりきちんとバックアップしてなかったりする俺であるが、やはりマーフィーの法則「きちんとバックアップしていればディスクは飛ばない/バックアップしていないディスクは飛ぶ」が怖いので、思い切ってきちんとしたバックアップ体制を構築しようかと思う。

以前ノートをメインに使っていた頃は主要なデータは全てノートにあり、ノート→デスクトップの向きでのバックアップ態勢を構築していたのだが、最近デスクトップがメインになってからというものバックアップ先がなくて困っていた。しかしながらノートに80GBものハードディスクをつけてみたものの容量の使い道がなくて困っている有様なので、逆向きのデスクトップ→ノートでバックアップを行うことにした。ノートにバックアップを取ることで、緊急時にもノートパソコンだけ持って逃げればよいということになる。

そこで問題となるのがバックアップ用ソフトなのであるが、これまで使っていたみやばっくがいつの間にかシェアウェア化されているので困った。とりあえずインストールするかと思ったらVBの特殊なランタイムが必要とか言われてげんなり。これだから(以下検閲削除

そういうわけでここを読んでいる皆さんはどんなバックアップツールをお使いでしょうか?ぜひコメント欄で紹介して下さい。

ちなみに俺はそれほど高機能なツールは求めてなくて、
・どのファイル/フォルダを指定・除外するか毎回指定しなくてよい(一度設定を作ったらあとはそれを呼び出してボタン一発で実行可能)
・2回目以降のバックアップでは追加・変更されたファイルのみコピーする
・ネットワーク上のフォルダにバックアップできる(UNC名によるパス指定ができる)
無料
・(OPTIONAL) 特殊なアーカイブにまとめて突っ込むのでなく、ファイルをそのままコピーする
あたりが条件かな。意外とWindows XP付属の「バックアップ」も使えるのか?ちょっと試してみよう。

Continue reading "バックアップ"

| | Comments (3) | TrackBack (0)

September 23, 2004

Ocaml本

OCamlの本がオンラインで読めるとは。てかInriaのトップニュースに出てるじゃん。何でこれまで気づかなかったんだろう。プログラミングスタイル(関数的 vs 手続き的)とか、興味深い話がいっぱい。

なんか有用なサンプルがいろいろ。BASIC interpreterだって。この辺読めばML最終課題ができちゃう?末永さんが「誰かMLでマインスイーパ作らん?」と言っていたけどそれもある

ついでになんとMinimax alpha-betaなんて項も。思わず反応してしまうな。

結論:もっと早く気づけばよかった。まあCPU実験でもOCamlを使う可能性は高いし、じっくり読むとするか。これだけの分量になるとさすがに紙の本で欲しいなぁ。注文してしまうか?と思ったらまだ本として出てるわけではないっぽい。日本語の本も出るといいなぁ。

| | Comments (0) | TrackBack (0)

英語

家庭教師していたら、「受験勉強で学んだことで今一番使ってるものはなんですか」と聞かれた。

とっさに「英語かな」と答えた。得意だった古文や漢文にはお目にかかる機会は全くないと言っていいし、物理も化学も家庭教師以外の場面で使ってないし。数学には苦しめられているがあまり使っているという実感はない。するとやっぱり英語だろうか。特にOCamlなんてやっていると「詳しくはマニュアル参照」と言われても英語マニュアルしかないわけだし(フランス語版もあるか)、強くするためには論文をくまなく読まないといけないとか。

まあコンピュータ業界の英語なんて簡単な文章だし単語はほとんど知っているし、読むだけなら何の苦労もいらない作業だから普段は特に気にも留めていなかったが、高校生から見ると「ものすごいこと」に見えるらしい。まあ今俺が毎日読んでいる英語よりも高校生が授業や試験で読んでる英文の方がはるかに難しそうだが。

しかしまあ読んだり聞いたりはできても話すのとなるとまた別なんだよなー。最近英語を読むことは多くても書いたり話したりという自分で英文を作る作業からは全く遠ざかっているので、英文構成能力は激しく落ちていそうだ。

| | Comments (2) | TrackBack (0)

試験終了

終了しました。いろんな意味で。

離散数学…先生の機嫌がよければ可、機嫌が悪ければ不可ってところか。微妙。
情報論理…俺が教官だったら、5億円くらい積まれてはじめて単位をやるかどうか考えるレベルだ。正直答案を提出するのが恥ずかしかったが(ry まあH先生が追試したくてたまらない雰囲気だったので受けましょう……「何度でも追試します」発言は本当!?


追試がある試験よりも、あと1週間以内に完成させて提出しないと即首が飛ぶ課題共の方がはるかにやばい。昨夜は寝ようとしたが課題が怖くて布団の中で冷や汗が出てきた。もはや1日でも無駄にしたら即死。

| | Comments (0) | TrackBack (0)

September 22, 2004

プライベートアドレス

192.168.0.1は私のアドレスです!

はぁ、というかなんというか。世の中ってすごい。

ところでこれって結構有名なネタなのかな?

| | Comments (0) | TrackBack (0)

September 21, 2004

メッセンジャーのステータス

メッセンジャーのステータスが「退席中」になってない奴はしょっちゅうパソコンいじってる奴=勉強に集中してない奴だろ!そうだな!

いや、俺のことだけど(´・ω・`)

パソコン切るとこれまた非常に気になって逆効果だったりするんだな…。

てか試験は10:15a.m.からだったような。さすがにそろそろ寝ないとまずい?なんかノートをめくるたび未知の単語が登場してきてもううんざりなんですが…。演習のプリントしか見てなかったら結構やばげな雰囲気!?

| | Comments (0) | TrackBack (0)

September 20, 2004

もうだめぽ

試験前ってなんか精神状態がやばいね。どうでもいいことばっかり思いつく。例えばこんなの。

優子さん…普通にいるな。
良子さん…普通にいる。てかいとこの名前だ。
可子さん…「カコ」という発音の方ならいらっしゃるがこういう字は当てない気がする。というかリンクなんか貼ってしまっていいのだろうかrefererで特定されてこんなバカなこと書いてるのが発覚し宮内庁のエージェントが今にもうわなにをするやめr
不可子さん…うわああああ

結論:よい成績を表す字は縁起がよいのでよく名前にも使われる。冷静に考えると自明だ……。

ノートを見返すとおもしろいね。字形を見るだけでどの程度眠かったかがすぐわかる。

追記)
やることが見つからないくらいならもう十分じゃないの?俺はというと、どうあがいてもやるべきことを残り時間でやりきれないことが自明と判明したのでやることがなくなった感があるが……。
結局勉強したのは線形計画法だけ!?しかも計算練習しただけだし(゚∀゚) 今井さんの過去問を試しに見てみたが不可 @ 99%という感じ。

58. 不可?? fujita.h loses 2 単位s

あぼん。まあ、全然眠くないのでもうちょっとあがくが。むしろ論理でもやる?

| | Comments (0) | TrackBack (0)

September 19, 2004

incremental index update

朝起きてアンテナをチェックすると毒電波が飛び込んでくるので困ったモノだ。俺も釣られて深く考察してしまうではないか。今日は勉強するはずだったのに。いや勉強するぞ。今日は考察するだけにとどめておこう。

俺のボード実装はこんな感じ。

MobilityTable[index]を見ると、flipable flip[8]とint movablesが見える。flipableとはstruct flipable {char lower; char upper};というもので、例えばflip[i]=={-2,3}だったら左に2つ、右に3つひっくり返せるということ。movablesはindexが指す辺に合計何カ所着手できるかを示す。これによってゲーム終了判定なんかが若干高速化される。

インデックスの更新であるが、俺は特にテーブルなんかは用意せずにどこが影響されるか、新しく置いた石及び返された石1つ1つについてその座標からその場で計算している。

問題となるのは斜め辺のインデックス。現在の実装は「mobilityに関係ないだろ」ってことでdiag3~diag8のインデックスしかおいてないのだが、こうなると斜めのインデックスを見るときにまず「現在の座標が関連する斜め辺が存在するか?(diag1やdiag2だったら斜め辺はいじらない)」をチェックしなければならず、引き算2回、分岐2回。あああ。

ということで、diag1とdiag2も常においといて更新していくようにすればいいのではないだろうか?これでパイプラインストールをかなり減らせるのでは?diag1って要は隅の石のことだから超ばかげてるけど。

能書きはいい、書けばわかる。いやその前に勉強ですね、ハイ。

| | Comments (0) | TrackBack (0)

コメント欄

このblogに関するお知らせです。

「どうせみんな捨てアドの1つくらい持っているだろう」と判断してコメント欄は全て記入必須、としていましたが、やはりspammerにアドレスを拾われる…という懸念もあると思うので、未記入による投稿も可能にしました。

あるいは、コメント欄にメールアドレスだけでなくURLも記入すると、そのURLが名前のリンク先として使われるようになり、メールアドレスは一切表に出なくなります。コメントの際に正しいメールアドレスを記入していただくと、コメントがつけられたことがメールで通知されるので見落としがなくなります。

ということで、可能であればコメントはメールアドレス・URL両方記入して下さると大変うれしいです。

| | Comments (0) | TrackBack (0)

今日のOcaml

あああ試験が目の前だってのになんもやってねーよー。誇張じゃなくて、本当に何もやってない。線形計画法と最小費用流にいたっては演習すら解いてないので正真正銘知識ゼロ。ゼロ知識証明。いや違う。もうだめかも。そればかりか某掲示板に某先輩が貼ったデスノートのコラに触発されてこんなページを読み始めたり、その先のコラ掲示板を読み始めて気がついたら全投稿に目を通していたりとか、救いようがない。あああ。

Messengerでそれぞれの状況を確認してみると、「2日ありゃ十分」といっていたO倉がフレッシュネスバーガー(!)算術とかやってるぞ!?ん、もしや論理に2日、離散に2日?まあ、もうどちらにせよ俺は手遅れだアヒャ(゚∀゚)

しかしながら課題が気になるので、今日も一日OCamlオセロ。Ocamellって名前はいまいち気に入らない。OTestとかどうよ?ちょっと恥ずかしいな。Othestは?うーん。

ボード実装は終わった。move/undo/passとgameover判定、それからincrementalなindex及び石数更新。これ重要。俺の実装は大部分の機能がボードに集中してるからあとは大したことないはず!空所表やらmovable_iteratorやらの高速化のための機構はあとまわし。

評価関数を書こうと思って気づいた。C++やJavaの感覚でいるととりあえずクラスを書いて、となってしまうが、OCamlには強力な高階関数がある。C++でよく書く「immutableな関数オブジェクト」ってのはOCamlではそのまま関数を作ってやればいいわけだ。いろんなパラメータなんかも関数の生成時に封じ込めてまとめて返してやればよい。これのことをclosureと呼ぶのか?そういうわけで、評価関数は board -> int の関数とすることにした。探索ルーチン(AI)はどうしよっかなぁ。

で、ファイル入出力ってどうすんの、と思ってライブラリを漁ったのだが、それらしいモジュールが見つからない。延々さまよったあげく、なんとPervasivesという、デフォルトでopenされているモジュールの中に定義されているらしい。というかおなじみの演算子とかも全部このモジュールのメンバだったのね……。

バイナリファイルからintを読んで来るには、input_binary_intを使う。いかなる環境においてもバイナリファイルをbig-endianとして扱うらしい。これは便利かも。しかしながら、このintってCでのintと等価なのかなぁ?OcamlのintはGCがチェックするビットが1ビット有るとかいう話を聞いたことがあるが…。

とまあ、こんな感じでいろいろ調べたりしながら書いていたら結局中盤評価関数を半分書くくらいのところまでしか進まなかった。一日を振り返ると萎える。さすがに明日・明後日は勉強するゾ!

| | Comments (1) | TrackBack (0)

今日のFFO

最終3手展開におけるゲーム終了判定をいじって若干高速化。12.8sec→12.266sec。最近こんなのばっかりだ。CPU換装前に換算すると15.3sec。「15秒切れたら諦めてもいいかな」とか思っていたのであとちょっとか。

あとは、中盤におけるOrderingHeight(H氏のdepth_MOに相当)は3がベストと信じていたのだが、4にしたら若干改善。中盤読みセルフプレイのテストが51sec→48secに。ホントに若干だけど。

22手とか23手読みでは事前探索の反復深化で5~10秒も使ったりしていてなんかもったいない感じ。この辺は評価関数の改善がきっと劇的に改善してくれる…はず。

| | Comments (0) | TrackBack (0)

September 18, 2004

訴えられちゃうゾ

これってホント?MicrosoftはOpenOfficeのユーザーや開発者を特許侵害で訴える権利を持っているらしい。開発者のみならずユーザーって何よ。

SunはMicrosoftと仲良しになったので、Microsoftが何をしようと関知しないらしい。SunのStarSuiteは別扱いだから別にいいらしい。まあ、「権利を持っていることを確認した」というだけで今すぐ何か動きを起こすと言うことではないようだけど。

うーん、そりゃまあOpenOfficeはMicrosoft Officeにとって目の上のたんこぶなのはわかるけどねぇ。機能の成熟ぶりといい、MS Officeの完璧なパクリっぷりといいw しかしこういうインターフェースとかってパクリパクられではないのかねぇ。

とりあえず俺は2003年頃からOpenOffice使ってるから大丈夫だろうか。いや2004年6月にノートPCを再構築した際に入れ直したな。ありゃ。まあいざというときには、東大がSunと契約していて学生は全員StarSuite7を無料で使えるのであるが、StarSuiteの方は非標準なフォントを勝手に入れてそれがデフォルトになってるだとか、バージョンアップが遅いだとか、あまり使いたくないんだよなぁ。Mozillaを使ってNetscapeを使わないのと同じ。

| | Comments (2) | TrackBack (0)

OCaml day

書くことはほとんどプログラミングのことなのでカテゴリ「プログラミング」というのはでかすぎるんじゃないかと思う今日このごろであるが、いまさらどうしようもない感が。blogを移転することがあったら考えよう。

今日は午前中ちょっとFFOをいじった他はずっとOcaml。断念しかけていた着手可能表がついに書けたので、あとはすんなり、のはずが結構記述量が多いぞ。

なんか配列を使いまくっているので、「コンパイルに通れば動く」とはいえない状況になってきた。困るのは配列のインデックスをはみだした場合で、index out of boundsと表示されて落ちるのはいいけどどこでそれが発生したのか知る手だてがない。デバッガにかけたらわかるのかなと思いつつもそんなこともなかった。例外はASSERTとは違うよな、そりゃ。結局原始的な手段で、コードブロックをちょっとずつコメントアウトしてみたりしながら発生部位を絞りこんで行く有り様。

色の表現については最初はC++版に忠実に、type color = intとしようと思ったのだが、これだとパターンマッチがきれいに書けないとかいろいろ問題があって悩んでいた。もうひとつの選択肢はH氏方式の type color = Black | Empty | White である。

松葉さんから以前「OCamlのパターンマッチはif分岐じゃなくてswitchみたいなテーブルジャンプで実装されるから効率もよい」みたいな話を聞いたのを思い出したので、整数定数でパターンマッチさせるのとコンストラクタパターンでマッチさせるのとではどっちがよいか実験。ocamlc -dinstrでOCamlバイトコードを覗く。すると、整数定数でのパターンマッチは普通に比較とbranchに落ちるが、コンストラクタパターンのマッチはswitch 3 4 5/とかいうあやしげな命令になっている。これが噂のテーブルジャンプ? intでのマッチはどんな値がくるか事前にわからないのにたいして、コンストラクタパターンの場合は型チェックによって
事前に出現しうる値を知ることができるため、簡単にテーブルジャンプにできるのではないか、と勝手に推測して結局H氏方式を使うように変更。まあいずれにせよ速度でC++版に勝とうとは思っていないので、迷ったら「コードが美しくなる方」を選択すればいいんじゃないだろうか。

もうひとつ気になってしかたがないのが、関数を繰り返し呼びだしながらリストをちょっとずつ長くして行く処理。func : 'a -> 'b list -> 'b list というのがあるとして、

let lst = func x [] in
let lst = func y lst in
...

みたいなことをやっていて非常に謎。なんでこうなったかというと、appendとか@はなんとなく使いたくないのでfuncの引数に途中まで作ったリストを渡していくつか要素を付け加えて返すようにさせよう、ということなのだが、なんか薄気味悪いコードだ。束縛名lstを順次変えていってもいいのだろうが、数が結構多いのでそれをやっていると名前空間が枯渇するという罠が。

他にも全体的に関数頭部のlet hogehoge = fugafuga inまでが非常にでかくて関数本体が1行とかいうのばっかり。ほとんどの関数は先頭で「なんたらiter」を宣言して、関数本体で「なんたらiter 0」としてループを開始するだけ。ライブラリのソースとか見れば、OCamlらしいコードの書きかたがわかるのかな?

そういえばハードウェア演習で書いたOCamlのコードはOCamlっぽかったなぁ。今回はデータ構造をC++から持ってきたという時点でもう、ループと破壊的代入の羅列になるのは致し方ないのかも。

| | Comments (0) | TrackBack (0)

September 17, 2004

今日のFFO

昨夜小人さんにお願いした甲斐あって、最終2手展開のバグを発見。ついでに調子にのって3手も展開。14.6secが12.8secになった。4手はさすがに効果薄そうなのでやめておこう。記録がだいぶ縮まってるのはPen4 3GHzを導入したせい。1.25倍するともとの2.4C GHzの結果になる。

あとやれることといったら、最終1手の再帰呼び出し部分を除去してインライン化、くらいだろうか。しかしインライン化をやめたら速くなったという報告もあるな。過剰なインライン化でコードがキャッシュから溢れるのか?

思うに、分岐が激しく出現するような関数はインライン化してあちこちに散りばめるよりは、独立した1つの関数として置いておいた方がBTBの履歴に残りやすく、分岐予測ミスが経ってトータルの性能がよくなったりしないだろうか?関数呼び出しのコストよりは分岐予測ミスのペナルティの方が大きい気もする。

分岐予測ミスの頻度とかを計測するツールってないものかな。Intel社内にはまちがいなくあるんだろうが。っていうかそれがシミュレータってやつか?これからCPU実験で自分達のCPUを開発するときにそういうものを作れってことか?

追記)
H氏のキャッシュdisable試験がおもしろそうだったのでやってみる。なんか、L1キャッシュをwrite-backにするかwrite-throughにするかなんて設定もあったぞ!?
結果、L2キャッシュあり→19.218sec、L2キャッシュなし→23.274secで21%増。H氏の結果より差が大きいのは、俺のボード実装がテーブル参照(256KB)を多用するからではないだろうかと推測。テーブルをさらに小さくする方法を思いついたりもしてたけど、テーブルが黒白合わせてもう256KBにしかならないならあまり意味はないかな。

それにしても、学科ノートでの比較の結果、ThellはvsOthaの1/3、Oxelonの1/2の速度しか出てないということが明らかになってしまった……orz

ちなみに、「PentiumMはPen3に近そうだからPen3向け最適化の方が速そう」と思って試したが、Pen4向け最適化の方が0.5秒ほど速かった。むむ?

| | Comments (0) | TrackBack (0)

Thellは速い?

昨日地下室でごにょごにょネットワーク対戦向けコードなど走らせていたら、「Thellが超速い」と言われた。

まあFFOテストのための高速化は俺の場合ほとんどが中盤読みにも効いてくる部分であり、中盤読み速度は大会時の2.5倍強くらいになっているので、決して遅くはないと思うが、超速い部類でもなさそう。比較対象だったvsOthaはバグがあったようなので正しく比較できず。

ところで中盤読みの速度評価ってどうするのがいいんでしょうかね。評価関数が違うから打つ手も、途中の進行も、枝刈りもまるで違う。やはりnpsで比較するしかないのだろうか?Zebra神は中盤でも5Mとか6Mnpsとか…。化け物だ。

終盤読みはもう本当に弾切れ。学科ノートでFFO#40をやると23秒くらいっぽい。はぁ。寝てる間に小人さんが現れてコードを速くしてくれたりしないかな?

| | Comments (0) | TrackBack (0)

September 16, 2004

これはどうだ?

なぜか一度書いて保存したはずの記事がどっか行ったので再掲。なんなんだ?

self-playの棋譜がようやく5万件程度集まったので、テストのために学習させてみることにした。で、見て下さいよこれ↓

stage以前(IOS 300k + Log 120k)今回(self-play 50k)
022.28N/A
121.81N/A
221.099.67
320.289.41
419.418.96
518.458.65
617.338.34
715.998.01
814.417.67
912.487.28
1010.146.75
118.836.42
128.826.24
137.75.67
145.244.42

値は予測誤差の二乗平均の平方根。また棋譜数も圧倒的に少ないので誤差は小さくなる傾向にあると思うが、序盤・中盤に関してsignificantに誤差が減少している。stage0と1のデータがないのは、random-openingしかしていないので有効なデータが採れないため。

せっかく学習させたので試しに対戦させてみたところ、思ったよりもよい成績。例えば6手読みではベアに負ける場合があったが、確実に勝つようになったとか、Thell 3.0.1に勝つようになったとか。

しかしまだ手を間違う場面がある。おそらくサンプル数が少ないことによって正しく評価できない局面に遭遇した場合ではないかと思う。

で、学習させながら思ったのだが、予測誤差に並ぶ評価基準として、「パターン充填率」をはかってはどうだろうか。つまり、全パターンのうち何%が出現したか、及び例えば閾値を100にして何%が100回以上出現したか、を計算する。充填率が高い方が当然いろいろな局面に対して正しい評価を下せるということになる。

早速測ってみた。「最低1回出現したパターン」の種類は、従来のデータの70%ほど。しかしながら、「最低100回出現したパターン」を数えてみると50%ほどでしかない。まだまだ棋譜が足りないな。

さらに、前々から必要性を感じていた「異なる評価関数同士を戦わせてどっちが強いか調べる」ツールを書いた。でもって、序盤6手ランダム、中盤9手/終盤18手完全読みの標準的な試合を新旧の評価関数同士でやらせてみたら、新しい方が50勝44敗6分だった。勝率70%くらいにならないと有意に強いとは言えないなぁ。

ちなみに、FFOテストに適用したら枝刈りが劇的に悪化。これはもう完全にパターン数の少なさの影響か。そうに違いない。そう信じたい。

| | Comments (1) | TrackBack (0)

ウイルス

unno氏からSeal Software宛にウイルスメールが来ました

といっても今時のウイルスはほぼ間違いなくアドレス詐称だろうけど。しかし、2つのメールアドレスの組み合わせからして、この日記でunnoのコメントを読んで、それからSeal Softwareのサイトを見た人、という可能性が考えられます。念のためご自分のマシンを確認してみてください。

しかし、ウイルスメールを食ってくれるのはいいけどなんでヘッダまで食ってしまうかなぁ>Norton
配送経路がわかれば絞りこむこともできるかもしれないのに。

| | Comments (2) | TrackBack (0)

出た!

やっぱり出た

13:04現在、この件はニコンのサイトには掲載されていない。

ニコンホームページ
Nikon Imaging
DigitalCamera.jp

定価60万、8割がけで実売48万、ポイント還元考えると43万くらい?うーん、きついな。

15:15、ニコンのサイトにニュースリリースを確認。

| | Comments (0) | TrackBack (0)

出るか?出るのか?D2X

かねてから噂されていた9月16日がついにやってきた。噂によると今日この日、ニコンが新しいカメラを発表するらしい。D2XとかF6とか最高機種が一挙に出るとか出ないとか。ということで昨夜から2chのD2xスレを再び追い始めたが、リーク情報(←いつまでリンク有効か不明!)などもちらほら現れはじめてやはり祭り状態。こういうウワサはこの段階まで来るとほぼ間違いなくあたるのである。

D2Xについて言われていることはだいたいこんな感じ。
・APS-CサイズCMOS 12.4Mpixel、さらに小さいサイズ(6.8Mp?)にクロップも可能
・デフォルトで5コマ/sec、クロップすれば8コマ/sec おいおいD2Hは不要か
・感度はISO100~800。1600と3200は無理矢理上げるモードがあるが、質は微妙っぽい
・LBCASTじゃないっぽい
・予想価格は5000ユーロ?

5000ユーロか…さすがにちょっと手が届かないな。特に驚くべきところはないが、あえて言うなら本当に12Mpをやってしまったところか。感度もこれまでの200~1600というレベルから一段落としているし、画質が大丈夫なのか気になるところである。あと、なにげにこれまでのCCDからCMOSになっている。それでもLBCASTとは書いてないあたり、LBCASTはやはり失敗だったのだろうか。

なにはともあれ、午後の正式発表を待つとしよう。

| | Comments (0) | TrackBack (0)

September 15, 2004

計算機構成論試験

が終わった。大先生が「簡単すぎたかな」とおっしゃったとおり、前日午後10時から勉強を始めたにしては驚異的な解答を書き上げることができた。

まあもともとこの分野の話は好きな話題で、昔からASCIIで勉強しまくっていた(笑)というのもあって、教科書は難しいところだけさらっと目を通すだけで済んだというのが大きいのかも知れない。が所詮付け焼き刃なので、ブロック図とかはもう提出するのも恥ずかしいあり得ない図を描いて逃げてきたが。

昨日教科書を読んでいて思ったのは、PC系のプロセッサでここ10年くらいの間に高速化のための新技術として投入されてきた様々な技術、例えばパイプライン、スーパースカラ、動的スケジューリング、レジスタリネーミングなんかは、どれも1960年代頃に完成されていた技術であるということに驚かされる。

これはIntelをはじめとするメーカーの技術力の問題というよりは、コストの問題であろう。たとえばIBM/360は、それまでのマシンと比べれば安かったのかも知れないが、基本的に企業が導入するマシンであり、相当な開発・製造コストをつぎ込めたはずである。一方で初期のパソコン用マイクロプロセッサは価格を個人が買える範囲に抑えなければならないし、また1つのチップに全ての機能を集約しなければならないという大きな制約があった。当時のプロセス技術では、とてもパイプラインやキャッシュ、分岐予測機構といった複雑な回路を入れる余裕はなかったに違いない。その後、パソコンの普及が進展するにつれ、相対的に製造コストは安くなっていき、また例のムーアの法則によって組み込める回路規模が大きくなっていったのだろう。

現在では、パソコン用CPUに使われている技術は、プロセッサ業界全体を見回してもそれほど遅れを取っているようには見えない。集積度の面では十分に成熟したということだろう。

ところで、勉強のおかげでこんな記事を読んでも「ライトバック・キャッシュ」だとか「4ウェイ・セットアソシアティブ」とかいう単語がすらすら理解できるのがうれしい。これまで実はセットアソシアティブって何なのかわかってなかったからな。

| | Comments (0) | TrackBack (0)

Prescott

何となく最近身の回りでPrescottが熱い(掛詞?)ので、つい解説記事を読んでしまった。

化け物級のパイプラインをさらに30段にしたりしてもう救いようのない感じであると理解していたのだが、さらに驚愕すべきがこの記事だ。全消費電力の60%がリーク電流だと!?100Wの消費電力のうち計算に使っているのは40Wでしかないのか…。これはまさに不祥事だ。

とにかくこの90nmプロセスというのは終わってるようだ。同じ90nmプロセスで製造されるDothanも予定より消費電力が増えているようだし、いいニュースがないなぁ。65nmプロセスになればリーク電流は大幅に減らせるとインテルは言っているので、今が暗黒の時代なのかもしれない。それまでは金を貯めておくか。

しかし、30段パイプラインといい、ループアンロールや戻り値最適化をしないコンパイラといい、試験の答案に書いたら不可食らいそうな商品が堂々と出荷されているのはどうしたことだろうか。

| | Comments (0) | TrackBack (0)

September 14, 2004

試験前日だというのに

またやってしまった、FFOテスト。元はといえば昨日久々に学校に行ってあんな奴やこんな奴と話したらまたあんなアイディアやこんなアイディアがわいてしまったことが原因なわけだが。また、「CPUアップグレード前に、ハードウェア性能に頼らない速度向上を成し遂げたい」と思っていたこともあった。

でいろいろやってみたわけであるが、結果は悲惨なものだった。

まずはより効率のよい空所表を使おうかと考えて、あれこれ実験してみたのだが、試しに空所表を使わないようにして実行してみたところ全く速度低下がない。あれれ?ということは空所表は意味なし?おかしいな。

それから最終2手展開をやるか、と思って書いて、動かしてみたのだが何かおかしい。一部の局面において、結果が微妙に異なる。例えばFFO#40で+36とか。あるいは非常に遅くなる局面がある。FFO#43は本当は50秒ちょっとで終わるはずなのにノード数激増で170秒かかった。

何か間違っているのは確かなのだが、昨夜と今日ひたすら悩んだがまったく持ってどこがおかしいのかわからない。こんなのどうやってデバッグしろというんだ。というか試験前日という格好の現実逃避日和のこの日にデバッグできなかったらいつデバッグできるというのだ(違

萎えたので、とりあえずはコードをコメントアウトして未来の俺に託すとしよう。かわりにこれから勉強して、未来の俺に追試で苦しむことのない明るい世界を残すため努力するとしよう。

ちなみにCPUアップグレード後のFFO #40は14.3sec。アップグレード前が18secだったから、ちょうど1.25倍。Pen4/3.0をつぎ込んでなお、Celeron/2.0のunnoの記録に及んでいないという事実にもはや絶望すら感じる今日この頃である。

| | Comments (0) | TrackBack (0)

Intel Pentium4 3.0GHz

自分でもばからしい買い物だと思いつつ、Pen4 3.0GHzなど買ってしまった。

Northwood/FSB800MHzである。Prescottではない。

もともとつけていたのが2.4GHzだったので1.25倍の速度向上にしかならないわけだが、現在のマシンを買ってから1年以上経っていること、3GHzが安くなったこと、現在の2.4C GHzの売却先が決まったことから、買うことにした。

もともと「CPUアップグレードは1.5倍以上の性能差が生じてからにすべし」という脳内規定があったのだが、CPUの性能向上が伸び悩む昨今の状況ではそれはなかなか難しい。また、「マシン買い換えはクロックが3倍以上になってから」という脳内規定もあったが、それも今では有名無実化している。

起動してみて気になったのは、起動時の高負荷(なぜか俺のマシンはログイン後しばらくlsass.exeが暴走する)においてCPU温度がぐんぐん上がり、57度くらいまで行ってしまったことだ。ちと怖い。熱伝導グリスの説明書には付着後200時間くらいしないと性能を発揮しないとあるので、数日待てばまともになるのだろうか?それともグリスの塗布量が少なすぎたかな?数日待ってだめだったらもう一度開けて塗り直すか。

もう一つ気になるのは、サウンドがならなくなってしまったことだ。ケースを開けたりまたコードを繋いだりした際にカードがずれたかな?

このマシンのCPUアップグレードはこれが最後になるだろう。次はPentiumM系列の、発熱の少ないデュアルコアCPUがいいなぁ。

あとこのマシンをいじるとしたらなんだろう。ビデオカードかな。現在はIntel 865G内蔵のビデオチップを使っているわけであり、描画性能には全く不満はないのであるが、VRAMとしてメインメモリを使うという点がちと気になる。メモリは1GB積んでるので容量を食われることは問題ないのだが、問題は帯域だ。ただでさえ遅いメモリの帯域をさらに一部をビデオに振り分けているわけで、とてももったいない(気がする)。安いのでいいから単体ビデオカードを買ってきて挿してやれば、その分メモリ性能が向上するに違いない(気がする)。

追記)
さらに負荷かけてみたところ59度に達した。大丈夫か?レビューによればTcaseは70度とのことなので、70度までは上げても問題ないのだろうか。CPU Tempとして表示されてるのはIHS表面の温度のことなんだろう、多分。コア温度は常に76度か77度で一定だから、別にいいのかな?
まあPen4だし、いざというときには自動で停まってくれるに違いない。

| | Comments (1) | TrackBack (1)

September 12, 2004

定石

今日はまったく試験勉強せず。では課題をしていたかというとそうでもない。じゃあオセロかというとそうでもない。明日補講だし、今日は早起きしてみたところ眠すぎて耐えられずぼーっとしたり昼寝したりというダメ人間の極致のような一日であった。はぁ、自己嫌悪。

そんなことより、やはり定石を実装しないといけないと思うわけだ。

これまで理解不能として放置してきた例の書、"Toward Opening Book Learning"をもう一度読んでみた。概要の和訳を参考に読み進めてみるとだいたいやるべきことはわかった。しかしこれで本当に無敵の定石集になるのか?

論文によれば未知の変化について中盤評価関数による深い探索で評価値をつけてるので、相当評価関数に自信がないとできないのではないか。事実、どっかで「評価関数が進歩したため初期のOpening Bookは一旦破棄して作り直した」といった記述を見た記憶がある。すると50万棋譜計画が成功するまでは定石はできないということ?

とりあえず、既知の有名定石を外れるようでは話にならないので、既存の定石を利用する方法で考えている。とりあえずないよりはマシだろう。プロトタイプをOcamlで作ってみるか。こういう木構造の操作は非常にラクそうだ。

| | Comments (2) | TrackBack (0)

22歳

になりました。昨日だけど。なんか書くのを忘れていた。

うちの母方の祖父母は偶然二人とも誕生日が同じ8月15日で、「誕生日には日本中の人が黙祷してくれる」と自慢しているのだが、俺の誕生日9月11日には世界中の人が祈りをささげてくれる。

正直この年になると誕生日と言っても「ふーん」という感じだな。29→30のときはそれなりに思うこともあるだろうけど。

今の自分は、1年前の自分よりも充実した日々を送っていると思う。1年後も、2年後も、3年後も、同じ事を思えるようだといいな。

| | Comments (1) | TrackBack (0)

September 10, 2004

GC

友達の家に遊びに行ったりして思うことは、部屋が片づいている人というのはちょっと何かモノを出した後、それが不要になったら即座に元の場所に戻す癖がついている人である。

それに比べて、俺はどうかというと、何か出したらそのまま放置、で空間が不足するまではそのまま。

プログラマの観点から見てみると、前者はCのmalloc-freeであり、後者はJava等のnewしてその後は放置、に似ている。俺って先進的なんだなぁ。

しかしながら問題は、俺GCは非常に怠惰なので、空間が不足してガベージコレクションを開始しようと思っても始まらなかったり、面倒になって途中で放棄したりしてしまうことだ。→メモリリーク
またGCの性能が悪いため、完全にGCを行うためには数日間を要する。その間他の全てのタスクはsuspendされてしまう。こうして常に空間が微妙に不足した状態が維持される。

現在のスタックフレーム(作業)が終わったら、そのフレームの内容を自動的に破棄してくれるという、C++のデストラクタ的システムを机の上に導入できないものか。

| | Comments (1) | TrackBack (0)

秀丸が!

ふうやっとLilf.*第5回終了。あんな構文解析で果たして自然言語処理なんかできるのか。

ふと秀丸のページを覗いたら、Version 4.13が出ている。しかも、なんか結構機能アップしてるゾ。タブ機能だって。これはいいかも。

最近気づいたのだが、俺はフリーソフト作者なので、秀丸を無料で利用することができるのだった。それまではどうしていたかというと…難儀してる学生だったのでこれまた払わなくてよかったんだな。なにしろ秀丸使い始めたのは中学生の頃だったからなぁ。当時の4000円って今の4万円くらいの感覚ではなかろうか。もっとかな。

秀丸は少なくとも一般的な文書をいじる際には実にいいエディタだ。何よりも手になじんでいるというのがいい。

しかしながら、最近OCamlとかLilfesとかそういうヘンな文書もいじるようになって、そういうのの守備範囲は自由にmodeを追加できるEmacsの方が広いなぁ。秀丸でも色はいじれるだろうけどインデントモードまでは追加できないからなぁ。まあ適材適所ってところですかね。

うちの父は「UNIX使いを名乗るなら当然vi、Emacsなど邪道!」とのたまうので超硬派かと思いきや「秀丸がある限りWindowsは捨てられん」とものたまっており、意味不明である。

| | Comments (0) | TrackBack (0)

September 09, 2004

FFO test @ ECC

ところでECCのマシンどもの性能ってどうなんだろう。ふと気になったので、FFO endgame test suiteをECCでかけてみることにする。以下、#40の結果。

sx102/g++ -O2/52.25sec
sx102/CC -O2/62.28sec
sx102/CC -O3 -xunroll=8/54.08sec
ux101/g++ -O2/26.97sec

SPARC遅っ!そしてPowerPC速っ!ux10?が使っているCPUのスペックがわからないのだが、PowerPC G4 1.33GHzだろうか。G5もありえなくはないが、発表時期と納入時期の関係から無理っぽいな。それに2GHzだったらもっといい成績が出ていそうだ。

それにしてもSPARCは遅い。そして「超性能がイイ!」と喧伝されていたSun純正のCCであるが、見ての通りがしがしに最適化してもgccに届いていない。やはりいろいろ実験しないとわからないもんだね。む、sx10?ってSun Fire V210らしい。今度ISで入れた新クラスタと同じではないか。がっくし。

| | Comments (0) | TrackBack (0)

プレッシャー

self-playingを始めたことで、とりあえず当初の目的であったプレッシャーをかけることには成功したようなのでひとまずOK。しかしながら逆にFFOでプレッシャーをかけられてしまった

なんとなく1999年から2000年にかけてのIntelとAMDのクロック競争を思い出したが、あのときみたいに抜きつ抜かれつではなく、こっちは逆転されて以降追い抜けてないからなぁ。どうしたものか。中盤読み性能とあわせた「モデルナンバー」を提唱して消費者の目をごまかすかw

ちなみに、みんな学科ノートで測定したら正確な比較ができるんではないだろうか。俺は現在FFO#40が23.5秒。Pen4に最適化したバイナリだから多少遅くなってるのかもしれないが、それにしても遅い…。向こうは学科ノートで計測したらもっと速くなりそうで怖い。

こっちはもうほぼ弾切れ状態。Lilf.*でもやってみると、現実逃避からすばらしいアイディアが浮かんでくるに違いない。そうしよう。

| | Comments (0) | TrackBack (0)

random-opening self play game

をしたくなったわけだ、唐突に。いやほら、OCamellの完成度を高めるためにはもっと評価関数精度を上げないといけないしね。(←ということにしたいのですね)

ちょちょっと書いて、Windows上で問題なく動いたので、クラスタで走らせる下準備としてECC上で試す。いくつかコンパイラに怒られた点を修正。中には、例の「表問題」が出現。しかしgccは-Wallつけてると「コメントが複数行にわたってるけどいいの?」という感じの警告を出してくれる。

さて、コンパイルもできたので、big-endianな評価関数データを用意して早速実行。評価関数データはbig-endianで格納とか決めておいた方がラクかも。

そこで俺を待っていたのは、segmentation faultと謎の挙動。なんだこりゃ。手を打ってない。ありえん。SunのCCだけでなくgccも異常な動作。手元のLinux/x86のgccでもまったく同じ動作。なんなんだこりゃ……。

以前棋譜訂正をクラスタでやろうとしたときにはちゃんと実行できたよなぁ…。高速化のためのあれやこれが裏目に出ているのだろうか。しかし悪いことは何もしていないつもりなのだが。

そう簡単にデバッグできる事じゃなさそうなのでとりあえず寝よう。50万棋譜計画は思っていたより難しいのかも。コンパイラの違いで動作まで違うなんてはじめて。SunのCCとgccがおかしいのか、VC++がおかしいのか。

追記)
バグの原因は、1つは「表問題」によってその次のフラグの書き換えという重要な行が消去!されていたことだった。gccが警告してくれなかったら絶対に気づかなかった。もう1つは、実はバグでもなんでもなく、gccのiostreamがcoutへの書き出しの後flushをしないとすぐには表示されない仕様になっていたため、結果が表示されずに悩んでいたというオチだった。
さてバグは取れたが、これから学校に行くのもなんだかなという感じ。家からクラスタが使えないのは不便だ……。とりあえず家庭内クラスタで我慢するか。

| | Comments (0) | TrackBack (0)

首がまわらない

別に借金をしたつもりはないんだけど、朝起きたらひどく寝違えたらしく、首をひねるといたい。そればかりか、肩や背中の筋まで張ったようになって、すごく痛い。

キーボードを叩く姿勢をとるとさらに痛い。しかしパソコンをさわらないと他にやることもないのでさわってしまう。←こういう時に勉強しろ

そもそも今日の寝起きは最悪で、超変な姿勢で寝てたらしく、起きたときには右手が完全にしびれていて感覚が全くなかった。左手で探ったら人の手らしきものがあったので持ってみたら超重い。ってこんなことしてても右手はまったくそれを感じない。ちょっと不安になる。とりあえずまともな位置に右手を持って行って血流の回復をはかる。すごい重さだ。バラバラ殺人事件の犯人とか大変なんだろうなとか考える。血流が回復する感覚はなんかおもしろい。すごく熱く感じる。

寝床に本積みすぎなのかな…。ちなみに積んであった本は「FreeBSDカーネル入門」「Exceptional C++」「Effective STL」「C MAGAZINE 9月号」

明日は、この症状が快復していたら気分転換に地下にでも出向こう。たまには誰かに会って話さないと、なんとなくだらだらした日々を送ってしまう。地下室行っても誰かと会ってだべってるだけな気もするけど、なんというか、そこで他の人の課題の進み具合を聞いたり、全然関係ないことを話したりして過ごすのがいい刺激になるのか、それ以降の日々の生産効率が劇的に向上する気がする。

| | Comments (0) | TrackBack (0)

September 07, 2004

続・デバイスドライバ

偉そうに1日で仕上げたとか書いたが、レポートを書いていたらちょっとおかしな挙動を見つけてしまい、調べていくうちに潜在的かつ致命的なバグを見つけてしまい、結局実質2日になってしまった。

いろいろやっているうちに、Ethernetフレームの構造に詳しくなってしまった。1フレームに格納されるデータサイズの最小値は1オクテットではなく、46オクテットです。気をつけましょう。

バグを直して、ようやく提出。OS演習の課題をこんなに早く出したのははじめてだ。

さて、課題はあと5つ……。

追記:
早速採点されていてびっくり。割り込みハンドラとの競合条件の解消にはspin_lockじゃだめで、local_irq_disable()というのを使って割り込みそのものを禁止するらしい。Y氏は「もっと改良してから出す」と言っていたなぁ。偉い。

| | Comments (0) | TrackBack (0)

試験まであと1週間

らしい。全然そんな気がしていなかったのでびっくりしたが、カレンダーを見るとたしかにそうだ。なんと。

正直、課題がどうしましょという感じで試験どころではないというのが本音なのだが。

だってさ、試験は落としても追試があるけど課題のdeadlineは落とせないじゃん!本試をスルーしつつ問題傾向をチェックして追試でゲット、これ最強(おい

計算機構成論はなんとかならないかな?パイプラインを乱さないことやデータをキャッシュにおさめることがいかに重要かということはこの夏に身をもって体験したわけだし、きっとなんとかなるぜハハハ。

| | Comments (0) | TrackBack (0)

デバイスドライバ

Lilf.*に嫌気が差して、現実逃避した先がデバイスドライバ。TA松葉さんが「環境構築を含め10時間でできた」とのたまうのでこっちもなんとなくタイムアタック気分で。環境構築の頭のところから、なぜか学科ノートにSP2をあてたり、Firefoxのバージョンを上げたりとかしつつ。

飯・散歩などを挟んで実質10時間以内で実装は終わった。が、ちょっと動かしてみたところプチkernel panic。ログに詳細なスタックトレースとかが載るのでまだ簡単な方なんだろう、多分。見たところ関数の使い方を根本的に間違っているらしい。うーむ。

少し調べて、kernel panicの問題は解決。レジュメで意味ありげに書いてあったところだった。なるほどそういうことか。

panicは起きなくなったものの、全くデータが受信される気配がない。ここで地獄のデバッグを決意していったん風呂へ。上がってからはひたすらprintk文の挿入。全コードのほとんどがprintkかという勢い。

いくつか勘違い、ミスがあったので1つ1つつぶしていき、ようやく動いた!デバッグは実質3時間。ドライバのコードはデバッグ出力とか全部ふくめて354行。そんなに大きくない。

ここのところC++しか使わない生活だったので、純粋なCのコードを書くのはひさしぶりだった。普段思っているほどに辛いものではなかった(ドライバはいずれにせよライブラリが使えないので、コードの字面はCもC++もそれほど差はない)が、やはり困るのは変数宣言の前に式が来てはいけないという制約である。変数宣言と使う場所が離れてしまうので書きにくいことこの上ない。結局、C++スタイルのコメント(//)は遠慮なく使ってしまった。本当はC99でないとあのスタイルはだめっぽいけど。C++では使ってない引数があるとコンパイラに警告されるので、使わない引数については型だけ書いて変数名をつけなかったりするが、Cではそれはできないらしい。gccにおこられた。

「はまりどころは全部書いておいたよ」というレジュメであるが、確かに親切にいろいろ書いてある。が、当然ながら書いてない部分とか、中にはわざと調べさせるために書いてないんじゃないかという点もあって、レジュメを過信するのは危険である。レジュメの内容を全部読んで、そこを足がかりにカーネルソース探検するのがよいだろう。

いろいろ調べる手段としては、Linux Device Drivers 2nd Editionと、Linuxカーネルのソースあたり。カーネルソースは現物を直接読むよりも、Linux Cross-Referenceの方が数百倍便利だと思う。どう便利かは使ってみればすぐわかる。

ちなみに俺がはまったところを以下に述べよう。情報科学科の人しか興味ないだろうから「続き」で。

Continue reading "デバイスドライバ"

| | Comments (3) | TrackBack (0)

September 06, 2004

うがー

何の気なしにLilf.*演習の提出状況のページを眺めていたら、いつの間にか俺が現人神として殿堂入り間近な状況になってるので、ちょっとやってみる。このままではりふねんしてしまふ。

えーっと、まずはインストールから。なんかバージョンアップしてるぞ。
ってそういうことじゃなくて。Linuxに入れる場合は特にソース修正の必要もなくてラクである。

とりあえず課題5をやってみるが……構文木を返すところで詰まった。どうやって木を返すんだ?OCamlならささっと書けるが……。こんなに直感に反してる言語は見たことない。

1日1時間以上見てると怒りがこみ上げてくるので、今日はこのくらいにしておこう。というか地下室行って誰かに聞いた方がはるかに効率的なので、家では他のことをすべきか。

| | Comments (4) | TrackBack (0)

September 05, 2004

反復深化

反復深化を使うように探索ルーチンを書き直してみた。

効果は何とも言えず。悪化する局面もあり、劇的に向上する局面もあり。23手読みとかすると、木の上層部のソートがよりよくなるおかげか、半分程度の時間で済むようになったりもする。悪化する局面でも1.5倍程度だから、トータルで見ればまあよい効果を上げているというところか。

そんなこんなで、FFO #40は枝刈りが若干向上して18.11sec、1358.86knps。なんとなく、反復深化にしたことによってnpsが向上するような感じ。7月時点でのvsOtha程度にはなったか?#41,#42,#43と順に59sec, 56sec, 52secだった。#41は枝刈りが悪い。評価関数向上に期待。むしろ50万棋譜計画に期待。

中盤のテストは、進行が変わったので何とも判断できず。バグかと思ったが、どうも序盤の「どっちを打っても同じ得点」という手の選択が、反復深化導入によるmove orderの変化によって変わったらしい。

| | Comments (0) | TrackBack (0)

今日のFFO

移植作業をしつつもやはりオリジナルのC++版が気になる。Ocamellはもはや関数型言語の影も形もない代物になりつつある。OCaml最終課題に認定されるのか不安になってきたYO。

ということでFFOテスト。まず、SP2の適用後に測定してないことに気づいたので何もせずそのまま測定。すると、21秒。1秒短縮している。やるじゃんSP2、ってホントか?

minを呼んでいる箇所を、あらかじめ結果を配列に入れておくようにして条件分岐をはぎ取る。ここ、インラインアセンブリにしてcmov使った方がメモリアクセスのコストもなくていいかもしれない。初代Pentiumなんぞ知るもんか!あー、でもメモリアクセスと言ってもたかだか256バイト分だし、絶対L1キャッシュに入ってるはずだから関係ないかも。

これで最大瞬間風速19.953秒。1300.14knps。夢の10秒台キタ━━━━(゚∀゚)━━━━!!!! しかし、毎度のことだがunnoに先を越されているため素直に喜べず。向こうに勝つには10ぎりぎりか10秒切るくらいいかないとだめだ。

さすがにそろそろ設計上の性能限界に来ているような気がしないでもない。ここ数日、全然画期的な高速化案が思い浮かばなくて困っている。

| | Comments (0) | TrackBack (0)

September 04, 2004

EOS 20Dの画質

C社のカメラなど買うわけもないが、やはり同じランクの他社製品の機能や性能は当然気になるもので。PC WatchにEOS 20Dのβ機のレビューが出ていたので読んでみた。

文中で山田氏が「ただ、本機は素材重視のセッティングのため、デフォルトでは輪郭強調処理が弱めなので、標準設定では、意外にソフトな印象だ。」と述べているが、サンプルを見てびっくり、かつて「JPEGボケボケ」とさんざん揶揄されたNikon D100の画質に近い。C社のカメラもここまで来たか、という印象。また彩度、コントラストともにかなり控えめな印象であり、とてもC社のカメラとは思えない。ぱっと見せられたらD100の画像と間違うかもしれない。Kiss Digitalがある今、マニア向け、プロ向けの設定にしてきたということなのだろう。

ただ、サンプル画像の空の部分を見ると、いわゆる塗り絵トーンであり、Nikonのそれとは明らかに違う。まあ、空の部分の描写など多分モニタで100%に拡大しない限り判別できないことで、どちらでもよいと言えばどちらでもよいとは思うのだが、俺はNikonの方が銀塩っぽくて好きだ。→EOS 20DのサンプルNikon D70のサンプル

ところで、この全体的な輪郭の甘さは輪郭強調設定の問題だけでなく、レンズの問題でもあるような気がするのだ。たとえばこの画像の左下の建物のエッジを見ると、強烈な色にじみが見える。D100でも高級レンズを使うと実にくっきりとした絵が得られるということがあったので、ぜひLレンズ(それもデジタル一眼が出て以降の製品)でもテストして欲しいところだ。

EOS 20DはLレンズをつけて使うべきカメラだと、個人的には思う。(しかし超広角域はEF-Sしか選択肢がないんだよなぁ…)

| | Comments (0) | TrackBack (0)

software suspend

Vine 3.0にして、カーネルは2.4のままであるものの、software suspendという機構がデフォルトで利用可能になっている。software suspendとは要するにハイバネーションのことらしい。あらかじめでかめのswap領域をとっておいて、そこにメモリイメージを書き出す。Windowsの方は常に休止状態と復帰を行き来させており、本当にシャットダウンをするのはパッチを当てて再起動するときくらいしかない状態なので、Linuxでも同じことができればシアワセである。LinuxはWindowsよりも起動が遅いし。

このへんを参考にして、ハイバネーションと復帰自体はうまくいったのだが、Xが復帰した際に色がおかしくなる。なんというか、色が裏返ってるというか、ネガを見ている感じ。ハイバネーションに入る動作と復帰は期待していたよりもはるかに高速だったし、Xの画面表示以外の要素はうまく動いているだけに残念である。いったんXが落ちればよいので、ハイバネーションからの復帰後にいったんログアウトして入り直せばよいのだが。

やっぱり電源回りの完璧なサポートはカーネル2.6じゃないと無理なのか?Vineは当面カーネル2.6には手を出さないと明言してるしなぁ。

| | Comments (0) | TrackBack (0)

O'Camlオセロ始める

ようやく環境が整ったので、OCaml最終課題を始める。締め切り1ヶ月前になってから始めるってどうよ。

いいや、実は2ヶ月前から研究を続けてきたんだ。

実際のところやることはC++版のアルゴリズムを移植することなので、作業量は(OCamlの罠を除けば)正確に見積もることが出来る。再実装による利点は、実装の細部まで再び書き直すことによって全ての処理とデータ構造を今一度理解し、整理し、場合によってはよりより構造を発見できるかも知れない、という可能性である。一種のリファクタリングですな。

現状。

# print_board new Reversi.board;;
  abcdefgh
1 --------
2 --------
3 --------
4 ---ox---
5 ---xo---
6 --------
7 --------
8 --------
- : unit = ()

OCamlはやっぱりいい言語だ。もう、配列、副作用プログラミングの羅列でとんでもないことになっているが、まあそれはこの際そういうものということにしておこう。必要ならforでもwhileでも使っちゃうぞ~という勢いで。

配列は境界チェックが入るらしく、実行速度をどうしてくれる!と思っていたら、ocamlopt -unsafeとすればチェックされなくなるらしい。デバッグ時は配列境界チェックをし、リリース時には省けるというのは理想ではないだろうか。

あと、caml-modeはやっぱり便利だった。配色はCやC++のと違って実に控えめで見やすい。インデントも実は使いやすかった。あとはまだ試してないけど、ocamlc -dtypesとかいうオプションを使ってコンパイルしてからEmacs上でC-c C-tとか打つと、カーソル位置の式の型を表示してくれるとか。やっぱそういう機能は必要だよね。コンパイルしないと使えないのがまだまだVisual Studioに比べると不便なので今後に期待。

向こうがOCamlOthaなら…こっちは"Ocamell"か?設計と速度両面にこだわって、少なくとも9手読みの試合をストレスなくこなせる程度にはしたい。9手読みなら並の人間には負けない強さを保証できるからである。もちろんThell3の評価関数も移植する。そのために頑張ってインデックス表を書いているところだ。

| | Comments (0) | TrackBack (0)

September 03, 2004

Vine Linux 3.0 install

X23のVine 2.6を3.0にアップグレードしたもののしっくりこなかったので、新しく入れ直すことにした。最近、無精であまりカスタマイズをしないのが幸いして、.emacs.my.elをバックアップするくらいで済んだ。

Vineなど何度も入れてるので特に問題はないかと思いきや、いろいろと罠が。

まずテキストインストーラのバグにはめられた。インストール自体は終わってるので再起動。LILOの画面にlinuxしかなくなっていて焦るが、lilo.confからwindows用項目が消えていただけだった。

それから例のマウス暴走。Vine 2.6のときは起きなかったZO。

あと、Vine 3.0ではkonがなくなっているのでコンソールに日本語を出すためにはframebufferを有効にしないといけないのだが、X23ではどういう設定にすればいいんだ?このツリーを参考にすると、どうも普通のビデオチップなら汎用のVESA用設定でいけるらしい。ということで起動時にvga=0x303を渡してやったらframebufferが有効になった。framebufferが有効になると起動時の画面にVine Linuxという画像が出てくるのでわかる。

しかし、framebufferは有効にしたはずなのに日本語が化ける。と思ったら今度はこんな罠が。インストール時に日本語を選ぶと固まるから仕方なく英語にしたというのに。もう。

Windowsの文句を言ってLinuxマンセーする人はこの辺どう思ってるんだろう、とふと思った。暇な時ならこういう作業も楽しいが……。


さて、そもそも何のためにLinuxを入れ直したかというと、快適なO'Caml編集環境が欲しくなったからだ。さすがにそろそろ秀丸で書くのはうんざりしてきていたところだ。かといってWindows用EmacsはどうもよくわからんしMeadowは信じがたいほど重いし、Linuxかなと。

Vine Plusからapt-get install ocamlで一式入り、caml-mode関連のファイルも入るようなので、この辺を参考にそれを有効にする設定を加える。

確かにハイライトされるようになった。しかしながら、インデントとかがいまいち謎。慣れるまでに少しかかりそうだ。

| | Comments (0) | TrackBack (0)

今日のFFO

大して進展なし。昨夜、着手可能テーブルを書き直して配置を変更して局所性が高まるようにしてみたが、変化なし。

それからコンパイラの最適化オプションを"Pentium4向け"に変更。このオプションってPen4でしか動かない命令を使う可能性がある、って意味だと思っていたがどうやらそういうわけではないらしい。「Pen3以前のプロセッサでは遅くなる場合があります」ということは動かないことはないということか。というわけで安心してこのオプションを使うことにした。これで2秒短縮。

それからやはり_forceinlineはどうなのよ、と思って省いたせいなのか2秒延びたり、プロファイル取って時間かかってそうな命令をちょこちょこ削ったりして2秒縮め、結局22.188s、1215.21knpsに。あと何をしたら15秒とか出せるんだろう。ラスト2手展開による関数呼び出しオーバーヘッド削減は実はあまり関係ないという話だし…。とりあえずは五十嵐リストを利用した空所表かな?

FFO#41,42,43にも手を出してみた。それぞれ71、74、155秒。手数が深くなればなるほどZebra先生との差が開いていくなぁ。枝刈りが圧倒的にだめっぽい。反復深化で途中の枝でのmove ordering精度を高めればもっとよくなるのかな?

プロファイルをとってみると、高速高速と自慢していた評価関数がなにげに重くなっている。average timeが評価関数7.5、moveが1.7、undoが4.0くらい。単位はmicrosec?なぜかundoがmoveに比べて圧倒的に重いのが気になる。処理内容は大差ないはずなのに。

探索手法に関して。この方法ってどうなんだろう?最善のlineが出てくるのはまあ便利だが、最善進行のlineだけで次の探索を効率化できるのか?このlineから外れた部分のmove orderingがちゃんとできないと結局ノード数が増えてしまうのでは?と思うのだが…。

| | Comments (0) | TrackBack (0)

September 02, 2004

ステラナビゲータ Ver.7発表

アストロアーツからステラナビゲータ Ver.7が発表された。

それほど目玉と言える新機能はなさそうな感じだが、これには感動した。Ver.6までは基本的に白一色だったから、すごく綺麗に見える。色情報はどうやって得てるんだろう。Hipparcosに色温度のデータとかあったかな?それとも別のカタログか、はたまた手作業?感動したが、この見栄えのためだけに\15,000出すかどうかは微妙だなぁ。

操作性には疑問が残る。ステラナビゲータは従来キーボード操作がまったく考慮されていなかったのだが、今回も特にキーボードによる操作性の向上には言及されていないので、対して変わっていない可能性が高い。実際にフィールドで作業することを考えると、マウス、キーボード、あらゆる手段で操作しやすくしておくことは重要だと思うのだが…。特に数値の指定とか、スピンコントロールは小さくていじりにくいのでキーボードの上下ボタンでいじれて欲しいところである。

| | Comments (0) | TrackBack (1)

SP2入れた

Windows XP Service Pack 2日本語版が正式リリースされたので、早速自分のデスクトップに適用してみた。
リモートデスクトップが複数ユーザーで同時使用できるようになるというオイシイ噂もあったものの、やはり世の中そんなに甘くなかった。それができたらWindows 2003 Serverの意味が半減してしまうからな。

噂のセキュリティセンターだが、Norton Antivirus 2003だからか、「ウイルス対策ソフトの状態が確認できません」とか出る。一説によれば最近のLiveUpdateでSP2対応のupdateがあったという話なので、8月半ばに購読期限が切れたのが原因なのかも。延長するか、2004買うか、どうしようかな。

さて、この勢いで他のマシンにもががっと当ててしまうか。

| | Comments (0) | TrackBack (2)

置換表の実装

現在の置換表はopen hashで実装しているけど、closed hashでもいいんじゃない?と思う。alpha-beta探索の置換表は途中で要素の削除が起こらないのでclosed hashにしても実装が簡単だし、余計な追加メモリアロケーションも発生しない。置換表なんだから入りきらなかった要素は諦めて捨ててしまっても結果には影響しないし。

問題は、テーブルのサイズを探索深度に合わせて正確に見積もらないと性能が悪化するかもしれない、というところか。

でもまあ、本来は置換表のサイズはユーザーに指定させるべきであって、200MBも300MBも無言で使用する現在の実装はやっぱりまずいかも。昔Pentium/120MHzのノートで開発していた頃とは大分感覚が変わってしまった。

| | Comments (0) | TrackBack (0)

blog watcher

自宅サーバのアクセスログを見ていたら、blog watcher spiderなるUAが定期的にアクセスしているので、何なのか調べてみた。どうやら東工大の人の研究らしい。

トップページからキーワード検索をかけるとなかなかおもしろい。"Thell"で検索したら、関連するキーワードが「fujita」とか「評価関数」とか「significant」とか…。significantには笑った。

結構よくできてる…と思ったが、どうやらniftyのココログにあったのでがんがんキーワードを拾っただけで、まだ偏りは大きいみたい。でもキーワードの抽出・分類精度はなかなかよいと思う。

| | Comments (0) | TrackBack (0)

upgrade to Vine 3.0

マニュアル読みと並行して、O'Camlプログラミング環境を整えようと、X23のVine Linux 2.6r4を3.0にアップグレードしてみる。いろいろがあることは言われていたが、それ以外にもわんさか出てきた。

・再起動すると"Checking new hardware"のところで止まる。どうやらハードウェア検出のkudzuが悪さをしている模様。ということでlinux Sでシングルユーザモードに入り、chkconfig --level 3 kudzu offでkudzuを切ると無事起動できるようになった。Vine 2.6のkernel 2.4.22で起動しているのに、Vine 3.0のkernel 2.2.26用kudzuが動いてしまって悪さをしたのか?
・次に、インストールに失敗したパッケージの再インストールに挑戦するも、何度やってもだめなのがいくつかある。libXft.so.2がないとかなんとか。/usr/X11R6/lib を見てみるとファイルはあるではないか。ということで、/etc/ld.so.confを覗くと/usr/X11R6/lib が入ってないので追加してldconfig。それから再びapt-get --reinstall installするとOK。
・ここまでで、一応KDE 3.2が立ち上がって使用できるようになった。が、emacsを立ち上げると起動時にミニバッファに"Error in init file: Wrong type argument: keymapp,[27]"というメッセージが。あーもう何これ。wnnが関係ありそうということだが…?

面倒なので再インストールしてしまうか。その方が起動画面とかが格好イイし(おい
どうせ/home以下はISの課題のファイルだけで、それらはcvs checkoutすればすぐに復元できるものである。

| | Comments (0) | TrackBack (0)

Objective Caml

連想ゲーム:ラクダといえば?
「砂漠」→一般人
「Perl」→Webプログラマ
「OCaml」→ISer

ということで、OCaml最終課題。一応俺の「C++の次に好きな言語」ということになっているので、楽しんでいこう。

Objective Camlなのにオブジェクト指向好きの俺が使わないわけない、ということでまずはオブジェクト指向のお勉強。

コンストラクタ/抽象クラス/C++でいうprotectedメソッド/thisポインタ/インターフェース/継承/template classみたいなの? という適当な理解。

まだ1/3くらい読み切れてない部分があるが、ざっと眺めて雰囲気はつかめた感じだ。C++からJavaに行ったときよりも、書式が全然似てない分混乱は少なそうだ。

| | Comments (0) | TrackBack (0)

September 01, 2004

Thell 3.0.1リリース

panter氏より指摘された全滅の問題を修正して、その他若干の速度向上を行ったThell 3.0.1をリリースした。

オセロの序盤というのは「自分の石を減らし、相手の石で囲ませることによって自分の着手可能手を増やす」というのがセオリーなわけだが、この極限が自石→0ということである。全滅の場合は+64/-64の評価を与えることで、正しく全滅手を排除できるようになる。

| | Comments (0) | TrackBack (0)

今日のFFO

今日は久々に地下室へ。オセロ組で激しく討論した結果、やはり3Mnpsは出さないと我々のプライドが許さないという認識で一致した。

で、とりあえず今日は寝ようかと思っていたところ、unnoが17秒とかのたまってくれちゃってるので寝られるわけもなくなった。17秒っていったらあんた、マシン性能差も考慮に入れると大会前のvsOthaに匹敵しちゃってますよ。

俺はというと、とりあえず終盤2手展開がすぐにはできそうにない、というか、設計に妥協すれば書ける、とわかって、設計の美しさを捨てる覚悟があるかどうか中の人と相談中。「着手可能手が存在しないことが判明して初めてパスを認める」という現在の設計ポリシーを捨てれば簡単なのだが、「Boardクラスはオセロのルールを全て体現するクラスである」というBoardクラス誕生以来の要請を無視することになり、ちょっと複雑な気分。要は現在の実装では着手可能手があるのにpass()を呼ぶとエラーになるようになっているが、高速化のためにはそれを諦めないといけないかも…ということ。

3Mnpsのためには悪魔とだって手を結ばないといけないのかもしれない。あれほど愛していたSTLをどんどん破棄している現状を考えると。

さて、今日の戦績。move ordering用と、着手可能手の列挙用に使っているvectorをfast_fixet_vectorに変更。予想通り、この変更は木の上の方にしか影響しないので、それほど大きな差は出なかった。24.4秒。

今回から、TN-18及びOV-18は「速すぎて、見えな~い」になりつつあり、誤差による変動が大きくなってきたことから、調査対象から外した。

現在のテスト結果。題名、結果、internal、leaf、time、knpsの順。FFO#40だけだとunnoに圧倒され気味なので#41も加えてプレッシャーをかけることにした。こっちでも実は圧倒されてたらどうしましょ。
FFO#40 +38 21332520 6964375 24.375s 1160.9knps
FFO#41 0 59499651 19391009 78.531s 1004.58knps
TN-20 +22 19803126 6003711 25.969s 993.756knps
OV-20 0 2933335 1013047 4.438s 889.225knps
PANDA-18 +10 8634223 2768151 9.032s 1262.44knps

目標である3Mnpsを達成できれば、FFO#40で10秒を切れるのか。すばらしい。

追記:終盤にはほとんど影響がなかったが、ほとんどの箇所でmove orderingを行う中盤には著しい効果があった。テストケースの10手読みセルフ対局で、中盤58秒が47秒に。「中盤1.5Mnps計画」もあわせて推進。

Continue reading "今日のFFO"

| | Comments (0) | TrackBack (0)

« August 2004 | Main | October 2004 »