「C++ Composer XE 2011」ベンチマーク記事の隙が大きすぎて、アーキテクチャ批評が書けない
Sourceforge Magazineのデベロッパー向け記事にアセンブラコードで見るC++ Composer XEの強力な最適化機能がリストされています。さて、その記事、SSEの性能評価をしてやろうかと思ったらそれ以前の問題で膝を折りたい気分です。
一例は2ページ目
シンプルなベクトルの内積計算を行わせて、その生成コードをIntelコンパイラとVS2008のコンパイラで比較しようとしています。
プログラムはこんな感じ（リスト1より引用）
int i;
float a[128];
float b[128];
float d;
：
：
d = 0.0;
for (i = 0; i < 128; i++) {
d += a[i] * b[i];
}
printf("%f\n", d);
：
：このコードからIntelコンパイラは4並列浮動小数点演算を行うSSE命令をびっちりと出力してその実力を見せつけています。DSP屋としてはSSEに並列ロードストア命令がないのが不満ですがIntelやAMDのx86はスーパースケーラーの力業で命令を並列化しますから、そこはあまり問題ではありません（そういう事にしておきます）。
一方のVS2008コンパイラはFPUを使ったスタックコードをこれもびっちりとはき出します。
勝負あった、と思いきや、100万回実行した結果はこんな感じです（表4より引用）。
| コンパイラ | 実行時間 |
|---|---|
| インテル C++ Composer XE 2011 | 9.325秒 |
| Visual Studio 2008 | 9.722秒 |
ええええ？って、1MACに170サイクル以上かけていますから、明らかにprintf()の時間まで含んでいます。「ここで使用しているコードはシンプルであるため軽微な違いしか見られないものの、SSEを利用することによるパフォーマンス向上が確認できる」と記事にはありますが、少々すっとぼけた過ぎていないでしょうか。何のためにアセンブリ出力まで引っ張り出して比較しているのかと問いたださずにはいられません。
うがった見方をすれば、フォン・ノイマン・ボトルネックのために思ったほど差が出ない事を隠蔽するためにprintf()を取り除かなかったとも考えられます。
MAC演算は信号処理の基本演算であり、SSEがどの程度の性能向上をもたらすか興味があるのですが、残念ながらそれをえぐり出す鋭さはこの記事にはありませんでした。
Intelコンパイラはお試し版があるそうですが、わざわざダウンロードして調べるほど興味があるわけじゃないんですよね。
