Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
[go: Go Back, main page]
Hobby or Money?
10/28 趣味と実益


まぁこういうひとたちをひっくるめてソフトウェア・フェチと名づけてしまおう。僕も少なからず共感する部分はあるのだけど、果たして重要なのは過程なのか。過程のためには結果を無視してもいいのだろうか。





ケイ氏について



　先日、僕が去年教えた生徒のひとりと意外なところで再会した。いろんな事情で名前を明かすわけにはいかない。ここでは仮に彼をケイ氏と呼ぶことにしよう。

　彼は神楽坂にある理系大学を中退して、専門学校に入ったという変わり種だ。頭はよく、明晰だが、僕が思うに少し趣味に傾倒しすぎるところがある。

　しかし今や彼もプログラマの端くれ・・・いや、大学にだらだら通いつづけている僕なんかよりずっと立派なプログラマだ。元気そうでよかった。仕事が忙しかったのでその場はあまり話をせずに別れた。

　後日、そんな彼が珍しく学校を訪ねてきて、相談にのって欲しい 　詳しいことは言えないが、あるとき彼は仕事上の問題に直面した。とある事情から二つの開発バックグラウンドのうち、ひとつを選択しなくてはならなくなった。まぁどんな場合にでもよくあることだ。

　それについて、僕に意見を求めたいというのだ。

　ひとつは汎用性に富んだシステムで、これは長い年月をかけて高度に最適化された、実績のあるものだった。もうひとつはより原始的な開発環境だったが、ハードウェア・メーカーが直接供給していて、いかにも低レベルな作業をこなせそうに見えた。そのぶん、粗削りではあったが。

　彼の気持ちとしては、どちらかというとメーカー製の低レベルライブラリを使いたい、ということだった。

　彼は生っ粋のアセンブリ言語プログラマで、大学ではハードウェアを専攻していた。だからよりハードに密着したプログラムを組むというのは、彼にとっての理想に近いといえた。

　制御系・機械系の世界では、汎用であることはそのまま危険であることとも取られる。ハードはシステムによっちまちまちなため、必ずしも常に最適な効率を達成できるとは限らないのだ。

　彼の作ろうとしているプログラムは、純粋なソフトウェア商品であるため、彼が気にしているのは危険性よりもむしろその性能・理念についてだった。

　最高に素晴らしいソフトウェアを作るために、必要なのはハードウェアに極限まで密着したプログラムである・・・・・これはいつも真実だろうか。

　彼は言う。

　「でもパフォーマンスを考えると・・・マシン語のほうが・・・・・」
　僕はここではたと気がついたのだ。ぼくたちは思い込んでいる！と。




なぜマシン語が、ハードウェア依存が「速い」のか！？



　これまでずっと感じてきた違和感があった。それは決して拭い去ることができなかった。誰もが言う。「アセンブリ言語で書いて高速化せよ」と。誰もが薦める。「ハードを直接叩け！」と。

　なぜ、それが高速と言われたのか・・・・ずっと忘れていた。そう、それは僕らのあいだだけの常識だったのだ。

　それはBASICとマシン語しか使えなかった大昔のパソコン時代の記憶なのである。

　当時のマシンでは、BASICのような高級言語を高速に逐次実行できるほどのパフォーマンスはなかった。そのため、全く同じアルゴリズムでも、それをただマシン語(アセンブリ言語)に書き直すだけで、劇的な・・・ふつうは10倍程度の・・・高速化ができたのである。これならアセンブリ言語で書かなければ話しにならないというのは実に道理だ。

　ハードの直接駆動も同様だ。そもそもBASICにはハードウェアを直接駆動できるような部分はマシン語で直接書くのと同じ程度の機能しかない。I/Oポートへのアクセスとメモリへのアクセスが関の山だったのである。

　しかし、それも極度にBASICのオーバーヘッドが巨大なため、シビアなタイミング制御には使えない。なにしろ僕が使い始めた頃のBASICといえば、わずか1000回の空ループで数秒間が経過するウェイトになったのだ。

