東大理情名物のCPU実験で毎週徹夜したお話（概要編）

インフラチームでインターンをやっている粟本です。
普段はansibleをのんびり書きつつ、Pairsのボトルネック調査と称してGoと戯れている人間ですが、今回は業務から少し離れて、私がつい先日まで大学の学科でやっていた学生実験の話を書きたいと思います。


会社のブログに大学の事を書くのも変な話ですが、如何せん自分のブログを持たない身には自分のやった事をアウトプットする場所がないのです。というわけで、ここは一つ、大目に見て頂ければ。


ちなみにタイトルに（概要編）とついているのは、この記事が二部構成になっているからで、第一部の今回は、技術的な話を廃したCPU実験の概要に関するお話です。ある程度ITに詳しい人なら分かるかな、くらいを目指しています。
第二部はこちら。

CPU実験とは

私が所属している東京大学理学部情報科学科では、学部３年の冬学期になると、「プロセッサ・コンパイラ実験」（通称CPU実験）なる学生実験が開催されます。


名前から大体想像がつくかと思いますが、この実験は自分たちでプロセッサやコンパイラを作って遊ぼうというものでして、自分たちのCPUで以下のようなレイトレ画像(オブジェクトデータを基に、3D画像を描画する)を制限時間内に生成するというのが単位習得要件となります。

（これは実際にレイトレプログラムを実行して出力された原寸大の画像です。）

流石に一人でプロセッサもコンパイラも作るわけではなく、学生たちは４〜５人で一組となり、以下の担当に分かれて共同作業を行います。


・コア係（VHDLを用い、FPGAで動くCPUを作る）
・コンパイラ係（Ocamlサブセットの言語をコンパイルするコンパイラを作る）
・FPU係（コアに組み込む浮動小数点演算ユニットを作る）
・シミュレータ係（自班のアーキテクチャのシミュレータを作成する）


自分達で０からアーキテクチャ（命令セットやレジスタ構成など）を設計するので、それを動かすためのCPUやFPUはもちろん、コンパイラやシミュレータも自前で作らなければなりません。パッと見、凄く大変そうですが、たった数ヶ月の実験なので、意外と大した事はありません。


ちなみにこの実験、割と伝統があるらしく、その筋の方には有名なんだとか。中の人間からすると実感沸かないんですけどね。

早いコンピュータ

前章で、「自分達で０からアーキテクチャを設計する」と書きましたが、正直そんな事なんてせずにMIPSとか既存の物を参考にして作ってしまえば良いじゃない、と言いたくなる方もいらっしゃるかもしれません。
ところがどっこい、そこは上手く考えられていて、成績がレイトレ画像の出力に掛かった実行時間によって決まるため、早いCPUを作ろうとすると様々な試行錯誤の末に編み出されたカオスアーキテクチャーを作らざるを得なくなるのです。


この「早いCPU」ですが、一言で「早くする」と言っても様々な要素があります。


例えば、


・CPUの周波数を上げる
・コンパイラの最適化によりレイトレ実行時の実行命令数（動的実行命令数）を減らす
・CPU設計による命令あたりの実行時間数の改善（パイプライン処理や２命令同時発行等）


等が代表的なのですが、各人が闇雲に作業するだけでは「あちらを立てればこちらが立たず」みたいな事が発生してしまい、上手く行かない事が多いです。なので、「早いコンピュータ」を作るには、班員一人一人が頑張る事はもちろん、チームの中で連携して「全体として良い設計」にしなければなりません。アーキテクチャー設計なんぞはその最たるもので、コンパイラ係が動的命令実行数削減のために次から次へと新しい命令を追加していった所で、コアがその新しく追加された命令によって律速されるようでは全体としては早くならないわけです。

何が言いたいかというと、結局誰か一人が頑張っても効果は薄く、「全体として早くなる」ようにチーム内で協力しあう事が、高速化への近道なのです。


ただなんとなく、情報系の人間ってコミュ障というか、チームワークが苦手な人がやたら多いような。。。
もちろん、自分もそのうちの一人なのですけれども。

最近の傾向

伝統ある情報科学科のCPU実験と言えど、時代と共にその性質は少しづつ変わってきています。
上述のレイトレ画像を自作CPU上で出力する事を「完動」（完全動作の略）と呼んでいるのですが、最近では全班完動時代などと揶揄される通り、「レイトレ画像なんて出せて当たり前」という状況がここ数年続いています。今後もその傾向は変わらないでしょう。


