DGEMM のバグを探すことができた。やはり Cell プログラミングでは、デバッグが容易ではない。いい加減デバッグツールを使わないとまずいのかもしれない。。
ちなみに今回のバグは調子に乗って2行ずつ演算を行っていたために起きたのだが、その部分を1行ずつにするだけで正常に実行できた。しかし、実行時間がかなり増えてしまっている。
また、xlc コンパイラも試してみた。
以下は 512x512、1024x1024、2048x2048 においての xlc/gcc の性能比較である。
もちろん Double Buffer は用いていない。これにより、xlc は gcc よりも Cell に最適化され、かなりの速度向上が見られるとした期待を裏切ることとなった。しかしまだまだなにも最適化しているわけではないので、Double Buffer 等の改善を加えた後もう一度比較してみるとよいだろう。
ちなみに Makefile に次のように追加するだけである。
PPU_COMPILER = xlc
SPU_COMPILER = xlc
xlc -O3 / gcc -O3 [msec]
SPE 512x512 1024x1024 2048x2048
1 1148/795 8700/6010 16100/47400
2 600/430 4600/3170 36300/24500
3 425/310 3150/2240 24500/16900
4 330/245 2420/1730 18800/13200
5 280/210 2020/1460 15500/11000
6 245/190 1710/1270 13200/ 9700
ちなみに今回のバグは調子に乗って2行ずつ演算を行っていたために起きたのだが、その部分を1行ずつにするだけで正常に実行できた。しかし、実行時間がかなり増えてしまっている。
また、xlc コンパイラも試してみた。
以下は 512x512、1024x1024、2048x2048 においての xlc/gcc の性能比較である。
もちろん Double Buffer は用いていない。これにより、xlc は gcc よりも Cell に最適化され、かなりの速度向上が見られるとした期待を裏切ることとなった。しかしまだまだなにも最適化しているわけではないので、Double Buffer 等の改善を加えた後もう一度比較してみるとよいだろう。
ちなみに Makefile に次のように追加するだけである。
PPU_COMPILER = xlc
SPU_COMPILER = xlc
xlc -O3 / gcc -O3 [msec]
SPE 512x512 1024x1024 2048x2048
1 1148/795 8700/6010 16100/47400
2 600/430 4600/3170 36300/24500
3 425/310 3150/2240 24500/16900
4 330/245 2420/1730 18800/13200
5 280/210 2020/1460 15500/11000
6 245/190 1710/1270 13200/ 9700
※コメント投稿者のブログIDはブログ作成者のみに通知されます