CUBLAS の sgemm のパフォーマンス測定

昨日にひきつづいて、sgemm を CUBLAS で実行したらどのくらいのスピードが出るかを確認。

結果としては、以下の感じ（GFLOPS, 理論性能値との比較）

N	CUBLAS	ATLAS	GotoBLAS
4095	24.27, 27%	50.31, 65%	71.69, 93%
4096	50.55, 58%	53.47, 69%	72.19, 94%
4097	24.02, 27%	48.96, 63%	71.40, 92%

ただし、CUBLAS (Quadro FX 1800) の理論性能は86.9GFLOPS, CPU (Xeon E5520 x2) は 76.8GFLOPS として計算。

思っていたよりもCUBLAS は理論性能との乖離が大きい。あと、2^n になったときとそうでないときでの差も大きい。
実際に使うときには、このあたりを踏まえてプログラムを組む必要がありそうだ。

ちなみに、cublasSgemm は CPU の動きとは非同期で計算を進めているので、計算時間の測定は同期を取った上で行う必要がある。
他にも、実際に使うときの補足的な情報（時間計測などなど）は
http://matsu-www.is.titech.ac.jp/~naoya/teaching/gpgpu-tutorial-gsic-2009-library-usage.pdf
などが参考になるし、tune したときにどうなるのか、ということが書いてある PDF も発見。
http://mc.stanford.edu/cgi-bin/images/6/65/SC08_Volkov_GPU.pdf
そのうちに読んでみようと思う。


あとは、SNL の計算について。
SeDuMi でも、それなりに精度が出るが、SNL の計算結果の誤差を例えば 1.0e-8 に抑えるなら、SeDuMi の eps はいくつぐらい必要なのかを簡単な例で調べてみる。
どうやら、SeDuMi の eps とほぼ同等な桁で出てくるようだが、まだまだ調べる必要あり。
これに関して、SDPA-GMP でも同じ問題を解いた。ただ、%8.16e と出力桁数を増やして dat-s を生成すると pdOPT にならないが、%8.4e だと pdOPT になる。
4桁程度しか有効桁数がない情報で dat-s に %8.16eとすると、最後のあたりの桁が怪しい状態で dat-s に書き込まれるようだ。


ついでにメモ。RHEL で yum update したときに、
Error: failed to retrieve repodata/filelists.xml.gz from rhel-x86_64-server-5
と言ったエラーが出るときには、
# rhn-profile-sync
# yum clean all
# yum updae
とすると直る。この情報はどこかの Web ページで見つけたのだが、そのページがどこだったのか解からなくなってしまった。

今日の作業内容: sgemm 3h + SNL 3h
今日のBGM:　小松未歩ベスト [1-2], Chrono Trigger OST [1-3]
今日のランチ: らく カキフライ定食
明日の予測作業時間: 5h