Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.dyendignify(2008-08-18 10:20)
2.Dominic(2008-06-23 05:05)
3.CheapestCheapOEMoem(2008-06-17 03:00)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
ソフトウェアを作るという商売をしていると、良い製品とは何だろうか？ということがどうにも気になる。コンピュータソフトウェア製品の品質指標としては、 既にISO 9126なんていうのもあるし、他にも探せばマーケティングの分野あたりから山のように見つかるのだろうが、ここはあえて自前で使え る、ミもフタもないくらいに単純な物差しが欲しい。既存の評価基準は一旦忘れて、勝手に考えるとどのようなものが出来るだろうかということで、試しに一つ 作ってみることにした。
■ 作ってみる
ソフトウェア、ハードウェア、あるいは両者を組み合わせたシステムという製品を買ってもらうには、そもそも製品に価値(value)がないといかんのだろ うな、価値を示すには低コストであることと、高パフォーマンスであることをアピールする戦略があるよな、コストを具体的に表現するとこうなって、パフォー マンスを具体的に表現するとこうなって…細分化しすぎてワケが分からなくなった、単純化しなければ…と、ぐ ちゃぐちゃいじっているうちに、下のような怪しげな表（図？）ができた。作っているときには意識しなかったものの、出来上がったものを見るとちょっとQFDの風味も入っているようだ。
| 価値 | コスト | 安価 |
| 容易 | ||
| パフォーマンス | 高速 | |
| 安全 | ||
| 安定 | ||
| その他 |
表中、右端の各項目について簡単に説明する。まずは「コスト」の項。
続いて「パフォーマンスの項」。
う〜む、「安全」と「安定」は一つにまとめて、「高信頼」という項目にしても良いのかもしれないが、「安全」には既に複数の意味がくっついているからなぁ …今はこのままにしておく。あと、対象の品によっては「カッコ良い」、「面白い」などの、ワイルドカードとも呼ぶべき項目が追加さ れるべきかも知れない（これがないとiPodやゲーム類がカバーできない）が、これらはすべて「その他」の項として表現している。いずれにせよ、上の表は まだプロトタイプであるということだ。
■ 使ってみる：Blue GeneとMac miniをネタに
さて、典型的な製品では、上記の物差しに挙げた項目のうち1つか2つを利点としてアピールし、その一方で（意図的かそうでないかにかかわらず）1つか2つ の項目を犠牲にする（で、そこはカタログには書かない）、というアプローチがとられていることが多いようだ。ここはIBMのBlueGeneとApple のMac miniをネタに一つ話をしてみることにしたい。
Blue Gene(/L)はIBMの誇る並列型スーパーコンピュータだ。最 大プロセッサ数65536構成で136.8TFlopsという世界一の計算性能を誇る。お値段は…1億ドル。 そしてそのパフォーマンスを最大限に発揮するのは生半可で無いほどの手間がかかるという、そういうシステムである。
片やMac miniは 「Macintoshがこんな値段で買えるのか」と思わせる低価格と、Mac OS Xの使い勝手の良さ、さらにWindowsマシンでのキーボードとマウス、ディスプレイがそのまま使えるという移行容易性でアピールする。ただしプロセッ サのスペックは他のMacと比較するとやや落ちるし、内 蔵ハードディスクのパフォーマンスはかなり犠牲になっているようだ。
それぞれの製品が力を入れている部分、犠牲にしている部分を表にしてみるとこんな風になる。いずれにせよ想定するユーザ層が全く違うので、両者を対比する ことは当然できないが、あえて極端なケースとして並べてみた。
| Blue Gene | Mac Mini | |||
|---|---|---|---|---|
| 価値 | コスト | 安価 | × | ○ |
| 容易 | × | ○ | ||
| パフォーマンス | 高速 | ◎ | × | |
| 安全 | ― | ― | ||
| 安定 | ― | ― | ||
| その他 | ― | ― | ||
■ 最後に
ということで、割と乱暴に作った表であるものの、とっかかりとしては思ったよりも悪くなさそうだ。こういった視点からいろいろなカタログや仕様書を眺めて みるのは結構面白い。また冒頭で述べたように、これを、既存の評価基準と比べてみる、というのもいいかもしれない。ちなみに、ここ最近話題にしている、コンポーネントに関するネタにも使えそう…かどうかはまだわからない（イケそうな気はなんとなくするが）。
今までは適当なプログラムをコンパイルし、その途中経過から、レジスタ間の干渉グラフを求めていた（2005年4月3日のエントリ参 照）のだが、レジスタ割り付けのアルゴリズムの動作確認をきちんとやろうとするならば、テスト用の干渉グラフを自由に生成できる方が良い。ということで、 そのための生成プログラムを作ることにした。できあがったのがこちら。
上記プログラムの中にある"genDummyGraph"という関数に、ノード数、干渉が起きるノードの組のリスト、「生存区間の合 併」の候補となっているノー ドの組のリスト、という4つのパラメータを渡すと干渉グラフが出来上がる。例えば
genDummyGraph 4 [(0,1),(0,2)] [(0,3)]
を実行した結果生成される干渉グラフはこんな感じ：
後はこの要領でテスト用の干渉グラフを作っていけば良い…はずであるが、さて。
今日は、7月6日の日記で 書いた
コンポーネント化というのは半端で無いほどの開発資源の投資を伴う割に、かなり後にならないとその効果が目に見えな いという点で、非常に大きなリスクを伴 う、一種のギャンブルであるとも言える
というの話の続きを。
■ コンポーネント化のコスト
まず「半端で無いほどの開発資源の投資」とは何を指すかについて整理してみる。下の図はソフトウェアエンジニアリングの古典としておな じみ、Fred Brooksの"Mythical Man-Month"（日本語題は「人月 の神話」）の一章"The Tar Pit"から引っ張ってきた図。
この図が言おうとしているのは、
ということ。ちなみにこの本が書かれたのは今から30年前（1975年）という大昔である。「3倍」とか「9倍」という数字が妥当であ るかは議論の余地もあるだろうが、個人的な経験からすると、この値は今もなお、かなりいい線を行っているように思える。
さて、上の図が妥当なモデルであると仮定した場合、コンポーネント化というのは『プログラム製品』を『プログラミングシステム』へ発展 させる作業である、ということになる。ということで、工数は3倍、あるいはそれ以上（手持ちの製品において『プログラム』から『プログラム製品』への移行 が不十分である場合）となる可能性が出てくる、というワケだ。
これだけでも大変な負担であるが、さらに野心的な目標、つまり自前のコンポーネントアーキテクチャを打ちたてようとした場合において は、その負担はさらにハネ上がる。1990年代を通じて、MicrosoftはCOMとその発展形、Netscape はXPCOM、 ジャストシステムはJOCAと、 それぞれオリジナルのコンポーネントアーキテクチャを立ち上げようとしていたが、これらのケースでは
という二つのハードルを超えなければならない。ちなみにNetscapeはこれらに加え、「Javaによる全面的な再実装」まで同時に行おうとしてい た。さすがにここまで来ると「野心的」を超えて「無謀」と呼ぶべき域に入り込んでいた、と言えるのかも知れない。
■ コンポーネント化によって得られるパフォーマンス
ではこんなに大きな工数を掛けて（賭けて?）手に入るものとは何であろうか。
製品間での共有型再利用による効果
コンポーネント化によるプログラムの再利用と共有が実現出来れば、工数の削減が可能になる、ということは良く言われる。代表的な例とし ては、複数の製品で共通した機能を切り出し、コンポーネ ント化するというのが挙げられるであろう。Microsoft Officeに含まれるWord, Excel, Powerpointなどの各製品において、コ マンドバー、Office アシスタント、ファ イルダイアログ、ス クリプトの操作、などの機能が共通化されていることはご存知の通り。これは一つに、各製品で重複した開発を行わないことによる工数削 減効果を期待したものであると言える。
一方NetscapeはVersion6.0で、HTMLのレンダリングエンジン部分をコンポーネント化し、ブラウザ (Navigator)、メーラ(Messenger)、HTMLエディタ(Composer)、プッシュ型配信クライアント(Netcaster)など で共有させようとしていた。無論Netscape CommunicatorのVersion4.0で既に、これらの機能は単一の製品として全て含まれてはいたのだが、実際のところは…
1997年から1998年にかけて、ネットスケープの製品群が抱えていた深刻な弱点として、クライアント機能担当 チームの開発者たちが、十分にモジュール化されていないコードを大量に共有していたことが指摘される。これにより生じたスパゲッティコードが原因で、各 チームが独立してビルドやテストを行ったり、または各コンポーネントを独立した機能を持つ製品として（個別に）リリースすることはほぼ不可能となってい た。
("Competing on Internet Time" p.202, やさぐれ訳)
といった具合に、コードレベルでの共有が開発の進行を逆に阻害していたようである。これをインタフェースのきちんと定義された、コン ポーネントレベルの共有に切り替えることにより、「お互いの足を踏むことなく」各機能の開発チームが作業を進行できるようにすることを目論んでいた、と言 えそうだ。
上に述べたMicrosoftとNetscapeの両者の例において、まず共通しているのは複数の製品が関係しているという点だろう。コ ンポーネントを共有するような製品を数多く持っているようなところでは、当然のことながらコンポーネント化による効果は大きくなる。裏を返せば、単一の製 品しか持たない場合にそれをコンポーネント化しても、コンポーネントの共有による工数の削減というものは期待できない。
バージョン間での再利用による効果
また、コンポーネント化では「バージョン間での再利用」と呼ぶべき効果も期待できる。プログラムを明確なインタフェースにより切り分け れば、（理想的には）前バージョンからそのまま引き継いだ「再利用」コンポーネントと、新規コンポーネントを組み合わせることによるスムーズな開発が実施 できる（はずである）、ということ。
1996年9月に発売された一太郎7は"JOCA(Justsystem Object Component Architecture)"によるコンポーネント技術を採用していたが、次のバージョンである一太郎8は、そのわずか5ヶ月後の1997年2月に発売さ れている…実はこの後に「これはバージョン間の再利用の良い例であろう」、と続けるつもりだったのだが、一 太郎8が発売された当時の「がんばれ！！ゲイツ君」の記事などを見た限りでは、どうも少々怪しそうだ。ということでこの件に関する見 解はしばらく保留しておく。
このようなかたちでの再利用を実現するためには、バージョンが変わった際にコンポーネント間のインタフェースに不整合が出ないような仕 組みが必要となる。Microsoft COM (Component Object Model)は、これを最重要課題の一つとしてとらえており、コンポーネントを提供す る側と、コンポーネントを使用する側の間で、期待するコンポーネントのバージョンが異なっている場合にも問題が発生しないよう、さまざまな工夫がこらされ ている。
なお、当然ながらバージョン間での再利用は、コンポーネント化をした後のバージョンでの製品開発において初めて有効になる。コンポーネ ント化を行った最初のバージョンで掛かったコストを、次バージョン以降で回収していくというカンジと言えば良いだろうか。無論、その間にコンポーネント アーキテクチャが根本から変更されてしまったりすれば元も子もなくなるため、コンポーネントアーキテクチャを新しく作る際には、なるべく長期にわたり使えるよう なものを考えなければならない。コンポーネントアーキテクチャを設計する人々の苦労は増える一方である。
(つづく)
