プロセッサ・コンパイラ実験記
プロセッサ・コンパイラ実験(「CPU実験」と呼ばれます)は、(今年は)4,5人のチームで「CPUコア」「コンパイラ」「シミュレータ」を分担して作り、左のようなレイトレース画像を出力する課題プログラムを(基本的にはベースとなるコンパイラ(MinCaml)を改造した)自作コンパイラでコンパイルし、自作アーキテクチャに則った自作CPU上で動作させる、という、なんでも、ウチの学科の名物実験らしいのです。
書き始めた今日(3/8)、最終成果報告会、要するに最後のプレゼン及び課題プログラム実行時間のコンテストが終了し、今年度のCPU実験は一応の終了ということに相成りました(延長してやりたいという人もいなかったですし、そのまま終了ということになるんじゃないかなと)。
今年は無事に全班がレイトレ画像を実機から出力、シミュレータの出力と一致しました。HWの難易度が少し下がったとはいえ、全班動いたことはすばらしいことだと思います。アーキテクチャに関しても、スカラ、スーパースカラ、VLIW、となんとなくそろった感じでした。
ウチの班の結果は、
- 総命令発行数19億命令程度
- CPU動作周波数110MHz
- 課題プログラム実行所要時間26.548秒
で、3位でした。
2ndArch.が完成してから1位の班の所要時間を聞いたら正直絶望的だったので、2位かなーとか思っていたのですが、2位の班が思っていた以上に速かったです。オーバークロックして121MHzで無理して動かしても良かったかなー、とかほんの少しだけ後悔しました。
僕はCPUコアをVHDLで書く係だったので主にその方向についてしか詳しくない・その方向ばかりの内容になりがちになりそうなのですが、CPU実験を振り返って2回に分けてまとめておきます。
1回目は2010年度CPU実験の全体の変遷まとめ、2回目は次年度以降の展望とCPU実験について思うこと、実際に6ヶ月やってみての感想、という感じで行きたいと思います。
全体を眺めていての印象、まとめ
7-9月
かなり早い時期からCPU実験の班分けをどうしようか、という話し合いをしていました。
班決め方法決め論争
「夏休み中にCPU実験を始める」という今から考えると何かキチガイじみたような意見がぽつぽつと出ていたように感じました。しかし、実際、後にコア担当になったような人は、夏休みに技術習得などを行っていたようです(簡単なCPUを作ってみるとか、後にも普通に使ってるようなCPUまで作ってるとか、FPUモジュールを書くとか)。
それはさておいて、この時期の興味の対象は「班の決め方をどうするか」というものでした。ざっくり言えば「各班の能力を均一にする」か、「各自集まりたいように集まる」かです。前年度には後者の方法をとったことで、実力のある人が1つの班に固まったせい(だけとも思わないのですが)で、動かなかった班が多数出ており、それがこの論争の大きな原因の一つだと考えられます。
当時の僕はやる気に満ち溢れていたので、単刀直入に言えば足を引っ張られたくないなー、などと、後者よりの考えであったと思います。それを口や態度に出してたかは覚えてませんが。
当然思惑が一致するわけもなく、結局話し合いは暗礁にのりあげ、なぁなぁに近い感じで夏休みを迎えることになりました。確か、「夏休み中に勝手に集まっても良いけど、それは解体されても文句を言わないこと」みたいな感じだったと思います。結果的には後にコア係になる人しか夏休み中に作業していなかったように感じたのですが……
10月
CPU実験が始まりました。他の班の動向も目に見える部分が多く、もっとも活動的に見えたといえるでしょう。
CPU実験開始、班決め
まずは班決めをしなければ動けないわけなのでまずは班決めから行わないといけないわけなのですが、話し合いをしてもあまりに決まらなかった経験があったため、コンパイラ、コア、シミュレータ、の順でやりたい人を募り、残りの人を出席番号順に詰め、TAがランダムで班の間で同じ係の人を交換していく、という決め方になりました。
前年からみて5,6人だと思っていたのですが、今年は4,5人8班という、割かし少ない(らしい?)人数、多い(らしい?)班数でやっていくことになりました。
班が決まったら、各班アーキテクチャ(命令セットアーキテクチャとマイクロアーキテクチャがあります)を決め、実際に動いていくことになります。とにもかくにもレイトレが動かないと単位が来ないので、ほとんどの班が比較的単純なアーキテクチャで単位確保に向かうこととなりました。
ウチの班も例に漏れず、というか僕がそう決めたのですが、まずはMIPSのサブセットのような簡単な命令セット、簡単なパイプラインCPU、要するにRISCアーキテクチャで単位を確保することに決めました。
デバッグ天国
夏休み中にCPUをそれなりに実装していた班が2つほどあり、それらの班はすぐに動くと目されていました。しかし、CPU実験はそんなに甘いものではなかったのです。何故か動かない課題プログラム。理由のわからない動作不良。結局詳しくは知らないのですが、1つの班は作り直し、1つの班は「動く動く詐欺」などと言われてました。「動く動く詐欺」の班は、聞いたところによると班員間の意思疎通が図れていなかったことによる仕様の食い違いが原因だったとか。
ウチの班は他の班に比べたら比較的マシだったように思います。今にして思えば大きなバグは特に無く、min-rtの前にパーリンノイズ出力でデバッグしていたのですが、itof/ftoiがバグっていたことぐらいだったような。「ぐらいだった」と言いつつ、パーリンノイズがきれいに出なかった日は、(他の班がデバッグ地獄だったのを見てるので)ウチの班もやべーなー、などと十分に睡眠をとることもできず、夢の中でまでデバッグしてる有様でした。次の日に無事float_of_intとint_of_floatがバグフィックスされてパーリンノイズがきれいに出力されましたが。
fib(10)=0x37が表示された拡張基板(2009の方からの頂き物ですが、使っているうちに配線が取れたりして現在は使うことができません)
以下は、デバッグに使ったプログラムから出力された画像です。パーリンノイズはビット演算を多用するため、命令種を絞った2ndArch.では動作させるのが難しかったので使われなくなりましたが、マンデルブロ集合は単純で少ない演算で出力することが可能なので、最後の方まで主にコンパイラのデバッグで役立っていたようです。HWのデバッグはもっと小さなプログラムでないと厳しい印象でした。
パーリンノイズ
マンデルブロ集合
完動ラッシュ
10月末、4日のうちに3班が実機でレイトレ画像を出すことに成功しました。ウチの班も含まれてます。上で触れた2班もこのタイミングで動きました。11月第1週まで含めて半分の班が実機で動作させることに成功しました。
ウチの班は単位確保ー、うひょー! ってなってましたが、実機の出力とシミュレータの出力が真に一致することが単位条件に含まれている、とか言われてたので実は単位確保されていませんでした(最終発表やその後のソースコード提出の方法などを考えると、実は一致しなくても良かったのでは……などと思いますが、まあまだ成績出てないのでわからないですね)。
11月
リスタート
まだ動いていない班はデバッグ作業があまり進展せず、動いた班はちょっと余韻に浸ったのち2ndArch.に移る、という感じでした。夏休みから作業していたコア係を有する班はこの時点で3rdとかいってたりしました。2班追加で動き、比較的大きな問題も無く動いた班はここら辺で動いたようです。正直、ここで動かなかった班は最後まで動かないのかなー、とか失礼なことを考えていました。
ウチの班は2ndArch.を考え始めました。スーパースカラで2命令同時フェッチ、を目標に設計などを開始しましたが、結局最後まで完成させることは無かったです。スーパースカラを設計し始める前に、プログラムを送信できる設計にする、OutofOrderCompletionを実装する、を達成させた1.5thArch.を実装しました。今にして思えば、ここでもう少しストール方式などを考えて時間をかければスーパースカラもあるいは、というところだったのかもしれません。バグに追われてうまくいかなかったかもしれません。
スーパースカラを目指す場合は、それなりの速度のスカラを実装してからの方が良いと思いました。少なくともInorderCompletionScalarのほぼ直後に実装を開始するものではなかったと思います。
自作CPU上でゲームを動かす、というのはここら辺で実際に目標として掲げられたような。覚えてないですが。
12月
聳え立つクソ
さらに1班が動いた時期だったような。その班に関しては、なんでも本来シミュレータ係の人がコアを書くという謎な事態だったようです。
ISersのやる気も順調に低下し、「CPU実験は聳え立つクソ」という名言までもが飛び出す始末でした。
ゲーム動作に向けて、周辺機器の調査整備などを開始しました。この時期にやったことはVGA出力でした。モジュール整備や仕様調査などはholeにやってもらい、ネット上の回路図の通りに実際に電子部品を配置し半田付けするのは僕がやりました。といっても、後で変わるかもしれない部分はブレッドボード上に構築し、端子類だけ半田付けした感じでした。
スーパースカラの設計も同時進行していましたが、コンポーネントの宣言をファイルに記述した時点で「うわ、これ、無理じゃね」ってなってほとんど投げ出してました。
1月-2月上旬
大義名分
試験週間でした。最後の進捗報告も終わり、試験を受け、という感じでした。この時期にさらに1班動き、動作していない班は残り1班、という状態になりました。もう最適化が行われるフェーズだったのか、12月に引き続き、全体的に目立った動きはありませんでした。
僕は2ndArch.の命令セットでスカラCPUを実装し、一応動く程度にしたのはこの時期(1月頭〜1月中旬)だったと思います。OutofOrderCompletionScalarです。一部命令をmin-rtに最適化したものです。最適化と言っても、さすがにゲームも動かせる程度の命令はあります。VRAM出力なども含んだシミュレータですでに開発されていた、立方体のワイヤフレームを回転させるプログラムがなんとなく動作することを確認し、試験勉強フェーズに移りました。
周辺機器としては、SFCのコントローラをばらしてパラレル化し、実際に入力をとれるようにする、ということをやっていました。これでディスプレイに絵が出て、入力が取れるようになりました。
2月下旬-3月
試験終了、追い込み期
コンテストの1週間程前に最後の班がmin-rtを動作させることに成功、これで全班実機動作となりました。沸くIS2010ers。
他の班に関しても、最適化・高速化する余裕がある班は3月に入ったあたりから地下で作業している時間が一気に長くなり、どんどん実行時間が短くなっていっていました。もうちょっと早くこの状況になっていたら全体的にスコアが良くなっていたのかもしれません。CPU実験としては健全な姿ですが、どうなのかな。
前日〜コンテスト当日にかけては15名近くの人が地下に泊まっていました。完徹で作業していたわけでもなく、途中で寝た人しかいませんでしたが。
sqrt係とうまく連携が取れず、コンテスト1週間前までmin-rtを動作させることができない、という微妙に綱渡りな日程になってしまっていましたが、ゲーム製作準備を通してかなりデバッグされていたので、sqrt追加してバグが1つも無くストレートで動作させることができました。前日に、負の数を第2引数に取る比較がうまくいかないことがある、という初歩的なバグがフィックスされていた、というのも大きいのですが。
前から準備しておいたFPUのC++実装をシミュレータに組み込み、一部バグを修正して実機の出力とシミュレータの出力がめでたく一致しました。
この時期は、ゲームを作るためにドット絵をかなり描いていた覚えがあります。意外とそれっぽくはなるけどもうしばらく描かなくても良いや、という気持ちになりました。
前々日、前日でコントローラ・サウンド・VGAが安定動作するように基板にほぼ完全に配線半田付けしました。抵抗を24個半田付けするあたりがもっとも何も考えなくて良くて楽しかったです。逆に辛かったことはコントローラの接続用コネクタを作ることでした。
ゲームも無事完成し、発表用のスライドも作成し、あとは明日の発表を迎えるだけ、という状況になってからはまったりと過ごすこととなりました。
コンテスト、そして
とうとう6ヶ月の長きに渡るCPU実験が終了する日が来ました。
1班あたり発表に(ゲーム、動画、独自のレイトレ画像、といった余興は別として)15分与えられました。
ウチの班は、班員の都合により最初に発表することとなりました。どの程度の固さなのか全くわからなかったのでかなり不安でした。
発表自体は途中少しもたついた部分もありましたが15分30秒と、ほぼ時間通りに終わらせることができました。
そして2月後半あたりからかなり時間を費やしたゲーム実演……となるはずだったのですが、ミュートにしていることを忘れ、ドライバを地下にとりに行かなくてはならない、というアクシデントが発生。ここで僕が走ったのですが、今にして思えば先にゲームのタイトル画面だけ出しておく、などすべきだったかもしれません。
そして実演……想定外の事態。数分も経っていないタイミングで「じゃあ終わって」「後にも班があるからねー」などと打ち切られる。憤りを感じずにはいられませんが、説明も何も無くコントローラ操作していただけだったのもいけなかったのかな、とも思います。
まあそんなこんなでウチの班の発表は無事終了しましたが、明らかに準備不足考慮不足の面もあり、リハーサルの必要性を実感した発表でもありました。チーム全体でリハを行うことができなくても、チーム全体で行うことに固執せず、自分の担当分を1回でも行っておくと気持ちの面でも、準備の面でも、全然違ったものになると思いました。
後は他の班の発表をぼーっと聞いていました。技術説明を中心にする班、変遷を中心にする班、動作速度を中心にする班、などいろいろな発表があったように思います。
各係に関する全体的な傾向として、HW係の発表は地味なものになりやすく、逆にシミュレータはGUIシミュレータを作っていた場合は目に楽しい感じのものになっていたように思います。
先ほど過去の発表スライドなどを眺めたところ、「命令セット」「マイクロアーキテクチャ」を全体として解説、後は各係の特徴を発表、という形式をとるのが良いかな、と思いました。
班番号(班名) | 所要時間 | アーキテクチャ | 余興 | 寸評 |
---|---|---|---|---|
1班(1班(仮)) | 29.800s | Scalar | - | 150MHz達成、FPUすげえ、コンパイラはポケモン |
2班( 班(whitespace班)) | 42.502s | VLIW | - | HWの発表がHWにしては面白かった。シミュレータがんばってた |
3班(sky班) | 26.548s | Scalar | IKADIUS(イカ娘の横STG) | 僕たちの班 |
4班 | 418.41s | Scalar | - | 最後にmin-rtが動いた班 |
5班 | 241.07s | Scalar | - | 数学科の人がいた |
6班 | 19.928s | Scalar | - | 今年度最速、コンパイラの最適化が光る(12.4億) |
7班(yjfactory) | 350.97s | Scalar | - | なぜかシミュレータ係も別のコアを書いた班 |
8班 | 25.924s | SuperScalar | 手動最適化min-rt(22.599s)、FCマリオsld | HWやべえ班。コンパイラもなかなか |
この表、間違ってそうなので、誰かis2010erで間違いに気づいたら教えてください。
最後にTAのまとめの言葉をいただき、FPGA基板を返却し、CPU実験が終了しました。
僕の心に残ったのは、達成感でも、充実感でもなく、ただただ「あー、終わったんだ」という虚無感、脱力感だけでした。
これ以降は、我が班のアーキテクチャ、開発方法についてや、CPU実験を通して学んだこと、反省点、感想などを書いていきます。
1st Architecture
Cumulus
特徴
- 2ndアーキテクチャ
- コンテストで使った
- bit割り当てをきれいにした(ささやか)
- 書き込み予約などによりExecでの追い越しなどが可能に
マイクロアーキテクチャ
命令セット
- ADD / SUB / MUL / SRA / LIH / ADDI / MULI
- FADD / FSUB / FMUL / FDIV / FNEG / FABS / FSQRT / FLIH / FLIL
- ITOF / FTOI
- LOAD / STORE / FLOAD / FSTORE / IOLD / IOST / IOFLD / IOFST
- MOV / FMOV / FMOVI / IMOVF
- BNE / BLT / FBNE / FBLT / BNEI / BLTI
- RET
- JMP / JAL
- NOP / HALT
Cumulus-game
特徴
CPU処理能力
- 60FPS時:約160万クロック/frame
- 30FPS時:約330万クロック/frame
バージョン管理
今回、Mercurialというバージョン管理システムを利用することとしました。Mercurialを選んだ理由は、Subversionはあまりに時代遅れ、Gitと悩みましたが、最終的にはなんとなく、で決めることになりました。
まともなプロジェクトでバージョン管理システムを利用するのは初めてでしたが、HWはほんの少し変えるだけで動かなくなったり、変更箇所が思いのほか多くなって大崩壊したりすることがあるので、もしうまくいかなくてもいつでも以前のバージョンに戻すことができる、という強みは、そのまま変更をガシガシすることができる、という強みへと変わりました。
また、branchすることによる異なるラインでの分岐開発(Cumulus-gameは、分岐予測とキャッシュが搭載される前のCumulusから別れ、平行して開発された(といっても、IO開発などはブランチ前に開発してしまっていたので、Cumulus側ではrevertみたいにしてから進んだが))、うまくいくかどうかわからない機能拡張時に別ブランチにし、機能拡張完成時にマージすることで不要なrevert、レポジトリの汚染などがなくなることは、途中で気づいたのですが、かなり便利だと感じました。
add/commit/pull/pushがわかれば最低限良く、今回のように1人1人担当が全く異なる場合にはそれでほぼ十分でした。また、ホスティングサービスのbitbucketが無制限の容量を使うことができ、また家鯖にはない安心感をもって使うことができたのも良かったこととして挙げられると思います。
結果からいえば、必ずしも分散バージョン管理システムである必要はありませんでしたが、レポジトリのコピーを容易に作ることができる点は開発を柔軟に進めることへとつながるのではないかと感じました。
プロジェクト管理
RedMineを家鯖に立て、それとGitを連携させてプロジェクトを管理している班もありましたが、ウチはPukiwikiを班員の家鯖に立て、そことbitbucketのアップロード機能を併用し、緊急性の高いものはメーリスで通知、という形で管理することになりました。それに週1回のミーティングで周知する、という感じでした。作業範囲がほぼ被らない上、なるべく仕様変更の少ないように作業したこともあり、その程度でも問題になることは少なかったと思います。また、10月〜1月に関しては、主に地下での作業になっていたため、影響のある人に対しては直接伝える、ということも行いました。
Mercurialのコミットログ(短縮するべきではないという話をしておいたので)もそれなりの情報を伝えてはくれましたが、それでも何回か(特にあまり地下に来ない人の作業結果)は伝わるのが遅くなったりしていました。TracやRedMineのように、チケット管理みたいにするとそのようなことが少なくなるかな、とも思います。
毎週の進捗報告でガントチャートを書く必要があったのでPlannerというソフトを使っていたのですが、微妙に使いにくかったです。それでも他のソフトよりは使いやすい、というふざけたような感じでした。
ISEのバグ
ISEは割とバグバグで、僕はあまり遭遇はしませんでしたが、今年度だけでも、例えば分散RAMだと推論されるべきものがブロックRAMだと推論されたり*1、なぜかシミュレータと違う挙動を示すことが多数報告されていました。
大抵はアルゴリズムのバグなのですが、どうしてもおかしい挙動を示す場合は、ISEが論理合成時にバグらないような記述に切り替えるというクソ作業をすることになります。例えば、
- 信号の変更が複数モジュールを複雑に行き来するものを1連の流れになるように調整
- if-elseを when-elseに変える
みたいなものが挙げられるんじゃないかと。
ちなみに、モジュールを分割しないで1ファイルにだらーっと書くとなぜか論理合成に時間がかかるようになります。その方が最適化がかかりやすい! という都市伝説みたいなものがありましたが、適度にモジュールに分割するようにする方が良いと思います。
もし自分がもう一周するなら(コンパイラの追従を受けられると仮定)
- 36bit命令長にする
ノイマンアーキテクチャにするかも、という話があったので32bitにしていたが、36bitにすることになるであろう。
- FPUの出力か入力にabs/negビットを追加する
最終発表を見ていて面白いなと思った。去年のksk班もやっていたという話を聞いた。1bit命令フォーマットに追加して1bitいじるだけで1命令発行削減できるので良さそう。
- 動作周波数を引き上げる
132MHz安定動作程度まで上げたい。
- ジャンプや分岐予測のレイテンシを1大きくする
ブロックRAMの出力を利用して次クロックのアドレスを決定すると動作周波数がかなり落ちるため、それを回避する必要があるかもしれない。
- 基本ブロック内の偶数番にのみジャンプ分岐命令を配置
実行は1命令ずつのまま命令を2命令ずつフェッチし、フェッチの次のクロックでジャンプ、分岐予測をすることにより、無駄なく動作速度を上げることができるかもしれない(スケジューリングの限界が来なければ)。調整のために1命令nopを入れることになれば、ディレイスロットを分岐命令の前に移動したような感じになる。コンパイラの大変さで言えば、基本ブロックの配置の調整なども必要になるかもしれない。
- ストールの仕方の変更
動作周波数の引き上げに必要かもしれない。
- 4Wordアンブロッキングキャッシュ
実装してみたい。キャッシュ自体が動作周波数を結構下げそう。
- 1Wordキャッシュ
miss時の動作がキャッシュなしと全く同じ、動作周波数がちょっと下がりそうな以外は欠点なし。Lineあたりの幅を減らす方が速くなるとは一瞬も考えなかった。シミュレーションすればすぐできる。
思うこと
視野が狭い。かも。
まず、「スーパースカラを実装する」と当初から言っていたような気がしますが、結局「作る作る詐欺」になってしまったことは非常に悔やまれることでもあるし、不完全燃焼気味になった原因の一つでは間違いなくあると思うのです。これに関しては、自分の力を過信せず、急がず、あせらず、もっと十分な段階を踏んで実装をしていくべきだったと反省しています。むしろ、この程度の力だったのであれば、最初からスーパースカラなど掲げず、むしろスカラで高速化をガリガリやった方があるいは不完全燃焼みたいなことにもならずに済んだのかもしれません。
僕が確認を怠ったせいで、時間のない中ギリギリに時間をとってもらう、ということがおきてしまったことも、かなり反省する点だと思います。なんとかなったので良かったですが、もしなっていなかったら大変なことになっていたと思います。複数人で何かをやるときに、誰もが自分と同じぐらい時間をかけることができるわけではない、ということは今後十分留意していかねばならない点だと実感しました。
また、ウチの代はあまり高速化を本気で競う、という感じが薄かったので余興に力を入れたのですが、それも結局FPGA基板を返してしまえばプレイ不可能になり、むなしさを感じずにはいられませんでした。それだけでなく、僕は、反応を発表以降ほとんど得られなかったせいもあると思っています。つまり、去年はあったと聞いている各種部門の表彰のようなものがなかったことが大きいと感じています。なぜ今年はやらなかったのか、について教授(だったのかな?)から問われたとき「あれは面倒くさいだけだと思って」(TA)とのことでした。何がしの表彰のようなものがあれば、また感じ方も違ったのではないかと思ってしょうがありません。
あと、CPU実験の難易度に関して、高速化の方向だけでなく、設計や実装が難しくなる方向のコンテストもあって良いと思います。HWの資源が豊富になり、結構適当に作ってもそれなりの速度が出るようになっています(命令キャッシュのようなサイズのBlockRAMにプログラムが乗りきる、など)。2ヶ月程度で半分以上の班が動作させることができました。動かない班、というのも僕の予想では、設計は全体的に間違ってないけど細かいバグをとりきることができなかった、という類のものだと思っているのです。単に必要となる要素が増えるだけの煩雑化(例えば、必要なFPUを増やす、プログラムサイズが大きくなるようにする(キャッシュにのせきれないようにする))のみを行うのではなく、割り込みを実装したり例外やGCを実装しなくてはいけない、そんなプログラムが高難易度コンテスト用のプログラムとして提供されても良いと思うのです。
min-rtを本気で高速化するためには、どうしてもmin-rtに特化したコンパイラやらにする必要があると考えています(門外漢みたいなものなので良くわからないのですが)。HWに関しては、とりあえず動作周波数を引き上げるのが、いろいろ考えてFPUのレイテンシを1小さくするよりもはるかに有用です。後者とかはまあそりゃそうなんでしょうが、なんか、むなしい。僕なんかは、min-rtがただただ高速になっても、あまり、うれしくはない、です。むしろちょっと誰もやってなかったようなことをやってみたかった。だから、VGA出力できるようにして、音出せるようにして、入力できるようにして、絵を描いて、holeにプログラム書いてもらって、それでゲームを作ってみた。まあそれも終わったらむなしくなってしまったんですけどね。だって、ねえ。
難易度という点で言えばスーパースカラなんか、上で挙げたやつなんかよりたぶん高いですよね。そういう風に自分で難易度を高くすることができるでしょう。でも、スーパースカラはまだ高速化に寄与するでしょうけど、割り込みとかGCなんかは、どう考えても高速化に寄与しない。むしろ悪影響。そういうのを明確に評価する軸、というのを用意しても良いんじゃないかな、と。いまどき割り込みのないCPUやGCのないOcamlなんて無いでしょ。
やっぱり、一応コンテストという形式をとっている以上、形だけでも表彰みたいなものが欲しかったな、と思います。そうしたらCPU実験全体がまた全然違ったものとして記憶に残ったかもしれないな、と。
僕が来年度以降にかける期待
一部、班のWikiの「できたら良いかもしれないね」ページから
最後に
これで僕の書く2010年度CPU実験記は終わりです。他の人が別に書いてくれることも期待しています。
他の人と一緒にCPU実験を「クソだー」とか言ったりはしましたが、なんだかんだで僕は楽しかったです。
班員のみんな、ありがとう。
前年度までの皆さん、資料など参考になりました、ありがとうございました。
2010erのみんな、半年間お疲れ様。
来年度以降の皆さん、――もしCPU実験がこのまま続くなら――がんばってくだい。
*1:回避するためにはattributeでdistributed ramを指定する必要がある