貧乏に部室で飲み。結局千円しか使わなかった。
2.4.20 (/.)。Linux のバージョンですが。Linux の記事で出てくる VM っていう単語、誰か意味を教えてください・・・。なんのことだかわからないのです。・・・って、atmarkit の記事（Linuxカーネル2.5 最新開発動向）を見ると、VM（Virtual Memory：仮想メモリ管理システム）と書いてある。VM だけだったら、Virtual Machine だよなぁ。俺だけなのか？ せめて、VMM (Virtual Memory Management) とかだったら類推できるのに。いや、まさか JavaVM 云々の話じゃないだろうし、VMWare みたいなこととか、メインフレームの Virtual Machine とか、そういう話なのか〜とか、色々考えてしまった。今まで知らなかった（調べなかった）のは恥ずかしいかもしれない。
しかし、仮想記憶かー。触りたくないねぇ ^^;。すっげー性能にかかわるはなしだとは思うけど、研究の種にするには、過去の遺産がでかすぎて・・・。アーキテクチャにかなり拠った話と、そうでないアルゴリズムよりな話、ということか。
OpenBSD では、スタックオーバーフローによる攻撃を防ぐために、スタックを実行不可の属性に（できるアーキテクチャで）するらしい。というのは、以前聞いたような気がするが、じゃぁどうやってシグナルなどのトランポリンコードを置くのだろう。ちょいちょい調べただけだけど。[odc] Daily src changes for 2002-07-20なんかどっかの共有領域にそのコードを置くらしい。うーん、なるほど。んで、アレはこれにしないといけないわけだ。多分。だってスタックやっぱり小さいもん（謎）。んで、プロセスの情報に、シグナルのコードがどこに置かれているか、という情報を追加した、ということか。なるほど。結局ヒープとかは、実行可能なんだろうか。ヒープも不可なのか。トランポリンする領域ってのは、実行可能な特別な領域ってことなのか。ユーザはそいつにアクセスできるんだろうか。いや、ほんと実行時ネイティブコンパイルやるようなアレとかナニとかはどうなるんだろう。って、実行不可にするのはBSS、スタック領域だけなのか。ヒープから無理やりスタックをつけてしまうアレなコードとかじゃ、結局問題は残るのかなぁ。そのあたりはどう考えているんだろう。OpenBSD 3.2 リリース に詳しい。日本語っていいなぁ。nested function については、俺は使ったことがないのでどうでもいいや :-p 。
シグナルの実装についても、少しかんがえないとなぁ。
ふと、シグナルなんかの議論を読んでいて思った（自明な）ことなんだけど、高級なプログラミング言語（Hとしよう）からより低級なプログラミング言語（Lとしよう）があったとき。高級、低級の定義はまぁ、おいといて。H から L へ変換するときは、俗に言う L でのご法度なコーディングも、変換プログラムは吐いていいわけなんだねぇ。例えば、Lisp から C に変換するようなものを作ったとき、C でご法度な global variables とか、 goto とか、全然使ってもおっけーなんだよね。変換プログラムにバグがない限り 、バグの温床になったりしないわけで。いや、アセンブラに落とすときは結局 goto なんだけどさ。すげー自明なんだけど、ちょっと新鮮に感じた。勿論、グローバル変数やgoto を使うと最適化を阻害してしまい、性能に関わってしまう、という可能性はあるから、全部オッケーというわけではないと思うけど。いや、例えば (let ... ) をローカル変数じゃなくてグローバル変数で取ったっていいわけだ。って、駄目か、closure 考えると。結局ヒープでの管理になるか。まぁ、環境を弄る必要が無いようなコンテキストでは大丈夫なような気がするが、まぁいいや。んで、H が高級、L が低級とか書いたけど、別に高級でも低級でも、同一動作が保証されていれば、そんなのどっちでもいいんだねぇ。うーん、何が言いたいんだ私は。
東大米澤研究室の StackThreads/MP について、思い違いをしていることに気づく。スタックは一つなのか、こいつら。うはーー・・・。各スレッドが自前のスタック持ってて、そいつに動的にコンティニュエーションをやりとりするのかと思ったら、そうか、一つのスタック上に置くのか・・・。うーん、まだ誤解があるような気がしないでもない。もっと読まねば。うーん、文章だとそれっぽいんだけどなぁ・・・。見ている論文が違うような気がしてきた。うーむ。って、日本語がなひのかもしれなひ・・・。しくしく。頑張って読むか。盗み取るという言葉の定義が問題だよな。うん。
しっかし、排他メソッドの融合（排他的なメソッドの並行な呼び出しを融合する機構を持つ言語 ）ってのは・・・。すっげー面白い。うん。いやー、確かに盲点なのかもしれない。これ、なんとなく Ruby に実装できそうな気がするのは気のせいか。今度やってみよー（いよいよそんな余裕無くなって来てるような気がするが）。誰かやりません？(笑)
$counter = 0
sync def inc # Java の Synchronize みたいなものだと思ってくれい
$counter += 1
end
# ...
10.times{Thread.new{
inc
}}
# => $counter == 10
で、inc が排他しちまったときには、ロックでブロックがかかってる個数分 $counter をインクリメントすればいいわけで。いちいちブロックとかしないでね。うん、Ruby ならできそうな予感がする。
うー、色々読んだけど・・・。どう研究に生かすかなぁ・・・？ 色々得るものはあったが、利用できるかどうか。
とりあえず、今日は帰るか。
Unit testing with mock objects (xpjp)。そもそもUnitTest 自体実践したことないんだけど。勉強しないとなぁ。
C Mag 12月号を買う。うへー、P/ECE プログラミングの記事がー。某Java批判の部分、あれはあんまりじゃないかなぁ、というところがある。あんまりじゃないかなぁ。著者の方にメールでもしてみようかなぁ。でもなぁ、ひよっこが御大になぁ。。。
ANSI Common Lisp (/.)。欲しいなぁ欲しいなぁ（と言ってみる）。
そんな中でPaul Graham [paulgraham.com]のANSI Common-Lisp [paulgraham.com]の邦訳 [pearsoned.co.jp]がついに出版されたようです．
とのこと。読みたいなぁ。
本といえば、生協に XP 関連というか、まぁそういう流行の本が、ずらっとまとめて置いてあったのにびびる。うーん、全部欲しい（ぉぃ）。
なんか、今更読まなきゃーって論文・資料がゴロゴロ出てきた。Rava なんかにかかずらってる暇あるのかなぁ(笑)。
並列オブジェクト指向言語の汎用高並列計算機向け処理系の開発とその応用実証プログラムによる評価 が、なんか素敵。97年か。
東大米澤研究室 のウェブページを、全然関係ないところからたどってきたら、スレッドライブラリ・・・。うーん。というか、個人的に論文のテーマが楽しすぎるのでつい読みふけってしまう。GCが沢山。
Lazy Task Creation について、まぁ論文を見てるんだけど。いやー、まさかここまでダイナミックにやるもんだとは思わなかった。原理を聞けば、なるほどなるほど、という感じがするが、スタックの中身（継続）を他の（暇な）計算機にぼーん、って投げてしまうとは。怖い怖い。卒論のネタに使えないかな、これは。
この言葉を聞いたときは、もっとナイーブに、未実行タスクを積んでおくスタックとかを用意するのかなぁ、とか思ったんだけど。いやはや。これは凄い。うーん、なんか手はないものか。卒論のネタにするには、プロセッサのあの機能を使って・・・。どちらから通信をすることにすればいいんだ？ Idleなやつが「なんか仕事ねーかー」って聞くためには、何が動いているかを知らなければならない。Busy なやつが「暇なやついねーかー」って投げるには、適当にあれを使ってやればいいのか。一応、後者の方が実装は楽だと思うんだが、Busy なやつが余計 Busy になる可能性あるよねぇ・・・。卒論的には、これがあれなのでOKってことなんだろうが。うーむ。これに頑張るよりは、特定の並列化のためのフレームワークを用意してやったほうが効果的だし楽な気がする。Lazy の定義を考え直す必要がある？ 特定のシチュエーションでの Lazy ってなんだ？ うーん、やっぱりどっかに積んでおきたいような気がする。というか、そもそも継続を投げるってできるんだろうか。投げることはできるか。受け取ることができないのか。うーん、これは考える必要があるテーマな気がする。というか、本研究の肝の一つであるアレにアレを押し付けてしまうのもいいかもしれない。というか、それはいい考えかも。おお、面白い（自己完結）。でも、アレが余計に重くなってしまう。うーん。しかも、固定領域なのでネストができない。まぁ、それは制限でいいか。
しかし、あれとかなんとか、わけわからん文章やな、これは。
昨日の ptt では、全然わからなかったけど、やっぱりそうそうたる面子だったのですね・・・。うへー、その前で再来週なんかするのかー・・・。
さて、貧乏に飲み。
ゼミ資料は朝起きたら作ろうと思って、起きたら10：30。やばー。なんとか間に合った、のか？
未踏ユースの発表が。うーん、ユースなんてあったのか。300万円かー。学生を一人アルバイトで強制する人件費くらいなのかなぁ。
先日の日記についてまとめると、JIT というか、コンパイル自体を二段階にするとすると、二つのコンパイラが必要になるということである。
前者は、まぁバイトコード自体の規模が小さいので問題ないだろう。
後者は、Ruby ソースにある種の縛りを設ければ問題ないだろう。
と、まぁこのようなもの、誰か作ってくれないかなぁ(笑)。後は力業だと思うんだけどなぁ。
俺が作るんだったら、名前が前者が Kohaku で後者が Hisui か（ぉ。 ってことは VMの名前がTsukihime か？
卒論終わったら書くかぁ。
でも、両方 Rava に depend したものになりそうだ。
今日は電通大へおでかけ。2年ぶり？
昨日は名前決めに悩む。結局まだ決まらない。
今日は、ちょっと懐かしいところへいって、G200 をゲット、というか回収。これでデュアルディスプレイ環境へ返り咲きだ〜。HHK2Lite も回収。さて、何につなげるか。
しかし、昨日は激しく長い日記だったけど、その考察をまったく生かせていない。なぜか。それは久しぶりに卒論について考えていたからです。多分。名前以外もちょっと。DO ALL とかなんとか。明日のゼミに間に合うんだろうか。
企画書と仕様書について、少し考える。やっぱり、世間一般は私の認識と等しいことを確認。
そもそも、プランナーを甘く見すぎてはいないか。仕様書などのコミュニケーションを甘く見てはいないか。それを誰も指摘しないって、いったいどういうことなんだ。私が言っても聞かないしなぁ・・・。
と、こんなところで愚痴を言ってもしょうがない・・・。
名前といえば、名刺（なんのだ）に書けるようなドメインがほしいなぁ、という話をしてみる。なんか一般的で恥ずかしくなくて覚えやすくてまだ取れるようなドメインないかな〜。
Rava JIT コンパイラはインチキだー、ということで、いんちきじゃなく Just In Time Compile をしてみよう、とか思う。というか、今のはあるメソッドのあるバイトコード直打ちの、いんちき JIT だから、まぁしょうがないのだけれど。
現在のは、class file をロードしたときにコンパイルしてしまうが、これをもっと動的、動いてるときにコンパイルするように変えよう。というわけで、なんか 楽な 手は無いかなぁ。
Lazy Compilation で、彼の有名な首藤さんのわかりやすい解説があるのだけれど、基本はメソッド起動時にコンパイルする。これによって起動されない無駄なメソッドのコンパイルを防ぐことができる。うん、わかりやすい。
んで、それだと一回しか起動しないような初期化メソッドもコンパイルしてしまうので、それは無駄っぽい。というわけで、沢山よばれているメソッドをJIT コンパイルするようなコードにしてしまえばよい。それが Lazy Compilation ということらしい。遅延翻訳とでも訳すんだろうか。次の先のページからの引用が、非常にわかりやすくてよい。
Lazy Compilation は、これまで何回も呼ばれてきたメソッドは今後も何回も呼ばれるだろうから、コンパイルしておけば得をするに違いない、という経験則に基づいています。
invoke 時でのみコンパイルすると、main の中でループをぶん回して何か重い処理をしていたりすると、こいつは JIT コンパイルしたほうがいいような気がする。なので、HotSpot では後方へのジャンプも JIT コンパイルするかどうかのカウンタを増やすそうです（んで、必要ならその時点でコンパイルをする）。後方へのジャンプってのは、基本的にループだしね。
首藤さんのページの受け売りですけど。殆ど。でも、頭の中で考えていたことと、大体同じですな。実は、メソッド呼び出し時にカウンタをインクリメントする、という考えはあまり無かった ^^; 後方参照ジャンプ時にカウンタアップさせりゃええやー、とか思っていた。そのループの部分だけコンパイルすればいっかー と。そうだねー、メソッドごとにカウンタもたせたほうが楽だねぇ。そうすれば、ループ内から invoke するメソッドに対する JIT コンパイルするかどうかの判断も、そのメソッド呼び出し回数で判断すればいいもんなぁ。なんか、難しく考えてしまった。
で、Rava にその機構を組み込むことができるか。できるか。楽にすませるには。うーん。invoke系、ジャンプ系に、その判断をする何かを挟めばいいかー。一つのメソッドで実現できるかなー。できるかなー。多分これも半日で終わるな、多分。ただ、JIT コンパイラ自体はまだすげーいいかげんなので、それをなんとか・・・するべきかなぁ、どうかなぁ。そんな時間ないしなぁ・・・。またインチキしよう（ぉ。
HotSpot とかでは、そのコンパイルしたコードを必要なら さらに最適化したコードへ置き換え するということで、ということは、一度コンパイルしたやつの中にも、カウンタを見たりするコードを挟むのか。うーん、プロファイリング用コードを低コストで持つにはどうやってんだろう。というか、論文探すか・・・。ここまでやると、どうもなぁ(笑)。
2段階最適化、やるとするならば、Ruby の C extension を実行時に Java Bytecode から生成する？(笑) いやー、ここまでやったら、確かに速いだろうなぁ。Ruby のコードより速くなるんだろうなぁ(笑)。うーん、絶対無理、不可能ってことはないわな。というか、RubyJIT って、そういうことやってんのかな。全然よく見てないけど。
今ちょっと見たけど、自動的に JIT コンパイルするかどうか、じゃなくて能動的にコンパイルしろやぁ、ってリクエストがあったときにコンパイルするって感じかね、これは。訂正:なんとなく、違うような気がしてきた。でも、確信が持てず。話を聞いてみたいなぁ。
同じひわださんの rb2c が、Ruby ソースを C 拡張ライブラリに変換して、必ず Ruby インタープリタから呼ぶってのに変えれば、それなりにいけそうな予感がする。予感だけ。
あ、これいいな。あるクラスなりメソッドなりを C 拡張ライブラリにして吐き出すって。全部が全部 C にする必要もないしね。大半の場合。そのメソッド中はスレッド切り替えが起こらない、という制限が付くが、まぁそれは諦めてもらうしかないねぇ。それともイテレーション中に切り替えポイントを挿入しておくとか。でも、それだとパフォーマンスが出ない気がする。そういえば、C extension 中から Ruby メソッド呼んだ時ってスレッド切り替え起こるんだろうか。少し疑問。なんとなく起こりそうな気がするので、少し気をつかったコーディングが必要になるのかな。しかし、俺が考えるくらいだから、既にありそうだな。誰も作ってなかったら、ちょっとやってみようかな。拡張ライブラリの雛型を吐き出すくらいでも、嬉しいような気がするんだけど、どうかね。
んで、Rava では、2段階目の JIT を、それを利用して make なり nmake なりをゴリゴリ動かすわけだ(笑)。すげー。すげー。わけわかんないけどすげー。Ruby より速くなりそうだ(笑)。んで、JVM に追いついたりして。すげー(笑)。 こうすると、なかなか味のある研究になったりするのか。インタープリットや、（一回目）JIT compile 自体は、生産性の高い Ruby で行い、本当に速度が必要になる部分を C で書くことで速度は確保できる。(一回目)JIT compile の処理は、Ruby の強力な機能や文法など、言語の力を利用した最適化ルーチンを書くことが可能で、しかもそれは更新しやすく（コンパイラ自体が Ruby だからだ）、保守性も高い（Ruby のコードは比較的見やすいはず）。うーん、なんとなく立派な感じに見えてきたぞ。Ruby 自体の処理速度が上がれば(2.0 とかで)、実は使い物になったりするのか。うひゃー。
あれれ、Rava は冗談で趣味だったはずなんだが。
今少し考えてみたのだけれど、invoke 時のカウントアップって、面倒くさいね。いや、invoke が呼ばれたときに、カウントアップする何かをいれるのは問題ないんだが、それをなくすことはできないな、と。後方参照ジャンプによる JIT コンパイラの起動は、そのメソッド全体をコンパイルする、少なくともその後方参照ジャンプによるチェックを行っていた部分はコンパイルされるはずなので、そのチェックが無くなる。無くなればチェックの分のコストが減るのでハッピーなんだが。
コンパイルしても、invoker による JIT コンパイルするかしないかのチェックは外せないわけで。それはなんか、非常に辛いような、少なくともそのオーバーヘッドが残ってしまう。invokee が JIT コンパイルされていても、そのチェックを行わないと、なんとなく不整合が起こる気がするし。実際に置くのは、スタックフレーム生成メソッドの中で判定しなきゃいけないのか。判定ルーチンは、こんな感じか。
class RJMethod
def invoked
if is_compiled
return
end
@invoked_count.succ
if @invoked_count > @interpret_limit
compile # JIT compile
end
end
end
うーん、簡単すぎる。簡単すぎて不安になる(笑)。でも、これ以上でも以下でもないんだろうなぁ。
んで、すべての invoke 系には、この RJMethod::invoked を一回呼び、一回 is_compiled を呼ばなければならない、という宿命がつくわけだ。呼ぶメソッドが JIT コンパイルされている、という保証があれば、このチェックは要らないわけだが、その保証ってつけられるのかな？ まぁ、一回のメソッド呼び出しに一回の比較にこんなに考えるな、という説もある。
うーん、どうすっかなー？
うーん、本当に、このソースはこれ以上でも以下でもないのか？ 例えば、is_compiled が真だった場合、なんらかの形で値を返してやれば、上はいかようにもやりようがあるのではないか？ うーん、どうだろう。quick_* みたいなやつ、あれに変更すればいいだけの話なのか。というわけで変更。
class RJMethod
def invoked
if is_compiled
true
else
@invoked_count.succ
if @invoked_count > @interpret_limit
compile # JIT compile
true
else
false
end
end
end
end
コンパイルされていれば true を返すー。後は invoker が煮るなり焼くなり好きにしろー。これで話は閉じるかな、閉じるかな、閉じるような気がするな。例外を投げるのはなんとなく過激すぎるような気がするし。
あー、やっぱ Ruby は楽で楽しい :) （楽しいのは卒論前だからという説もある）。
あまりに Rava ネタがでかいので、久々に線をひっぱってみる。
なんか、この日記のトップにリンクをはってくれている物好きありがたい方がいらっしゃるようで、んでアンテナはってらっしゃるみたいなんだけど、index ページは月１でしか更新しない(笑)。まぁ、当然っちゃぁ当然なんですが。
うーん、index ページに、最新の日記でもくっつけるようにしようかなぁ。そんなに難しい話でもないしなぁ。
というわけで、追加。うわー、ひでえ場当たり的なスクリプト :-p
rexml じゃなくてテンプレートでがさっとやってしまったほうが処理は速いか。まぁいいやこれで。
・・・。
・・・。
・・・。
えーーーーーーー！！！
いや、マジで？ むちゃくちゃ驚いたんですけど。うええええ。
スクウェア・エニックスですか。また安直な・・・。
植松さんはエニックス社員になるってことなんだろうか。
うーん、ショックだったので今日は帰ろう・・・。
全国大会の賞って、賞品出るんだろうか（ぉ。
Rava まとめにかかる。これだけあればいいだろう。多分。
Waterfall (oosquare)。うぉーたーふぉーる型開発の例として紹介されていました。ウォーターフォール型開発なのに、イテレーティブ。うん。イテレーションしてるわ(笑)。いやー、笑った笑った。よくできてるなぁ。
いいかげんな JIT(?) を作る。処理速度が 1800% アップ！ とかくとすごそうだが、元々が全然遅いだけだったりする。最適化を行えば、もう少し早くなるのかなぁ・・・。
計算天文学 II 第10回 データ構造とアルゴリズム(1) (cppll)。こういう分野って、なんか名前ついてたと思うんだけど、なんていうんだっけ？
プログラミング に関して、少し更新。というか、こんなことばっかりやってる気がする。というか、Ruby しか触っていない。最近。卒論ってたしか C とアセンブラだよなぁ。でも今更あんなもん触りたくないよなぁ（暴論）。
しかし、eruby 、面白いかも。アプリケーションサーバが必要になったとき、是非利用してみたいなぁ。
筋肉トレは続く。もう腕が痛くって痛くって。
そういえば誕生日だ。また歳を食ってしまった。
ねむ・・・。
なんか一週間考えっぱなしな感じがしている。Rava 、というか Ruby 遊びで、色々と困った。
先週のあれを先週ちょっと考えていた。
# 複数のファイルを読込んで、並列表示
class Array
# [[1,2,3],[4,5,6],[7,8,9,10] => [[1,4,7],[2,5,8],[4,6,9],[nil,nil,10]]
def zip
res = []
self.max{|a| a.size}.size.times{|i|
res << []
self.each{|a|
res[i] << a[i]
}
}
res
end
end
# p [[1,2,3],[4,5,6],[7,8,9,10]].zip
# ↑こんなのがあったとして
format = (["%-35s"] * ARGV.size).join(" | ")
ARGV.map{|fn|open(fn){|f| f.readlines}}.zip.each{|e|
puts format % e.map{|l| l.to_s.chomp}
}
まぁ、話題の zip ってことで。
腹筋とか、してみる。むちゃくちゃ痛い。やばい。
ruby で簡易計算機ってことで、適当に数字と記号だけのっけて eval するプログラムを作ってみる。んで、馬鹿でかい累乗の計算すると止まらなくなるので、timeout を使ってみる。が、累乗の計算が止まらない。
require 'timeout'
timeout(3){
puts 2000000 ** 20000000
}
ruby-list に投げてみたけれど、真相はいかに。
早速のお返事（まつもとさんから！）で、一つの ruby のプリミティブで実行してしまうので、スレッド切り替えポイントがないのでタイムアウトにならない、とのこと。Ruby のスレッド切り替えについて、大分誤解してて、SIGALRM が来たら即切り替え、だと思っていたら、大抵の場合そうではなく、pending しておいて、切り替えポイントで pending が true なら切り替える、みたいなことをしているんだと思う。うーん、いいな、それ。スレッドライブラリもそれでいいかしら(笑)（駄目です）。
で、楽して計算機は作れない、ということになったか。どうしようかな。 ** の次の数字の範囲でもチェックしてやるか。面倒くせー。
(ruby-list:36475) からのスレッドで、詰めrubyらしい。頭の体操。んで、私も他の方のを参考に書いてみた。
# 複数のファイルを読込んで、並列表示
format = (["%-35s"] * ARGV.size).join(" | ")
(files = ARGV.map{|fn|open(fn){|f| f.readlines}}).max{|f| f.size}.size.times{|i|
puts format % files.map{|l| l[i].to_s.chomp}
}
map の使い方にびびった。このスクリプト自体は、でかいファイルにはきっつそうだね。しかし、ここまで縮めると気持ち悪いな。zip が使えると、もう少しシンプルになると思うんですが(笑)。
GoogleAPI を使ってあそんでみる。GoogleAPI を使うよりも、環境を揃えるのがむちゃくちゃ大変だった気がする。SOAP 系は標準ではないらしい。世の中には 暇人 凄い人 が沢山いるようで、RubyでGoogleAPI をあそぶフレームワークがあったりする。それをなぞってみるだけ。でも、それなりに面白い。
kakasi というものをやっと知る。おもしれー。すげーすげー。
rbot という ruby の IrcBot であそんでみる。うーん、面白く、フレームワークがかっちりし過ぎだが、固すぎる気がする。BDB(Berklay DB)のインストールとかもしてしまった。やれやれ。人工知能の研究、なんぞできるほどの知識もないが、真似事くらいはあそべそう。
Rava 、例外処理をのっける。所要時間2,3時間。あとはスレッドのバグを取れば・・・。
って、スレッドライブラリ（卒論）はどうしたのかな？＞自分
帰ろうかと思ったら、世界最長となる87kmの量子暗号通信システム実験に成功 (/.j)。うへー、マジですか。もう実用化ですか。未だに原理がわかっていないのでアレなんだけれど ^^;。ワープができるようになる日も近いのか！（いや、ようしらんけど） しかし、これを利用しなければいけないほどの情報って、どんなものがあるんだろう。
久しぶりに学校にきました。
大量に食料を調達。これで冬眠もオッケーだ。多分。
免許の更新を受けてくるが、ありがたい話を2時間ほど聞く。すげーうまい話者（女性）だった。2時間飽きさせないとは、素晴らしい。プロだなぁ。お役所の見る目が、ちょっと変わった。
数字に関する調査報告（大きな数字あるいは退屈な数字） (fuji-ml)。でかい数字、沢山あるのねぇ。googol(10^100) かぁ。
http://www.yuko2ch.net/img20021104003005.gif 不思議図形。人に言われてやっとネタがわかった。
C++: 水面下の仕組み (cppll)。メモ。まぁ、こうするしかないよねぇ。原理的な説明なら、今月の C mag の、MALib の解説が良いんじゃないかしら。例外までは載ってないけど。
だらだらしてたら 22時。さっさと帰れよ・・・＞俺。
帰りたい（ぉ。
研究室内で初めて酒を飲む。なんで酔えないんだろう。
そういえば、開聞は冗談じゃなく SVC 中は割込み禁止らしい。うーん、まぁいっか、それで。楽だし。
うーん、なんとかスレッドライブラリ閉じそうだ。疲れた・・・。実は、特殊アーキテクチャだけじゃなく、一般的に使える技じゃないかと踏んでるんだがどうだろう。
体辛い・・・。これ壊してるような気が。つーか、かなり壊れてるっぽい。さっさと帰るか。
昨日、眠い目を堪えて学校に来る。TV取材云々というのを野次馬するため。危うくなんかに写りそうだったのを回避。TVに出すような顔じゃないしなぁ。
しかし、TVの裏側というか、取材風景というか、あのあたりは参考になりました。テクノ探偵団は、渡辺徹の喋りがなければ非常に面白い番組で、機会があれば見てるんだけど、毎回、あのような努力をしているんでしょうか。しているんだろうなぁ。きっと、たった5分（にも満たないか）のシーンに、一日がかりかー。なるほど。あと、街頭実験は、（やばそうなので削除）だったのか。うん、社会勉強になりました。しっかし、ハーフアダー回路を AND,AND,OR,NOT で作るやつ、解くのにしばらく時間がかかってしまったのは鬱。
河原さんに色々と話を伺う。やっぱりハード屋さんの考え方は、面白いというか、なんというか。
virtual(C++) は駄目ですかー。たしかにハードウェア的に見れば、分岐予測なんて効かないだろうなぁ。ハザードがガシガシ。JavaVM の内部なんて見たら、大変だよなぁ。デザインパターンとか、勉強したらどうなるんだろう、などと、妄想。逆に、パイプラインなぞない（分岐予測など必要ない）ほうが、いいんじゃろうか。うーん、無理か。
しかし、横浜行くかなぁ。学生会員5k円。うーん、悩む。
その前に、ゼミの準備に悩むか。何言おう・・・。
ユーティリティーロボット『番竜』の新型機を開発、実用化へ 。かっこいいんだけど、売れるのかなぁ。これにセキュリティ期待しても駄目そうな気がするのは、気のせいだろうか。
ゼミのネタが思いつかない。現実逃避に ../prog になんか書く。
ゼミのネタ、なんとか（でっち）あげる。まぁ作業はしてたから、そのあたりでよかったか。
やっと 開聞 for P/ECE の駄目なところを発見する。SVC中に割り込みが来ると、駄目だわぁ。
解決策を練るが、どうしようかな。割り込み処理ルーチンに、少し細工をするという手もあるし。うーん。難しいところだな。
やっぱり、SVC 中は割り込み禁止にするかなぁ(笑)。
Rava について、なんか喋らないといけないらしい。というか、名前は Rava のままでいいんだろうか＞俺
とりあえず、やらなきゃいけない項目を挙げてみる。
というか、学祭までは個人的に休眠期間だったんだが(笑)。一日に一個すれば、来週には間に合う、んだろうか。うーむ。まじめにやらんとなぁ・・・。
バルド某とかHello某とか、週末の予定だったんだがなぁ(T-T)。
