大学

修論のドラフト版を提出して、審査会（プレゼン）も終了。まぁあと正式版の提出が残っているけど、これはちょいと訂正して出せばいいかと。 審査会では「私のは研究ではありません」とか言ったりせず、普通に研究ぽいことして普通に修論書いたので問題になることはないはず。 ってわけでとりあえず卒業できそうです。これはもしかすると本当に就職して社会人になってしまうかもしれません；

5月末。 なんか出した学会の予稿の1つが採択されましたとかで、行って発表してきます。 いろいろ準備しておいて採択されなかったらがっかりだなーとか思って何にも準備してなかったので大忙し。 ・クレジットカード作る ・パスポートのために戸籍謄本の準備 ・学会登録 ・宿泊先の確保 なんて慌ただしいんだ。 ていうか英語で発表とかムリだとおもうんだけど。 この前日本語でちょっと発表するので大変だったのに、 　・外国行って 　・知らない町で 　・英語で 発表して 　・見たことない人に 　・英語で質問されて 　・英語で答えなきゃ いけないなんて、なにをどうすればいいのかサッパリです。 しかも昨日研究室の先生に 「英語が聞き取れないとか言うのは一ヶ月や2ヶ月ではどうにもならない」 「質問されて聞き取れなくて聞き返して、また聞き取れなかったときすごく悲しい」 とかいうありがたい助言をいただきました。 うーん・・・。どうしたものか。 発表の方はスクリプト作って、なんども練習するしかないんだろうなぁ・・・。 いや、もちろん発表できるの自体はうれしいですよ。はい。 ブログに関する研究している、世界的に有名な人達に自分の研究を聞いてもらえるわけだし。 それ以前に、論文読んで「こいつならまぁ発表する時間与えてやってもいいかな」とえらい人が思ってくれたわけだし。

サークルのみなさんが祝ってくれました。 ありがとうございます。 色紙というのをはじめてもらいました。 心温まるコメントから、訳の分からないコメントまでたくさんいただきました。 あ。お花も。 写真は、unnoに借りて衣装を着てみたもの。（どこ見てるんだろう？） そのまま同じ研究室で大学院いくわけで、とくに何の区切れ目というわけでもないです。

卒業式 卒業しました。 サークルのみなさんが祝ってくれました。 ありがとうございます。 色紙というのをはじめてもらいました。

というところでオセロについて、オセロな人達で発表します。12月1日。詳細はここ あぁスライド準備・・・

辻井研での演習が終わったので、まとめ。 お題は「潜在的意味解析(LSA)を用いた柔軟な情報検索」。 統計的手法を用いることで、たくさんの文書から人間界にある本質的な「意味」を検出して、それを通じて検索したり、類似文書を探したり、単語を分類したり。 作業の多くは実は数値計算。行列をうにょうにょする作業が主だった。そして、分かち書きとか、大規模な文書をメモリを少ししか使わずに扱うとか、Sparse行列を上手に扱うとか、検索結果評価用ツールを使うとか・・・その辺=LSAと直接は関係ないところでだいぶ時間を使ってしまった。 まぁ、自然言語処理入門としては、あれやったりこれやったりで有用だったとも言えるのだが、その分応用っぽいものをやる時間がなくなってしまったと思うと残念。あ、時間がなかったのは、週何回も飲み会に行ったりしていたのが原因か？ LSAは、単語と単語の関係、文書と文書の関係については本質的に何かが向上する可能性を秘めていそう。それに対し、単語と文書の関係については、ノイズ除去程度の意味しかない。このことに、演習のかなり最後に近い段階で気づいた。これは、もっとLSAの意味をよく考えておけばよかった。実装に目が行きすぎていたかも。 単語と単語の関係といって思いつくのは単語分類だが、単語を上手に選んで数を減らして、それをかなり高次元のLSAで処理すればいい結果がでるのかもしれない。 あと、途中から単語の重み付けに力を注ぎすぎたかも。確かに単語の重み付けは重要だし、ある程度までこれをチューニングしないと検索結果がまともに評価できるものにはならない。でも、baselineとかSaliencyを使うやつは面白そうだったのでつい目が行ってしまったが、演習のあとでよかった気も。 blogの検索とかは面白そうだが、LSAがこれに役立つ気は正直しない。精度はよくなるかもしれないけど、計算が増えすぎる気がする。 となると・・・ Saliencyを使って単語の重み付けをして重要語だけを取り出して、LSAで単語のクラスタリングをすれば、心残りのものはすべて達成されるのか。　どこかでやれる時間あるかな？

