C++の高速化は言語選びでは決まらない、データ指向設計がカギ

この記事は、2000年代に私が見始めたパフォーマンスに関するアドバイスを思い出させる。要するに、アルゴリズムの複雑さを下げるためにポインタを多用したデータ構造を導入するなということだった。すべてをベクターに詰め込め。コンピュータサイエンスの教科書では遅いと言われるアルゴリズムを使うことになるかもしれないが、すべてがキャッシュに収まるなら問題ない。ポインタをあちこち追いかけるキャッシュミスの方が、はるかに痛い。

ここでついでに、GCが関与する場合のデータ指向設計に関するリソースを誰か見たことがあるだろうか？データ指向設計の多くはアリーナに焦点を当てているが、コードのライフタイムモデルが（何らかの理由で）GCを必要とする場合、常にそれが可能とは限らない。

DoDムーブメントはシステムプログラミングのやり方を変える、ゆっくりだが大きな変化だと思う。しかし、さまざまなシナリオでこれをどう適用するかについての資料はまだ不十分だ。私の仕事の分野（これもC++）にもっとこれを適用したいのだが、提示されている内容と実際の適用方法の間にギャップがあるように思う。

具体的には、私はC++を使ってClojure方言の動的プログラミング言語ランタイムを構築している。そのランタイムはガベージコレクションされ、型消去され、高度に多相的であることが要求される。だから、すべてを単にSoAやAoSにすることはできない。確かに、データをパックできるし、コンパイラ/ランタイムコードと、エスケープ解析を通じて生成されたコードの両方で、可能な限りGCを避けることもできる。しかし、システムの80%以上を占めるその他すべてはどうだろうか？このランタイムはDoDとは相容れないかもしれないが、私は物事を白黒ではなくグラデーションとして見ている。

分岐予測やコンテキストスイッチ、同期については一切触れられていない。何をしているかによっては、それらが非常に重要になることもある。スレッドによる並列化とSIMDについてはごく簡単にしか言及されていない。

高性能プログラミングは大きなトピックだ。単一のブログ記事には範囲が広すぎるため、C++とコンピュータアーキテクチャについて自然と表面的な議論しかできない。記事は悪くないが、形式が間違っていると思う。ブログシリーズか、いっそ本の方がふさわしい。

私はほぼ毎日C++で書いているが、速度を最適化する必要を感じたことはない。素直なコードを書いても、すでに驚くほど速い。

「この記事は元々ポーランド語で2013年4/2013号に掲載された」— 素晴らしいアドバイスが多い。C++がここ10年で、効率的でシンプルな低レベルコードを書くのをどんどん難しくする方向に進んでしまったのは悲しい :(

ほとんどの場合、パフォーマンスの向上はごくわずかで、コードは単により複雑になっただけだった。

「早すぎる最適化は諸悪の根源」

私の最新のC++プロジェクトは、保険のリスク計算など様々なアクチュアリー関連をカバーする評価エンジンだ。バルク計算の典型的なパフォーマンスは、16コアサーバーで毎秒数百万から数千万の評価に達する。まあ、そこにはトリックがあって、内部でDSLからルールをJITコンパイルして実行可能コードにしている。インタプリタモード（主に監査モードで使用）は約3〜5倍遅いが、それでもめちゃくちゃ速い。