　また、当時は各社によってパソコンに搭載されているハードウェアがまるで違った。またそこで各社の色を出そうと努力もされていた。たとえばグラフィック関係ではGDC,GRCG,EGCなどの特殊なハードウェアを直接駆動するのとしないのとではさらに劇的な差が出た。

　当時、PC-9800シリーズの線分描画は異様に高速なことで有名だったが、それはCPUの半分のクロックで動作する超高速な(といっても2.5MHzだけど)グラフィック専用チップGDC(;Graphic Display Controler)のお陰だった。

　また、同じ頃のX68000などのマシンはスプライト機能をハードウェアで搭載していたし、FM-TOWNSも独自のグラフィック規格を持っていた。

　このように、各社のマシンの機能を「限界近くまで」引き出すには、ハードウェアを直接叩く以外の方法がなかったのである。

　そして、結果的にはハードウェアを直接駆動したプログラムが最も高速ということになる。




グラフィック



　実際、このような錯覚はつい最近まで僕も抱いていた。「マシン語でハードウェアを直接叩いたほうが速いにきまってんじゃん」と思う根拠を忘れていたのだ。

　これが根強いのは、簡単にいえば日本のパソコンの歴史が始まって以来の認識だからである。BASICやCのような高級言語=遅いという図式は、なかなかぬぐえなかった。C言語が遅いという決定的な印象を与えたのは、TurboCなのではないかと思う。

　TurboCにはBGI(;Borland Graphics Interface)という高度なグラフィックライブラリが標準でついていた。当時のグラフィック処理のハードルは高く、僕も喜んでこのライブラリを使ったものだ。

　しかし・・・・こいつが決定的に遅いのである。

　どのくらい遅かったかというと、三角錐のワイヤーフレームがまともに表示できないほど遅かった。原因は・・・・おそらくGDCを使ってないためである・・・・遅いに決まってるよね。

　そういう仕様になっていた理由は、もともとTurboCが舶来品で、BGIをAT互換機とも互換性のあるものにしたかったからなのだろう。AT互換機にはそもそもGDCのような描画アクセラレータはないので、そのルーチンをそのまま持ってきたのではないだろうか。

　僕は当時TurboCでワイヤーフレームを描画するプログラムを作ろうとしたが、あまりの遅さに愕然となった。

　そこで、仕方なく全てアセンブリ言語で3Dシステムを作った。むろん、内部ではGDCを駆動している。ただそれだけで、驚くほど良好なパフォーマンスが得られた。そういう時代だったのである。

　いまから当時のシステムを見直してみると、実にひどい内容で、よくぞまぁこんなものでゲームなんか作れたよなと感心してしまう。

　しかしそんなヒドイ内容のシステムでもかなり普通に動いてしまい、そのまま雑誌の10ページ特集記事を飾ってしまう。そんな時代だった。

　重要なのは、PC-9801のプログラミングにおいては、ハードウェアの直接駆動こそが最速で目的を達成するための手段だったことである。いわゆる「ゲームプログラミング本」にはとにかくマシン語でハードを直接駆動する方法ばかりがずらりずらりと紹介されていた。

　だがそれは過去の話だ。あくまでもGDCを直接駆動する唯一無二の方法がマシン語であったに過ぎない。また、当時のCPUはあまりに非力すぎた。
　また、マシンが変わると最適化の方法はがらりと変わる。

　これがマシン語伝説の正体だ。
　たしかにマシン語でのハードウェア直接駆動が速かったという根拠である。





汎用性はなにかの犠牲のうえにしか成り立たないのか？



　それでは近年ではどうなっているのか。これが凄く重要な点なのだが、誤解されていると感じることだ。

　それは全てのハードウェアが全体的に似てきているという現実である。そしてまったく共通したオペレーションを単位時間あたりにどれだけこなせるか・・・・そこにおいてのみ勝負している・・・。

　たとえば、これは昔からそうだけれども、あるレジスタに1を加える(x86であればたとえばinc ax)命令は、どんなハードウェアであってもそれ以外の操作はありえない。

　そしてaxに1を加えるという操作をinc ax以上に高速に行う方法は他にないのだ。

