性能評価

29

る。ここでは、#pragma loop count (16) などと SIMD レジスタサイズより大きくすればよ い。

最後に、型変換が自動ベクトル化できない制約を解決するための処理をおこなう。画像 処理では、入力画像の符合なし 8 ビット整数で表現される画素を入力とし、符合付き 16 ビ ット整数などで計算をおこない、計算結果を再び出力画像の符合なし 8 ビット整数の画素 に戻す型変換が必要となる。この後半の型変換が、想定したコンパイラでは自動ベクトル 化できないという制約がある。そこで、計算結果を一時保存する 16 ビット整数型の型変換 解決用の配列を用意し、そこへ代入するようにする。これにより、その代入の処理までは 自動ベクトル化できない型変換が入らなくなるため、自動ベクトル化が可能となる。型変 換解決用の配列から出力画像にデータをコピーする後続の処理のみが自動ベクトル化され ないようになる。

30 function img = prewitt(M)

Type({[1080,1920],'uint8'},M); % input image type Type({[1080,1920],'uint8'}); % output image type base = [-1, -1]; step = [1, 1]; size = Size(M); esize = [3, 3];

img = Map(@f, MExtract(M, base, step, size, esize));

end

function ret = f(m) v = [ 1, 1, 1;

0, 0, 0;

-1, -1, -1];

h = [1, 0, -1;

1, 0, -1;

1, 0, -1];

p = abs(Sum(h .* m)) / 2 + abs(Sum(v .* m)) / 2;

if p > 255

ret = 255; % saturated at largest possible value else

ret = p;

end end

図 2.10. MExtract2Extract 変換前の Prewitt フィルタプログラム

P = (abs(Extract(M, [-1, -1], Size(M)) + Extract(M, [-1, 0], Size(M)) + Extract(M, [-1, 1], Size(M)) - Extract(M, [1, -1], Size(M)) – Extract(M, [1, 0], Size(M)) - Extract(M, [1, 1], Size(M))) ./ 2) + (abs(Extract(M, [-1, -1], Size(M)) + Extract(M, [0, -1], Size(M)) +

Extract(M, [1, -1], Size(M)) - Extract(M, [-1, 1], Size(M)) – Extract(M, [0, 1], Size(M)) - Extract(M, [1, 1], Size(M))) ./ 2);

図 2.11. MExtract2Extract 変換後の Prewitt フィルタプログラム

31

評価環境は、表 2.1 の Core 2 Quad を用いた。また、C コンパイラには、Intel C++ コ ンパイラ 10.0 を用いた。コンパイルオプションは、-ipo –xT -O3 を用いた。-O3 は、高速 なコードを生成する-O2 の最適化に加えて、スカラー置換、ループのアンロール、ループブ ロッキングなど強力なループの最適化およびメモリアクセスの最適化をおこなう[126]。ま た、対象のプロセッサを指定する-xT はベクトル化のためのオプションで、SSSE3 命令、SSE3 命令、SSE2 命令、SSE 命令を生成する。

ベクトル化およびマルチコア並列化の効果を図 2.12 で確認する。速度向上は、Extract() への変換を行わない場合の実行時間(図中の MExtract(AutoVec)) を基準としている。

Extract()への変換までをおこなった場合を Extract(AutoVec)、同変換後にコンパイラヒン トを挿入した場合を Extract + CH(AutoVec)、さらに 4 コアで並列化した場合を 4core で 示す。また、比較のために、Intel C++コンパイラのイントリンシックを使ってベクトル化 をした場合を Extract(Intrinsics) と示す。

Extract()への変換を行わない場合、ループの最適化やベクトル化のコンパイラオプショ ンを使用しても自動ベクトル化はできなかった。最内ループの回転数が短いため自動ベク トル化がでなかったのためループの展開ができなかったと考えられる。Extract()への変換 までをおこなった場合でも自動ベクトル化はできなかったが、ループオーバヘッドが減っ たことやフィルタ定数との必要のない演算が減ったことで、それぞれ 3.3 倍、5.8 倍、8.9 倍の速度向上を得ることができた。

同変換後にコンパイラヒントを挿入して自動ベクトル化することで、それぞれさらに 1.4 倍、2.4 倍、2.6 倍の速度向上が得られることが確認できた。自動ベクトル化しない場合 は、1 画素単位で処理が行われる。これに対して、自動ベクトル化した場合では、4 画素 単位で処理されるようになる。ラプラシアンフィルタの例では、4 バイトのロードが 9 回実 行され、それぞれがパックドダブルワードに変換された後、パックドダブルワード同士の 演算が行われる、4 並列のベクトル化がなされる。

一方で、イントリンシックを使った場合との比較では、それぞれさらに 1.4 倍、1.3 倍、

2.0 倍速度向上できる余地を残していることがわかる。イントリンシックを使ったもので は、パックドワードでの 8 並列のベクトル化を行っている。自動ベクトル化の場合に 4 並 列になっているのは、現状の処理系で、プログラムの処理過程で必要な中間値の型を C++

のデフォルト型変換ルールに従って素直に決定しているためである。そのため、本来は 16 ビット整数でビット長が足りるところを 32 ビット整数を利用している。また、データ転送 は、16 バイトで転送をおこなった方が効率がよい。このため、イントリンシックを使った ものでは、16 画素分に相当する 16 バイト のロードを 9 回おこない、レジスタ上で上位ビ ットと下位ビットに分けて計算し、結果を合成してから再び 16 バイトでストアしている。

このような細やかなベクトル化が、自動ベクトル化では難しいことも性能差に影響してい る。

32

最後に、4 コアでの実行では、それぞれ、3.4 倍、3.0 倍、2.5 倍の速度向上が得られ ることが確認できた。

図 2.12. ベクトル化および並列化による速度向上

本配列処理言語のアルゴリズムレベル情報を利用した簡単なプログラム変換と、C コンパ イラの自動ベクトル化を組み合わせることで、近傍処理アプリケーションが SIMD 命令を直 接記述することなくベクトル化できた。これは、本配列処理言語がアルゴリズムレベル情 報が取得しやすくなっているために、複雑なデータ依存解析などが不要になり、処理系で 容易に最適化ができるという本開発方式の有効性の一端を示すものであると考えられる。

配列処理言語の処理系と C コンパイラの役割分担という観点では、ベクトル化は C コン パイラに任せることができるようになるのが望ましい。今後 C コンパイラの解析能力やベ クトル化機能が強力になりそれが可能になれば、配列処理言語の処理系の開発コストを軽 くでき、その分、C 言語のような低レベル言語が入力となる C コンパイラの解析能力では手 が届かない高位プログラム変換機能の開発に注力することができる。

その一方で、コンパイラの自動ベクトル化は不連続アクセスに未対応など未だに制約が 多い。今後は、さらにベクトル化できる範囲を拡大することも必要であるため、コンパイ ラの自動ベクトル化の進歩にも期待しつつ、処理系で SIMD 命令の一部生成もおこなってい る[110]。その際には、ベクトル化の並列度を上げるためにビット長推論をおこないさらに

33 効率の良いベクトル化をすることが重要である。

2.4 高位プログラム変換を利用した自動チューニングによる並列 C