これはFPGAの性能が上がった事により、素朴に作るだけでも制限時間を満たすコアが作れる事、並びにコンパイラ開発がmin-camlを改造する形で開発するのがカリキュラム上近道になっている事によるものと思われます。


私はコンパイラ係を務めていたのですが、自身のコンパイラもmin-camlをベースにして開発していました。昔はフルスクラッチで作っていた事を考えると大幅に手抜き感溢れるというか、もはやそれコンパイラ作った事になるのか、という話ではあるのですが、「ガチ」でやりたいのであればこの方が良いのではないかと思っています。


というのも、フルスクラッチすると自分でゼロから環境やらファイルやら整備しないといけないわけで、非本質的な部分に気を取られて最適化に取り組むまでにかなり時間が掛かってしまい、非常にもったいないのです。また、それなりに大きな成果（最適化なりなんなり）を出そうとすると、結局対象となるファイルをフルスクラッチしたに等しいくらい書き直す事になります。（実際、私のコンパイラも基本的な構造を除いて殆どフルスクラッチされてます）しかもその改良が元のmin-camlよりも性能がよくなければ何の意味もないですから、min-camlコードをきちんと読み込んでいる必要がある事を考えると、決してmin-camlベースだからといってコンパイラ手書きに劣るどころか、高度な最適化を実装したりできる余裕が生まれ、むしろプラスなのではないかと思います。ちなみに、私が作っていたコンパイラはベースのmin-camlが4500行に対して9000行、まあ二倍くらいにデブった、といった所でしょうか。


min-caml改造の方が実力がつく、という書き方はしましたが、もちろん中にはmin-camlに自班アーキテクチャ向けの最低限の改良を加えただけで良しとしてしまう人もいるのも事実です。単位のとり方は人それぞれですので、それはそれでアリですが。


便利の世の中に生きるというのは良いもので、我らが情報科学科の控室には「手配線のRAM」らしき古代（１０〜１５年前？）の基盤がゴロゴロ転がっているわけですが、とてもじゃないけど私はそんな世界で生まれなくて良かったと心底安堵している次第であります。

1stと2nd

先述の通り、「レイトレなんて動いて当たり前」な時代が到来すると、多くの学生は「もう１セットくらい作るか」という気分になってきます。慣れって恐ろしいですね。最初に作るアーキテクチャは肩慣らしというか、単位を確定させて、かつCPU実験がなんたるか把握するための試験的なアーキテクチャで、本命はその後に再設計したもの、つまり１つ目で得た知見を活かしてより早くしたもの、といった感じです。最初のアーキテクチャを1st、再設計版を2ndと呼ぶ事が多いので、ここでもそのように書いていく事にしましょう。


アーキテクチャ設計は一般的にコア係がやる事が多いようなのですが、私の班ではコンパイラ係（＝私）がコア係から奪う形でアーキテクチャ設計をやっていました。ジャイアニズム全開でございます。


基本方針としては、1stはとにかく早く完動させるために、シンプルで命令数をとにかく少なくした（代わりにコンパイラが頑張る）命令体系にしました。よく使う命令は2ndになってから導入すれば良いやという魂胆です。
最初の授業が９月末にあり、早い所だと１ヶ月足らずで完動してしまう班もあるのですが、折角やるからにはさっさと完動させたいよね、という意味合いでの1st単純化施策でした。ただ、ある程度余裕を持った線表も組んだものの、結局コア係がコアを完成させられず、我が班が完動するのは11月に入ってからという事に。。。難しいですね。いろいろ。

進捗報告会

少し話は変わりまして、CPU実験では毎週火曜日に進捗報告会というものが開催されます。その名の通り、一週間何をやったか、という事を発表する場なわけですが、そこで何がしか輝かしい成果を発表したい思うのが悲しい人間の性でありまして、特に私なぞは命令数が減った事を報告（＝自慢）したいあまりに毎週月曜の夜は徹夜していました。火曜午前の授業の出席率はお察し 第二部でいろいろと最適化手法を紹介しようと思っているのですが、それは毎週の徹夜によって生み出された進捗なわけであります。命令数を減らす一番簡単な方法は自分の寿命を縮める事、ですかね。ちなみにこの記事も徹夜で書いているので、寝ぼけた事書いてたらごめんなさい（汗


一応言っておきますが、うちの学科は誰も徹夜作業を強制しませんし、課題こそ重いものの、締切が実質無いに等しい上に、単位を落としても2年くらいは待ってくれるので（もちろん留年抜きで）大変ホワイトな学科です。大体徹夜するのは、全く勉強してない試験の前日か、或いはCPU実験が楽しすぎて自ら進んで徹夜の道を選んでいる場合か、だけだと思います。