　同じようなことが、実は3Dのハードウェアにも言える。

　DirectX以降にリリースされた3DハードウェアはDirect3Dの仮想ハードウェアモデルに基づいている。だからデザインが似てくるのは当然のことだ。

　それでは例えばRivaTNTを直接駆動してポリゴンを書かせるのと、Direct3Dを使ってポリゴンを書かせる場合とでは、できることにどんな違いがあるのか？三角形の頂点を指定して、描画コマンドを送るだけである。ただそれだけだ。

　むろん、Direct3Dを使うことによるオーバーヘッドを考慮しなければ、公正とは言えない。しかし、このオーバーヘッドは一度に24頂点以上の頂点を処理する場合は無視できる小ささになる。ならばなるべく大量にポリゴン描画をバッチ処理させればいい。ただそれだけだ。

　考えても見て欲しい。もし、Glideのような専用APIが最良のパフォーマンス発揮手段であるならば、なぜRivaTNTやSavage3D,ATI Rage Proを直接駆動するAPIがないのか？それはその必要もメリットもないからなのだ。それらチップは最初からDirect3Dにフォーカスして設計されているのである。

　GlideとVoodooシリーズはもともとアーケードゲームなど、パソコンとは離れた目的のために作られた。それをパソコンから使えるようになっているのはそのときのなごりにすぎないのである。

　パフォーマンスについても、それが天と地ほど違えば・・・たとえばGlideだと1000万ポリゴンだせるのにDirect3Dだと30万ポリゴンしか出せないとか・・・大問題だと思うが、オーバーヘッドのお陰でわずかに上回る場合がときどきあるに過ぎない。

　一般にGlide対応のゲームは美しいといわれるが、そのGlide版とDirect3D版に明確な違いをいくつ見つけることはできるだろうか。



ケイ氏とおれの事情



　まぁそんな話をしたのだけれども、彼はもともとハード屋だ。結局彼はこう言った。「いやぁ。僕としてはハードウェアの直接制御が凄く好きなんですよ」結局そういうことにすぎないのかな、と思う。好き、嫌いの問題。つまり趣味・嗜好の問題だ。

　しかし僕は再び問うた。

　「好き・嫌いの問題はいい。趣味でやるのは構わない。だが、必要なのは実際性だ。君は自分の商品の品質よりも、趣味を優先するのかね？君の心のなかで速いと思って満足できれば、実際の製品がまるで駄目でもかまわないというのか？」

　そうしたら、こんどは彼はうーんと唸る。

　趣味に走るひとは、ハード嗜好のひとだけとは限らない。たとえばソフトウェア処理に拘る人・・・・なんでもかんでもソフトウェアで処理しないと気が済まない人・・・デモコーダー？・・・・他にも、OSの機能を使いたがらない人・・・・まぁこういうひとたちをひっくるめてソフトウェア・フェチと名づけてしまおう。僕も少なからず共感する部分はあるのだけど、果たして重要なのは過程なのか。過程のためには結果を無視してもいいのだろうか。

　もし彼が学生やサラリーマンなど、職業プログラマでなかったら僕はなにも言わないだろう。そもそも無関係だからだ。だが、彼は職業プログラマであり、僕の教え子だった。だから彼には僕の主張を理解して欲しい。

　「つまりこういうことだよ。ケイ君。君のやろうとしていることは単なる自己満足だ。自己満足の結果にできあがった排泄物を、君は客に売りつけるわけだ。客がそれを喜ぶのならいい。だが本当にそうだろうか。売物を作る気なら、客が満足するものを作ることが最優先だろう？客が満足する顔を見る楽しみだってあるんだぞ」

　言うなればそれは実益である。利益、ではない。少しでもプログラマとしての誇りがあるなら、自分の作った作品をけなされるのは何よりもつらいことだ。それを感受してまで君は趣味人に徹することができるのか、と。

　結局、どちらをとるかは他人が決めることではない。それでも今一度、考えてみていただきたい。果たしてあなたは趣味をとるのか、実益をとるのか・・・・。