CPU実験まとめ

CPU実験

CPU実験とは大学の演習の一つで、その名の通りCPUに関係する様々なことを班単位で実験するもの。演習としての最終目標は

• 班ごとに設計したCPUで
• 定められたプログラムが
• 定められた入力を
• 正しく処理できるようになること

で、それとは別に、処理の速さなどを競うコンテストが春休み期間中に開かれている。

今年は例年通り

• SLDというフォーマットのモデリングデータを受け取って(定められた入力)
• レンダリングするレイトレースのプログラム(定められたプログラム)

を正しく処理できるCPUを班ごとに作るよう指示され、3/11にコンテストが行われた。

役割分担

一学年が5-6人ごとに5つの班に分かれた。僕の班は5人で、結果的に、ハードウェア・コンパイラ・シミュレータとライブラリとデバッグ・ソフトウェアと遊撃・UIと入力データ、というふうな役割分担になった。

僕は最後の「UIと入力データ」、つまりソフトウェアや発表の見た目をデザインしたり、レイトレーサに食わせるモデリングデータを生成する役。一時期シミュレータの手助けをしたこともあったが僅かで、実は一番CPUから遠いところを担当していたことになる。

CPU実験においてCPUから遠いところを担当するためには、班としてその他の核となる部分に対して十分に力を割けていることが必要条件になるが、その点、僕の班は心強かった。

最後に時間切れとなった部分があるので、今さらながらもう少し他の分野で助力できていたら、と思うこともあるが、班全体の目標は「(今の実験基板を使うCPU実験が今年で最後なので)何か面白いことをやりたい」だったので、その意味では何とかなったと思う。

班としての成果

近々に発表資料を公開する予定なのでお待ちください。

UIと入力データ

僕が担当したところについて、もう少し詳しく書けることを書く。

rtcad

まず、入力データ、つまり3Dのモデリングデータは数値の羅列で構成されるデータであり、とても直感的に扱えるものではなかったので、それをGUIで表示・編集できるソフトウェア「rtcad」を作った。データの文法ミスが怖かったのでパーザ・文法チェッカなど、入力データを正しく便利に作成するために必要になると思しきほとんどの機能を実装してある。

発表資料公開に併せてrtcadと取り扱い説明書を公開予定です。

その他UIなど

また、実験基板で動かすレイトレース以外のソフトウェア(テトリス)の背景を描き、半年を通して発表用資料の作成に当たった。後半の仕事は丸っきりデザイナーであり、プログラムとはあまり関係ない。

感想

とりあえず

この班にいられて幸せだった。学ぶことが多かった。

• ソース管理と情報共有はSubversion+Trac+地下詰めで完璧だったと思う。
  • Trac最強説
  • いつ地下に行ってもたいてい班員がいる環境は異常に快適かつ安心。
• 各人の管轄がかなり独立した状態で、班内で共有すべき情報と一人で抱えるべき情報をそれぞれが判断していた。
  • VHDL記述はほぼkoiken氏
  • Haskell記述はほぼmad氏
  • HSP(によるrtcadの)記述はarc
  • e.t.c.
  • 役割分担することによる利点もあったろうが、この班の場合、責任の所在が曖昧になることなく緊張感を持って作業が続けられた。情報共有にあまり労力を割かずに済んだ功利も大きい。
• 各人が各々の得意分野を尊敬し合っていた。
  • 僕から見て
    • ハードウェアに関する見地でkoiken氏すごい(FPGA基板の中が見えていそうだ)
    • コンパイラに関する見地でmad氏すごい(ソースの変換過程がいちいち見えていそうだ)
    • レイトレ、シミュレータのプロファイリングに関する見地でLuna氏すごい(バイナリの実行過程をいちいち追えていそうだ)
    • ソフトウェアに関する見地やバイナリレベルの編集でmagicant氏すごい(ソースの特性やバイナリの中身が見えていそうだ)

実験を通して考えたこと

UIとかデザインって、最低限の部分は機能として考えられるのに、それ以上は機能と切り離されてデザイナの領分になるという不思議な性質を持っている。そのために、業務用に特化したソフトウェア・アーキテクチャではUIへの配慮なんてなくてもいいものとして考えられることさえあるけれど、実際のところ、その考えかたには違和感を覚える。

そうではなくて、ある目的に特化したソフトウェアでは、目的が限られているためにUIへの配慮が機能の制約で代替されていることが多いのだと思う。つまり、やれることが少ない代わりに・やれることが少ないゆえに、細かく色々なパラメタをいじる必要性にも乏しいのではないか。

また、UIやデザインが軽視されるのは恐らく今のPCの入力インターフェースの乏しさにも起因している。結局のところどのPCにもついている入力はキーボードとマウスくらいのもので、人間の手は2本あるのにマウスは一つ。PCの操作に熟練した人が2本の腕をフルに使えるキーボードで操作するCUIを好むのは当たり前だ。PCへの入力の局面でもどかしい思いをするようでは、GUIによる出力はやむなく軽視される結果となる。

Wiiの拡張デバイスが全部BluetoothでPCと繋げられたり、MacBook AirやMacBook Proがマルチタッチデバイスを搭載したり、PCの入力に使えるチャネルは着実に、少しずつ増えてきている。昨今携帯電話を使ってPC向けサービスを拡張する試みが多いが、ある意味入力装置に乏しいPCの世界に携帯というインターフェースでアクセスしているとも取れる。

今後どのようなデファクトスタンダードが生まれるのか分からないが、ソッチのほうに期待と興味を持っている一人として、今後の成り行きに注目していたい。

あれ、CPUからかけ離れた話になってしまったぞ。高速化という観点では、PCの操作を高速にできるようにするというこじつけも可能か？処理速度が何倍に向上してもキーボードの入力速度はそんなに速くならないものネ。

• 同期のCPU実験関連エントリへのリンク
  • suztomoの日記
  • mad日記

タグ: 学科 CPU
固定リンク | トラックバック(0) | はてなブックマーク(0)