challenge ciphertext

そこでCPUは3次元の仮想空間に存在する仮想物体に対して適切なライティング計算とトランスフォーム計算を行い、その結果を二次元のポリゴン情報(正確には2次元ではなく、透視変換された三次元の同次座標ですがそれは割愛)としてGPUに送信するとGPUがシコシコ描画してくれるという仕組みになっております。

それで皆さん、さすがにGPUの領域は手を出さないのですが、CPUでやる計算くらいは自分たちでやったほうがいいと強く信じて疑ってなかった訳です。

それで僕は言いました。

「ええと、このCPUには4×4行列を高速に計算できる回路がついてるのですが、某社さんのライブラリだと、わざわざ3×3行列で計算したあと足し算やかけ算をして表示していますね。当社のAPIの場合、内部で必ずトランスフォームの計算を4×4行列でやっています。これをわざわざ整数で計算したりしたとしても、最終的には必ずAPI内部で4×4行列を使うので皆さんが自力で計算しようとすればするほどパフォーマンスは落ちる事になってしまいます。ですから、そういう計算はせいぜいライティングくらいに止めてください」

誤解されそうなので補足しておくと、この場合、このAPIが必ず4×4行列の計算を挟むのが無駄という意味ではなく、ハードウェアの都合上、必ず描画前に4×4行列の乗算が必要なのであり、しかも全ての行列による座標変換と平行移動と拡大縮小は単一の4×4行列に集約できるというのは数学的公理であったので、これと別に3×3行列の乗算と3座標の加算を行うのは冗長以外の何者でもなかったのです。また、このハードでは整数よりも専用レジスタを使用した浮動小数点数の方が演算が速かったということも付記しておきます。

余談ですが、あるときこういうセミナーをやった直後にとある大手メーカーのプログラマさんからクレームの電話が来たことがあります。

「おいおまえ、偉そうに説教してくれたな。けれどもこっちはお前の言うようにプログラムを組んだが、秒間1万ポリゴンしか出ないぞ。適当なことを言ってるんじゃねえ!」

すごい剣幕でしたので、そのコードを送っていただくことにしました。

どうもこのプログラマさんはその会社では1,2を争う凄腕らしく、本人も相当なプライドがあったようです。僕らも大手メーカーさんに見捨てられては大変だと緊張感が走りました。

で、やってきたプログラム。確かにとてもシンプルなので、これで速度が出ないなら、どこで出すのだ、という感じではあるのです。

しかもかなり複雑なビット演算をやっていたり、ポリゴンを読み込んだ後でプログラムの形に展開して、そのコードを実行すれば自動的にポリゴンが描画される、なんてかなり高度なことをやっていました。高度なことをシンプルなコードで書く。まさに芸術です。

果たしてそのプログラムを実行してみると、確かに遅いのです。

最適化はループの内側から、ということでそのプログラムの内側を眺めてみました。

そのプログラムの内側は、プログラムとして展開された怒濤のようなコードを実行する部分でした。

待てよ、と思って僕はそれを会社が提供している標準的なAPIに変えてみました。

するとプログラムは易々と10万ポリゴンまで速度をあげました。あまりに沢山展開していたため、コードキャッシュに乗り切らず、常にキャッシュミスを引き起こしていたのです。メガドライブなどの旧世代機では有効だったかもしれないテクニックですが、普通の32ビットマシンでは邪魔なだけです。

とはいえ、それにしてもまだ遅すぎます。

さらに注意深く見ると、どうも、毎フレーム事にフレーム数を表示しています。

ゲーム機における文字の表示というのは、作った事があれば解りますが、かなり煩雑で面倒な処理です。

この方は、それが煩雑で面倒だったために、標準のAPIを使ってフレーム数を表示していました。

遅い訳です。

さらに悪いことに、このコードは毎フレームごとにホストコンピュータへ情報を送っていました。

ホストとの回線速度は、当時でも衝撃を受けるほど遅いスピードだったので、根本的な原因はこれでした。

それで僕は、その部分をふたつコメントアウトして、メールに返信しました。

「ソースに不可解な点がありましたのでアルゴリズムには手を加えずに修正しました。こちらでは秒間70万ポリゴンと計測されましたが、測定方法によりバラツキがあるため、もし返送したコードでも1万ポリゴンしか出ないようであれば、機器の故障である可能性があります」