理情の人間はCPU実験が辛すぎて地下に幽閉される等といった噂がありそうですが、全力で否定しておきます。否定しておかないと、後輩が減っちゃうからね。ぐへへ。

チームワークの難しさ

上の方で、「個々人が頑張るのは当たり前、大事なのはチームワーク」という風に書きましたが、それこそ自分たちの班が一番律速されたのがチームワークの不備でした。（まあ正直どの班もそうだと思いますが）
コンパイラは12月頃に余裕で2nd対応して、何時になったらコアができるのかと首を長くして待っていたのですが、待てども待てどもコアはできず。結局、最終成果報告会に2ndは間に合いませんでした。


学生実験でグループワークを行うとなると、そのグループの構成員の実力やモチベーションの高さにどうしても依存してしまう部分が大きくなります。班決めはくじ引きなので、こればっかりは神頼みするしかないですね。特に全班完動時代の流れの中でよくあるのは、1stが完動した時点で「ここからもっと改良して行こう」と思う人だけでなく、「もう単位来たからそこまで頑張らなくてもいいでしょ」と思う人も出てくるわけで、そこら辺は個々人の自由なわけです。仮に、もの凄いリーダーシップを発揮できる人がいれば、全員の向く先をきちんと揃えられるのかもしれませんが。


あとは、スケジュール管理の不備とかもよくあります。「このくらい期間を見積もっておけば終わるだろうから、デッドラインから逆算したタイミングから開発を始める」みたいな。こういう形で書くとわかりやすいですが、大変陥りやすいパターンです。最近はイカとかいう進捗妨害コンテンツもあるようですし。

停滞期?

そういえば、今年の、というより最近のCPU実験は何だか全体的に活気がないような気がします。先ほども書きましたが、「どうせ完動して単位が来てるのだから、それ以上頑張らなくてもいいじゃない」みたいに考える人が一定数いる気がします。あとは11月や12月辺りに完動した班だと、正月に中だるみしてそのまま特に頑張らずに終わる（or 直前で頑張って間に合わずに終わる）、みたいなパターンも多いです。年末年始は、毎週の進捗報告会が「進捗ありません」で終わっていました。

ま、僕自身も12月以降命令数を減らせてないので、あまり人の事は言えないんですけどね。。。（一応いろいろやってはいたのですが、結果には繋がらなかった）

CPU実験のその先へ

ちょっと暗い事を書いてしまいましたが、最近ではCPU実験本体よりも余興（FPGAを使った小ネタ）でなぜか本気を出してしまう人達が出てきました。去年だとxv6の移植とかですね。詳細はググッてもらえれば出てくると思います。
こういった人達は「単にレイトレが動けば良いや」からまた少し別のステージに進んでいて、大変良い傾向なのではないかと思っています。来年以降もこの傾向が続いていけば良いな、と個人的に期待しております。


ちなみにかくいう私も、どちらかというと余興がメインで、コンパイラ最適化は余興の合間にやっていました。まあ、この話は長くなるのでまたの機会に致しましょうか。

エウレカ、絶賛採用中！

さて、延々と大学の話を書いてきたわけですが、これだけで終わると流石に何か言われそうなので、強引に会社の話に繋げようかと思います。


僕がこの会社でインターンをしていて、コンパイラ技術が役に立った事は一切ないですし、たぶんこれからも役に立つ事はないと思います。でも、CPU実験の事を話すと、興味深そうに聞いてくれる心の広いエンジニアがたくさんいます。皆さん技術に貪欲なので、会社に全く関係のない話でも食いついてきてくれる方が多い印象があります。そういう意味で技術第一主義の人間にとっては、大変居心地が良い空間ですね。


まあぶっちゃけると、たぶんこの会社でコンパイラを書く事はないと思うけど、凄くホワイトで居心地が良い会社なので、バイト先を探すのが面倒だったり、今のバイト先に辟易している方は是非とも一度ご検討くださいませ。我らがエウレカはコンパイラを書けるような優秀な人材を絶賛募集中です。


なんでこんな事を書くかって、学科の友達が安い時給でめちゃくちゃ働かされて使い潰されてるのを見てるのと、なんともいたたまれない気持ちになってしまうんですよね。塾講とか、下手なベンチャーとかで働くよりかはエウレカで働いた方が自分の時間も持てるんじゃないのかなぁ、と思うのですが。コンパイラは空いた自分の時間で書けばよろし。


個人的には業務中にもコンパイラが書けるともっと良いのですが。。。
お偉い様方、如何でしょうか？（ ＾ω＾）