1月くらいになって、この「アーキテクチャは失敗だった・・・」となってはまずいので、10月にアーキテクチャを決める前にはプロセッサアーキテクチャに関する文書を結構読んだ気がする。なんでこのあとに計算機構成論の試験がないんだろう？ それはさておき、アーキテクチャを考えるに当たって「全てのことには理由がある」というのを重視した。アーキテクチャの細部に至るまで、適当に決めるのではなく、それが最善であるという理由付けができるように心がけた。これは、ぼく以外の3人を説得するためでもあるし、つい役に立たないものを実装するという無用な労力を避けるためでもある。 VLIWっぽいのにするかSuperScalarっぽいのにするかは結構悩んだ。まともなレベルのスケジューリングは1MゲートのFPGAではムリそうだったので、VLIWにすることに。VLIWだと予測分岐付きSuperScalarと比べて、分岐周辺でのオーバーヘッドが大きいのでそこら辺は注意が必要。それから、インストラクションキャッシュのサイズも問題になる。 インストラクションキャッシュミスの問題はnopをランレングス法みたいに圧縮するか、可変長バンドルかなにかで解決できるという考え。結局はキャッシュサイズは余り問題にならなかった(か、コンパイラ係海野の努力で問題が消された)ため、どちらの方法もとられなかったが。 分岐周辺については、予測分岐によって分岐のなくなった命令列に対してスケジューリングを行われてしまってはソフトウェアによる静的スケジューリングの勝ち目はないので、Predication(述語付き命令)による分岐除去で対応することに。アーキテクチャ設計時にはソフトウェアパイプライニングの実装も考えていたので、その障壁をとりのぞくという意味もあった。（結局ソフトウェアパイプライニングは効果が薄そうということで実装しなかったが） 命令形式については、ハードウェアによるデコードができるだけ簡単になる方法を選んだ。こんなところで貴重なハードウェア資源を使っている余裕はない。命令の最初にどの演算器に投入すべき命令かをめいきすることにより、デコードの手間を軽減した。 ある夜プレディケーションの有効活用について考えていたとき、命令のPredicationを指定するの部分に1ビットを加えて、横のPredicationの真偽を反転するかどうかを指示することを思いついた。この方法だと、複数の命令について「両方は絶対に発行されない」ことを簡単に見抜くことができ、複数クロック命令も1クロック差や場合によっては同時に発行できる。 この機能は例のごとくどこかの誰かが既に論文で発表しているかもしれないが、とりあえずは独自のものだと考えている。オリジナルってなんか気分いいよね。 ハードウェア担当のLadiemonが去年の平木班でLambdaユニットという即値テーブルを採用していることに気づき、うちの班でもそれを採用することにした。初期は複数のソースレジスタを結合して１つの即値を表していたが、2slot(当初は3slot)にしてからは命令長に余裕が出たので１つのオペランドとした。 搭載する命令については、完全に海野によるレイトレソースの分析によった。非常に早い段階でソースコードの全貌を解析してくれたことと、11月はじめまでにコンパイラが完成したことでアーキテクチャの細部の設計をレイトレに最適化することができた。 また、植松さんがほとんどの搭載可能性命令をHW実装してくれたため、ある命令がSW実装である場合とHW実装である場合のXXクロックまたはXXスライスといったトレードオフが具体的な値で分かり、適切な方を選ぶことができた。 レジスタへの書き込みを安全に行うには、1クロックで複数のレジスタへの書き込みは難しい。しかし、VLIWである以上何らかの形で複数レジスタの書き込みは行わないといけない。このため、整数と浮動小数点の各レジスタを上下の1つにわけ、4つにする。この4つのうち異なる2つにしか書き込みを行わないという形で問題を解決した。（大住班などでは同時実行する2つの命令は整数レジスタへの書き込みが1つと浮動小数点レジスタへの書き込みが1つとなっていなければならない。この点はうちのHW係の努力に感謝したい） 結果としてみても、うちの班のアーキテクチャは良いものだったと思う。強いて言えば、分岐に関してハードウェア側で高速な処理(命令フェッチ時に即値 or 数名例前に計算済みのアドレスへの分岐など)があれば最強だが、その程度しかさらなる向上のの余地がないと思われる。

終わったのか終わっていないのかよく分からない。 たけど、速度競争という意味でのCPU実験は終わったので、とりあえずまとめ。 今までは「班外秘」ということで(一応)秘密事項であったものが多かったが、もう公開してもOKだろう。 ハードウェア関連の作業(デバッグとか、メモリ周辺とか、基盤配線とか、回路の手動配置とか。)もやったけど、正直そっちは貢献したとは言い難いので、ソフトウェアの方について。 ぼくの主な仕事は ・アーキテクチャの設計 ・シミュレータ ・ソフトウェアスケジューラ の3つ。 と、ここまで書いておいてなんだが、これら3つを1カ所にごちゃごちゃ書くと見にくいので、別の項目として書くことにします。 で、ここには感想。 大変だったといえば、大変だった。「大変なこと=学ぶことが多い」とするなら、学んだことは多いだろう。 自分のソフトウェアの実装については、いくら大変だとはいえ、所詮自分の世界で完結しているので徹夜で実装して数日バグに悩んでむすーっとした顔をしていればできあがるわけだし。 それよりむしろ、自分の班の人たちをどうするかの方が大変だった。やる気がなくなっていそうなら、どうしたらやる気を取り戻してくれるか考え、変な方向へ開発が進みそうなら止め、衝突は回避し・・・。 人数が多ければ、仕事をしたくない人はしなくていいし、誰かが変な方向へ向かってもそれは放っておくだけでいい。 でも今回は、誰一人として失うわけにはいかなかった。リスクが大きいので、賭に出るわけにもいかなかった。 ぼく自身は時間とかを守らない方だけど、それが班員全体の士気の低下に結びつくのではないかと考えるとそうもいかない。 そういう辛さを体感したことが、このCPU実験で得た最大のものだと思う。 プレゼンは、眠くて正直自分自身でも何言っているか分からない感じだったので、聞いていて分かった人はほとんどいないと思う。 ・・・ので、ここにだけでもちゃんと書いておこう。あ、どこかにまとめておいて、来年のCPU実験でうちの班の遺産を取り入れてもらうっていうのもいいな。