8/24 AMD APP SDK v2.5

いつの間にか2.5が出ているようだが全然気づかなかった。

何が新しくなったのか見てみたのだが・・・

・Kernel launch times have been further reduced.
信じていいのだろうか。今更インストールする時間があるか微妙だが。

・For APUs, zero copy buffers created as CL_MEM_ALLOC_HOST_PTR | CL_MEM_READ_ONLY offer improved GPU read performance.
そもそもLinuxでzero copyは対応していない。残念。

8/23 苦戦中

IKA-SST GPU版をCUDAからOpenCLへ移植中。
OpenCLデバイスの初期設定やメモリ確保、CPU計算部分はたぶんうまく移植できた。
あとは本丸のGPUでの計算部分が動ければよい。

GPUカーネルコード部分が問題なのだが、初っ端から躓いてしまった。
OpenCLのデバイス側の制約などがまだちゃんと頭に入っておらず、
検索に時間を取られすぎてしまって全然進展しない。

締切も迫っているのでこのままではまずい。

8/22 gcc

IKA-SSTの実装で使っているライブラリはcblasとlapackだが、
ライブラリをリンクする場合には依存関係による順番に注意が必要らしい。

cblasはatlasとf77blasに依存しており、f77blasはgfortranに依存、
lapackはatlasに依存している。

これを踏まえてgcc(g++)に渡すオプションを整理すると、
-lcblas -lapack -latlas -lg77blas -lg77fortran
のような感じになる。
ダイナミックリンクライブラリだと関係ないらしい。

難しい。

8/22 IKA-SST on CPU

U君に手伝ってもらい、IKA-SSTのCPU版のコンパイルが通った。
一応コンパイル時のオプションを記述しておく。
g++ Main.cpp sst.cpp -I/usr/global/boost/include -I"/usr/global/cuda/include" -I"/nfs/home/matsuura/ikaSST/sst_CPU/inc" -O3 -fno-strict-aliasing -msse -msse2 -Wall -L/usr/global/boost/stage/lib -L/usr/global/centos5.4/lib64 -L/nfs/home/ueno/lib -lboost_thread -lgfortran -llapack -lf77blas -lcblas -latlas
環境依存なので他所では役に立たないし、そもそもIKA-SST自体がローカルのコードだが。

CentOS環境下ではうまく動作するが、Scientific Linuxではうまくいかない。
Fortran関連のライブラリがうまくいってない模様。
./a.out: error while loading shared libraries: libgfortran.so.1: cannot open shared object file: No such file or directory


＃＃＃追記

共有領域にlibが置いてあったようなので、それを/etc/ld/so.confに追加し、
ldconfigしたら無事に動いた。

Phenom 2.5GHzとE-350 1.6GHzなので実行時間は4倍くらいかかってしまうが、
APUとの比較なのでまあ大丈夫だろう。

ようやくAPUへのポーティングにとりかかれるが、困難を極めると予想される。

8/12

実験データをNFSから写し忘れてしまい、作業が全くできない。
図書館のサイトは復活したので停電は終わったはずだが、
なぜか研究室のSSHは全く無反応のままだ。
15日まで作業できないのだろうか。

8/9 OpenCL VWAP on Linux

だいぶ前に作成したVWAPをLinuxで実行。
ソースは時間測定部分が変わるだけで全て同じ。
10回実行の上下特異点を抜いて8回の平均値を算出。
10000回実行時のメモリ送信、カーネル実行、メモリ受信のそれぞれの時間を測定。

現在VOIDとVWAPをCPU、APUそれぞれで実行中。
結果が出たらWindows版と比較する。

ちらっと結果を見たところ、メモリ送信は10倍近く時間がかかっている。
初回起動時のオーバーヘッドかと思ったが、10000回のそれぞれがj10倍程度遅い。
実はWindows版はゼロコピーらしきものが効いていたのだろうか？

カーネル実行時間は数%程度は下がっている。
しかし大勢には影響ない・・・。

詳しい集計や考察はまた明日以降に。

8/8 Scientific Linux

インストールはCentOS 6.0とほぼ同様。
パッケージはDesktopのみを選択。
リポジトリはAMD64とセキュリティも追加。

・System S
必要なパッケージを適当にyum。
おととい書いたものは重複やエラーも混じっていたので修正。

# yum install -y gcc libstdc++-devel gcc-c++ boost-devel libicu-devel zlib-devel libxml2-devel binutils-devel libsepol-devel keyutils-libs-devel e2fsprogs-devel krb5-devel openssl-devel libidn-devel perl-Digest-SHA1 perl-XML-Parser perl-XML-Simple curl-devel libstdc++.so.5 perl-libwww-perl.noarch compat-libstdc++-33 perl-XML-SAX libicu-devel libxml2-devel binutils-devel libXaw compat-expat1 libperl.so

しかしこれでもgraphvizはインストールできないし、
スクリプト起動時のエラーも消えない。
具体的にはlibltdl.so.3とlibperl.soが解決できない。
yumではインストールできているようだが、System Sが要求しているものと微妙に違うようだ。
これに対処している暇は今はないので、System SはRedhat/CentOSの5.xで使うしかなさそうだ。


・OpenCL
今までと同様。
# wget http://www2.ati.com/drivers/linux/ati-driver-installer-11-7-x86.x86_64.run
# yum install kernel-devel rpm-build

runlevelを3にしてスクリプトを起動してRHEL6 AMD64のドライバを生成。
生成が成功したらyumでインストール。
rpmのインストールでもyumを使うほうがいいらしい。

# aticonfig --initial -f
してからまたrunlevelを5に戻して再起動。

このままではうまくいかなかったが、/etc/OpenCL/vendors/以下を追加したら成功した。
追加するファイルの詳細はこの前このブログにも書いたので省略。

ここまでやると、OpenCLデバイスでGPUも認識され、
サンプルコードを動かしてもGPUで実行されることが確認できた。
atigetsystemlog.shでも以前うまくいっていなかった部分が更新されている。

System Sは残念だったが、OpenCLは無事動いた。
これで安心して帰省することができそうだ。


・おまけ
サンプルコードのGlobalMemoryBandwidthの実行結果

実行環境
[OS] Scientific Linux 6.1
[APU] AMD E-350
[RAM] DDR3 2GB (512MB for Graphics)
[M/B] E35M1-I
[Software] AMD APP SDK v2.4, Catalyst 11.7, gcc 4.4.5


Selected Platform Vendor : Advanced Micro Devices, Inc.
Device 0 : Loveland
Build Options are : -D DATATYPE=float4

Global Memory Read
AccessType : single
VectorElements : 4
Bandwidth : 31.4677 GB/s

Global Memory Read
AccessType : linear
VectorElements : 4
Bandwidth : 17.9922 GB/s

Global Memory Read
AccessType : linear(uncached)
VectorElements : 4
Bandwidth : 15.332 GB/s

Global Memory Write
AccessType : linear
VectorElements : 4
Bandwidth : 21.1874 GB/s


色々CPUとの性能差があって面白い。