ほんまやろか。そうやろか。

お客様のマルチスレッド目一杯使ってチューニングしているバージョンで、新しく作ったスマートポインタを試してみた。古いディレクトリを消してコンパイルしてみると通らない。調べてみると、いくつかのクラスに関して、ゲーム本体とライブラリの参照しているディレクトリが違っている。virtual関数の種類や数が違う。ランタイムデータベースのフォーマットが違う。よくこれで動いていた、と感心するような状態だ。このソースを使ってテストするのは、かなりいやだ。うまく走って、大きく改善されれば、安定していると言われているバージョンを捕まえて、追加変更後、統合作業することになる。どれが安定しているかを、はっきり把握している人は、この１ヶ月誰もいなかった。動かないけど安定に近いのを修正して、まず安定させ、その後作業することになるが、その間に元のバージョンが消え去って、統合できなくなっていたりする。改善が顕著でなければ、もうゲームには組み込まないことになる。、ということは、うまくいかない時の方がラッキー！ということか。どっちに転んでもよいような気分になってきた。

ちょこっと改善できたとよ

チューニング作業で、ループの奥の方で繰り返し使われるクラスのvirtual関数を潰していく。一番外したい場所に、テンプレートクラスを騙す魔法が使ってあり、virtual関数を外せない。がっかり。裏で何が行われているかこっそり状態をボトムアップに返すvirtual関数を消して、トップダウンで状態を残すようにした。その部分がざっくり速くなった。おかげで少し見栄えが良くなった。なんて気分良くしていると、今すぐリリースせよとの強い圧力を受ける。コンパイルさえ通れば良いとのこと。なんて乱暴な話だ。テストをQAに完全に任せるということか。騙しと魔法の組み合わせをテストできるユニットテストってなんだろう。QAに説明できない。いきなりバージョン番号をアップして、リリースしてみた。いきなり上位バージョンのコンパイル環境でコンパイルできないとのクレームを受ける。やっぱり、魔法を使うためには、起動呪文が必要だ。最初の呪文さえ唱えれば、後は勝手に魔法が別の魔法を呼びながら解決してくれる。

コンパイルとプロファイリングば繰り返しとった

コンパイルしてプロファイリングしての繰り返し。意味もなくvirtual関数にしていたところとかが思いっきり足を引っ張っていた。こうやってどんどん継承クラスを使う意味が減っていく。このレベルでチューニングを進めていると、もうAllocとかFree止めたらという気分になるが、実際関数の中では、とっくの昔に止めていて名前だけになっている。もうinline関数だってオーバーヘッド扱いだ。どんどん定義に代えちゃえという意見もいまさらながらに噴出。次世代機では、こういうことなんか考えなくても良かったのでは、という根本的な疑問が沸々とわいてきた。マルチスレッド使ってるけど、こういうレベルの作業をしている世界ではmutexの生成が大変なオーバーヘッドだし、生成数を制限するとロックの致命的なオーバーヘッドが増えるし、仕事が滅茶苦茶増えている。

魔法対魔法の戦いやったとよ。

ヘロン湖畔にて、と言っても池だが。遠くに小さく白く見えているのはウェディングドレスを着た花嫁さん。

魔法のような方法でC++的にタイプを保持しつつ、自動で型の無い状態から復活させることはできたが、RTTIからオブジェクトを検索して生成するというとんでもない魔法を使っているところを発見。結局１００個以上のファイルを変更することになってしまった。まったく健康に悪い仕事だ。とりあえずコンパイラは通ったが、水面下でのテンプレートとC++の戦いを把握している人はいない。AI周りでバグがでたら大変なことになると予想され、その予想は大抵当たる。

テンプレートは魔法んごたるばい。

テンプレートでいったんvoidに変換されたクラスへのポインタを、型なんだか判らなくなるほど遙か彼方のオブジェクトで復活させるというboostの手法を解析してみた。全く魔法のような使い方をしている。早速、こちらのスマートポインタに実装してみた。boostより２．５倍速い。うれしい。