今年は基礎的な研究や調査を多数行いました。まだまだ基礎的なことでしなければならないことは多いのですが、それなりに各分野のノウハウが蓄積されてきましたので、来年は具体的な成果物を作る年にしたいと思います。最適化関連のアルゴリズムとデータ構造の高速実装と大規模計算に関する技術というのは、残念ながら今の日本では活躍の場はほとんど無いのが現状です。短期的に考えれば最適化ソフトウェアを作るよりも購入したりダウンロードして使う方がリーズナブルですし、ソフトウェアを評価する体制も出来ていません。というわけなので、来年以降も非常に厳しい状況が続くと予想していますが、暗い話ばかりではなく新しい企画や構想もたくさん用意しています。
いつもは計算サーバでの実験を行っていたので、今年の締めくくりとして PC を使った実験結果を示す。やはり Nehalem 系が最強ということに変わりはない。来年は特に Intel Nehalem-EX に期待したい。
ソフトウェア
○: SDPA 7.3.2β : GotoBLAS2 1.09 + MUMPS 4.9.2
○計算 PC 1
CPU : Intel Core i7 940 (2.93GHz)
Memory : 6GB
○計算 PC 2
CPU : Intel Core2 Quad 9650 (3.00GHz)
Memory : 8GB
○計算 PC 3
CPU : AMD Phenom II X4 955 (3.2GHz)
Memory : 8GB
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 4
●問題１ : theta6.dat-s
PC 1 : 16.8s(18回)
PC 2 : 21.2s(18回)
PC 3 : 20.1s(18回)
●問題２ : mater-6.dat-s
PC 1 : 31.9s(36回)
PC 2 : 50.6s(36回)
PC 3 : 61.1s(36回)
●問題３ : mcp2000-10.dat-s
PC 1 : 61.4s(16回)
PC 2 : 74.9s(16回)
PC 3 : 67.4s(16回)
●問題４ : LiH.1Sigma+.STO6G.pqgt1t2p.dat-s
PC 1 : 32.3s(29回)
PC 2 : 37.6s(29回)
PC 3 : 48.1s(29回)
ソフトウェア
○: SDPA 7.3.2β : GotoBLAS2 1.09 + MUMPS 4.9.2
○計算 PC 1
CPU : Intel Core i7 940 (2.93GHz)
Memory : 6GB
○計算 PC 2
CPU : Intel Core2 Quad 9650 (3.00GHz)
Memory : 8GB
○計算 PC 3
CPU : AMD Phenom II X4 955 (3.2GHz)
Memory : 8GB
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 4
●問題１ : theta6.dat-s
PC 1 : 16.8s(18回)
PC 2 : 21.2s(18回)
PC 3 : 20.1s(18回)
●問題２ : mater-6.dat-s
PC 1 : 31.9s(36回)
PC 2 : 50.6s(36回)
PC 3 : 61.1s(36回)
●問題３ : mcp2000-10.dat-s
PC 1 : 61.4s(16回)
PC 2 : 74.9s(16回)
PC 3 : 67.4s(16回)
●問題４ : LiH.1Sigma+.STO6G.pqgt1t2p.dat-s
PC 1 : 32.3s(29回)
PC 2 : 37.6s(29回)
PC 3 : 48.1s(29回)
前回の SDPA に関する数値実験で何故２４コアもある計算サーバ１が８コアの計算サーバ２に負けるのかという問題があるので、もう少し詳しく調べてみた。
ソフトウェア
○: SDPA 7.3.2β : GotoBLAS2 1.09 + MUMPS 4.9.2
○計算サーバ１
CPU : AMD Opteron 8439 (2.80GHz / 6MB L3) x 4
Memory : 128GB (32 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 24
○計算サーバ２
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 8
●問題１ : FH2+.1A1.STO6G.pqgt1t2p.dat-s
計算サーバ１ : 66.1s(30回) 24スレッド
計算サーバ２ : 96.4s(30回) 8 スレッド
F3 式の計算にかかる時間は
計算サーバ１ : 76.9s (24スレッド合計)
計算サーバ２ : 135.1s (8スレッド合計)
となっていて、これは明らかに CPU 数が４個あって、メモリチャンネルも多い計算サーバ１の方が有利になる。
●問題２ : mcp2000-01.dat-s
計算サーバ１ : 95.9s(16回) 24スレッド
計算サーバ２ : 46.2s(16回) 8 スレッド
例えば固有値計算などでは以下のような差が付いている。
計算サーバ１ : 14.7s (24スレッド合計)
計算サーバ２ : 5.4s (8スレッド合計)
●問題３ : thetaG51.dat-s
計算サーバ１ : 118.8s(28回) 24スレッド
計算サーバ２ : 83.6s(28回) 8 スレッド
F3 式の計算にかかる時間は
計算サーバ１ : 35.3s (24スレッド合計)
計算サーバ２ : 65.1s (8スレッド合計)
また Cholesky 分解にかかる時間は
計算サーバ１ : 66.9s (24スレッド合計)
計算サーバ２ : 43.4s (8スレッド合計)
となっている。
F3 式のようにコア単位で独立かつ並列に計算できる部分に関しては、Istanbul 24 コアが有利で、行列積のように全てのコアを用いて計算する場合には Nehalem-ep 8 コアの方が速い。
ソフトウェア
○: SDPA 7.3.2β : GotoBLAS2 1.09 + MUMPS 4.9.2
○計算サーバ１
CPU : AMD Opteron 8439 (2.80GHz / 6MB L3) x 4
Memory : 128GB (32 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 24
○計算サーバ２
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 8
●問題１ : FH2+.1A1.STO6G.pqgt1t2p.dat-s
計算サーバ１ : 66.1s(30回) 24スレッド
計算サーバ２ : 96.4s(30回) 8 スレッド
F3 式の計算にかかる時間は
計算サーバ１ : 76.9s (24スレッド合計)
計算サーバ２ : 135.1s (8スレッド合計)
となっていて、これは明らかに CPU 数が４個あって、メモリチャンネルも多い計算サーバ１の方が有利になる。
●問題２ : mcp2000-01.dat-s
計算サーバ１ : 95.9s(16回) 24スレッド
計算サーバ２ : 46.2s(16回) 8 スレッド
例えば固有値計算などでは以下のような差が付いている。
計算サーバ１ : 14.7s (24スレッド合計)
計算サーバ２ : 5.4s (8スレッド合計)
●問題３ : thetaG51.dat-s
計算サーバ１ : 118.8s(28回) 24スレッド
計算サーバ２ : 83.6s(28回) 8 スレッド
F3 式の計算にかかる時間は
計算サーバ１ : 35.3s (24スレッド合計)
計算サーバ２ : 65.1s (8スレッド合計)
また Cholesky 分解にかかる時間は
計算サーバ１ : 66.9s (24スレッド合計)
計算サーバ２ : 43.4s (8スレッド合計)
となっている。
F3 式のようにコア単位で独立かつ並列に計算できる部分に関しては、Istanbul 24 コアが有利で、行列積のように全てのコアを用いて計算する場合には Nehalem-ep 8 コアの方が速い。
研究室の以下のサーバなどは全て１２月２７日の夕方に復旧しましたが、別管理のメールサーバなどはまだ復旧していないようです。メールサーバは私の管理下ではないので、こちらの状況は良くわかりません。
1: SDPA ホームページ
2: SDPA Online Solver
3: 最短路問題 Online Solver
1: SDPA ホームページ
2: SDPA Online Solver
3: 最短路問題 Online Solver
長くなったので、MPACK の make についての記事を２回に分けてみた。
○環境１
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB)
gcc : 4.4.2
OS : Fedora 12 for x86_64
○環境２
CPU : Intel Xeon 5460 (3.16GHz / 6MB L2 x 2) x 2
Memory : 48GB (12 x 4GB)
gcc : 4.4.2 (デフォルトは 4.1.2)
OS : CentOS 5.4 for x86_64
2: 環境１ではデフォルトで GMP 4.3.1 がインストールされているので、これを用いることにする。qd-2.3.7 は /usr/local/qd/lib にインストールした。
./configure --with-qd-includedir=/usr/local/qd/include/ --with-qd-libdir=/usr/local/qd/lib/ --with-blas="-lgoto -lgomp" --with-lapack="-lgoto -lgomp -lgfortran"
qd を /usr 以下あるいは /usr/local 以下にインストールすれば問題無いのだが、/usr/local/qd などにインストールすると以下のようなエラーが発生する
libtool: compile: g++ -DPACKAGE_NAME=\"mpack\" -DPACKAGE_TARNAME=\"mpack\" -DPACKAGE_VERSION=\"0.6.0\" "-DPACKAGE_STRING=\"mpack 0.6.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"mpack\" -DVERSION=\"0.6.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" "-DF77_FUNC(name,NAME)=name ## _" "-DF77_FUNC_(name,NAME)=name ## _" -I. -I../../include -D___MPACK_BUILD_WITH_QD___ -funroll-all-loops -O2 -m64 -D_REENTRANT -MT libmblas_qd_ref_la-Caxpy.lo -MD -MP -MF .deps/libmblas_qd_ref_la-Caxpy.Tpo -c Caxpy.cpp -fPIC -DPIC -o .libs/libmblas_qd_ref_la-Caxpy.o
../../include/mblas.h:43 から include されたファイル中,
Caxpy.cpp:72 から:
../../include/mblas_qd.h:34:24: error: qd/qd_real.h: そのようなファイルやディレクトリはありません
In file included from ../../include/mblas_qd.h:35,
from ../../include/mblas.h:43,
from Caxpy.cpp:72:
3: SDPA-GMP を configure するときに以下のように行ってみたのだが、--enable-openmp, --with-mpack-includedir, --with-mpack-libdir 三つのオプションは有効なのだろうか？
./configure --enable-openmp --with-mpack-includedir=/usr/local/include --with-mpack-libdir=/usr/local/lib
○環境１
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB)
gcc : 4.4.2
OS : Fedora 12 for x86_64
○環境２
CPU : Intel Xeon 5460 (3.16GHz / 6MB L2 x 2) x 2
Memory : 48GB (12 x 4GB)
gcc : 4.4.2 (デフォルトは 4.1.2)
OS : CentOS 5.4 for x86_64
2: 環境１ではデフォルトで GMP 4.3.1 がインストールされているので、これを用いることにする。qd-2.3.7 は /usr/local/qd/lib にインストールした。
./configure --with-qd-includedir=/usr/local/qd/include/ --with-qd-libdir=/usr/local/qd/lib/ --with-blas="-lgoto -lgomp" --with-lapack="-lgoto -lgomp -lgfortran"
qd を /usr 以下あるいは /usr/local 以下にインストールすれば問題無いのだが、/usr/local/qd などにインストールすると以下のようなエラーが発生する
libtool: compile: g++ -DPACKAGE_NAME=\"mpack\" -DPACKAGE_TARNAME=\"mpack\" -DPACKAGE_VERSION=\"0.6.0\" "-DPACKAGE_STRING=\"mpack 0.6.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"mpack\" -DVERSION=\"0.6.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" "-DF77_FUNC(name,NAME)=name ## _" "-DF77_FUNC_(name,NAME)=name ## _" -I. -I../../include -D___MPACK_BUILD_WITH_QD___ -funroll-all-loops -O2 -m64 -D_REENTRANT -MT libmblas_qd_ref_la-Caxpy.lo -MD -MP -MF .deps/libmblas_qd_ref_la-Caxpy.Tpo -c Caxpy.cpp -fPIC -DPIC -o .libs/libmblas_qd_ref_la-Caxpy.o
../../include/mblas.h:43 から include されたファイル中,
Caxpy.cpp:72 から:
../../include/mblas_qd.h:34:24: error: qd/qd_real.h: そのようなファイルやディレクトリはありません
In file included from ../../include/mblas_qd.h:35,
from ../../include/mblas.h:43,
from Caxpy.cpp:72:
3: SDPA-GMP を configure するときに以下のように行ってみたのだが、--enable-openmp, --with-mpack-includedir, --with-mpack-libdir 三つのオプションは有効なのだろうか？
./configure --enable-openmp --with-mpack-includedir=/usr/local/include --with-mpack-libdir=/usr/local/lib
前回の MPACK に関する内容の続きになる。MPACK に関して以下の内容を試みた。普通に make すれば問題無いのだが、以下のように少し変わった方法で make すると問題が発生する。計算機環境は以下の通り。
○環境１
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB)
gcc : 4.4.2
OS : Fedora 12 for x86_64
○環境２
CPU : Intel Xeon 5460 (3.16GHz / 6MB L2 x 2) x 2
Memory : 48GB (12 x 4GB)
gcc : 4.4.2 (デフォルトは 4.1.2)
OS : CentOS 5.4 for x86_64
1: 環境２ではデフォルトの gmp が 4.1.4 と古い。そこで自分で gmp 4.3.1 を make してインストールするが、gmp 4.1.4 を置き換えるのではなく、gmp 4.3.1 は /usr/local/gmp にインストール。また、qd-2.3.7 も /usr/local/qd にインストールした。BLAS と LAPACK は以下のように GotoBLAS2 1.09 を使う。
./configure --with-qd-includedir=/usr/local/qd/include --with-qd-libdir=/usr/local/qd/lib --with-gmp-includedir=/usr/local/gmp/include --with-gmp-libdir=/usr/local/gmp/lib --with-blas="-lgoto -lgomp" --with-lapack="-lgoto -lgomp -lgfortran"
しかし、-I/usr/local/gmp/include が無いのでデフォルトの gmp 4.1.4 の gmpxx.h を参照しているようだ。
libtool: compile: g++ -DPACKAGE_NAME="mpack" -DPACKAGE_TARNAME="mpack" -DPACKAGE_VERSION="0.6.0" "-DPACKAGE_STRING="mpack 0.6.0"" -DPACKAGE_BUGREPORT="" -DPACKAGE="mpack" -DVERSION="0.6.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" "-DF77_FUNC(name,NAME)=name ## _" "-DF77_FUNC_(name,NAME)=name ## __" -I. -I../../include -D___MPACK_BUILD_WITH_GMP___ -funroll-all-loops -O2 -m64 -D_REENTRANT -MT libmblas_gmp_ref_la-Caxpy.lo -MD -MP -MF .deps/libmblas_gmp_ref_la-Caxpy.Tpo -c Caxpy.cpp -fPIC -DPIC -o .libs/libmblas_gmp_ref_la-Caxpy.o
In file included from ../../include/mblas_gmp.h:34,
from ../../include/mblas.h:34,
from Caxpy.cpp:72:
/usr/include/gmpxx.h: In destructor ‘__gmp_alloc_cstring::~__gmp_alloc_cstring()’:
/usr/include/gmpxx.h:2096: error: ‘strlen’ was not declared in this scope
make[2]: *** [libmblas_gmp_ref_la-Caxpy.lo] エラー 1
make[2]: ディレクトリ `/home/fujisawa/sdpa7.new/mpack-0.6.0/mblas/reference' から出ます
make[1]: *** [all-recursive] エラー 1
make[1]: ディレクトリ `/home/fujisawa/sdpa7.new/mpack-0.6.0/mblas' から出ます
make: *** [all-recursive] エラー 1
○環境１
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB)
gcc : 4.4.2
OS : Fedora 12 for x86_64
○環境２
CPU : Intel Xeon 5460 (3.16GHz / 6MB L2 x 2) x 2
Memory : 48GB (12 x 4GB)
gcc : 4.4.2 (デフォルトは 4.1.2)
OS : CentOS 5.4 for x86_64
1: 環境２ではデフォルトの gmp が 4.1.4 と古い。そこで自分で gmp 4.3.1 を make してインストールするが、gmp 4.1.4 を置き換えるのではなく、gmp 4.3.1 は /usr/local/gmp にインストール。また、qd-2.3.7 も /usr/local/qd にインストールした。BLAS と LAPACK は以下のように GotoBLAS2 1.09 を使う。
./configure --with-qd-includedir=/usr/local/qd/include --with-qd-libdir=/usr/local/qd/lib --with-gmp-includedir=/usr/local/gmp/include --with-gmp-libdir=/usr/local/gmp/lib --with-blas="-lgoto -lgomp" --with-lapack="-lgoto -lgomp -lgfortran"
しかし、-I/usr/local/gmp/include が無いのでデフォルトの gmp 4.1.4 の gmpxx.h を参照しているようだ。
libtool: compile: g++ -DPACKAGE_NAME="mpack" -DPACKAGE_TARNAME="mpack" -DPACKAGE_VERSION="0.6.0" "-DPACKAGE_STRING="mpack 0.6.0"" -DPACKAGE_BUGREPORT="" -DPACKAGE="mpack" -DVERSION="0.6.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" "-DF77_FUNC(name,NAME)=name ## _" "-DF77_FUNC_(name,NAME)=name ## __" -I. -I../../include -D___MPACK_BUILD_WITH_GMP___ -funroll-all-loops -O2 -m64 -D_REENTRANT -MT libmblas_gmp_ref_la-Caxpy.lo -MD -MP -MF .deps/libmblas_gmp_ref_la-Caxpy.Tpo -c Caxpy.cpp -fPIC -DPIC -o .libs/libmblas_gmp_ref_la-Caxpy.o
In file included from ../../include/mblas_gmp.h:34,
from ../../include/mblas.h:34,
from Caxpy.cpp:72:
/usr/include/gmpxx.h: In destructor ‘__gmp_alloc_cstring::~__gmp_alloc_cstring()’:
/usr/include/gmpxx.h:2096: error: ‘strlen’ was not declared in this scope
make[2]: *** [libmblas_gmp_ref_la-Caxpy.lo] エラー 1
make[2]: ディレクトリ `/home/fujisawa/sdpa7.new/mpack-0.6.0/mblas/reference' から出ます
make[1]: *** [all-recursive] エラー 1
make[1]: ディレクトリ `/home/fujisawa/sdpa7.new/mpack-0.6.0/mblas' から出ます
make: *** [all-recursive] エラー 1
Mixi などに出ている最新の情報は知らないが、とりあえずは11月24日の段階で MPACK が 0.6.0 になっていた。実は、これまで MPACK の make に成功したことが無かったのだが、それは普通に make しないのが原因なので、今回初めて普通に make したら成功した。普通とはデフォルトの GMP を使うとか、QD ライブラリを /usr/local 以下にインストールするという意味になる。ちなみに、nehalem-ep の 8 コアのマシンで make に 15 分かかった(make -j 8 として実行)。まさにちょっと信じがたいソースファイルの量になる。
大学の電気設備等の点検のため、１２月２５日の夕方から１２月２７日の夕方ぐらいまでの間、全てのサーバ(Web, メール、計算等)が停止します。よって、以下のページも全て利用不可になります。
1: SDPA ホームページ
2: SDPA Online Solver
3: 最短路問題 Online Solver
1: SDPA ホームページ
2: SDPA Online Solver
3: 最短路問題 Online Solver
現在入手可能な最新の CUDA は 2.3 になっているが、Fedora だと公式にサポートしているのは、Fedora 10 までだが、Fedora 11 でも動作する。しかしその場合では gcc はデフォルトの 4.4.1 ではなく、4.3.2 などをインストールする必要がある。また Fedora 12 では動作させることが出来なかった。
1: CUDA のダウンロード (RHEL5.x(CentOS 5.x) x86_64 の場合)
CUDAドライバ : cudadriver_2.3_linux_64_190.18.run
CUDA ツールキット : cudatoolkit_2.3_linux_64_rhel5.3.run
CUDA SDK : cudasdk_2.3_linux.run
2: NVIDIA ドライバのインストール
yum install kernel-devel
yum install freeglut freeglut-devel
init 3
sh cudadriver_2.3_linux_64_190.18.run
init 5
3: CUDA のインストール
sh cudatoolkit_2.3_linux_64_rhel5.3.run
sh cudasdk_2.3_linux.run
/etc/ld.so.conf に /usr/local/cuda/lib と /usr/local/cuda/lib64 を追加
ldconfig
PATH に /usr/local/cuda/bin を追加
4: サンプルファイルの make
cd NVIDIA_GPU_Computing_SDK
cd C
make
./bin/linux/release 以下に様々なバイナリが出来ている
この中の bandwidthTest を用いるとメインメモリ ←→ ビデオカードのメモリ間の
バンド幅の測定が出来る。
./bandwidthTest --device=0
Running on......
device 0:Tesla C1060
Quick Mode
Host to Device Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 5415.0
Quick Mode
Device to Host Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 4626.3
Quick Mode
Device to Device Bandwidth
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 73712.9
&&&& Test PASSED
[root@opt-tesla release]# ./bandwidthTest --device=1
Running on......
device 1:GeForce 9600 GT
Quick Mode
Host to Device Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 5353.1
Quick Mode
Device to Host Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 4588.2
Quick Mode
Device to Device Bandwidth
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 41306.4
1: CUDA のダウンロード (RHEL5.x(CentOS 5.x) x86_64 の場合)
CUDAドライバ : cudadriver_2.3_linux_64_190.18.run
CUDA ツールキット : cudatoolkit_2.3_linux_64_rhel5.3.run
CUDA SDK : cudasdk_2.3_linux.run
2: NVIDIA ドライバのインストール
yum install kernel-devel
yum install freeglut freeglut-devel
init 3
sh cudadriver_2.3_linux_64_190.18.run
init 5
3: CUDA のインストール
sh cudatoolkit_2.3_linux_64_rhel5.3.run
sh cudasdk_2.3_linux.run
/etc/ld.so.conf に /usr/local/cuda/lib と /usr/local/cuda/lib64 を追加
ldconfig
PATH に /usr/local/cuda/bin を追加
4: サンプルファイルの make
cd NVIDIA_GPU_Computing_SDK
cd C
make
./bin/linux/release 以下に様々なバイナリが出来ている
この中の bandwidthTest を用いるとメインメモリ ←→ ビデオカードのメモリ間の
バンド幅の測定が出来る。
./bandwidthTest --device=0
Running on......
device 0:Tesla C1060
Quick Mode
Host to Device Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 5415.0
Quick Mode
Device to Host Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 4626.3
Quick Mode
Device to Device Bandwidth
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 73712.9
&&&& Test PASSED
[root@opt-tesla release]# ./bandwidthTest --device=1
Running on......
device 1:GeForce 9600 GT
Quick Mode
Host to Device Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 5353.1
Quick Mode
Device to Host Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 4588.2
Quick Mode
Device to Device Bandwidth
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 41306.4
10月の終わりに HDD 0, 11月の終わりに HDD 3 が故障して交換と RAID 5 の再構築を行った laqua サーバ (laqua.indsys.chuo-u.ac.jp) だが、今度は HDD 1 に異常が発生したので、同様に HDD の交換と再構築を行った。HDD 0 から 3 までの 4 台の HDD で構成されている laqua サーバだが、これで１回も壊れていない HDD は残り HDD 2 だけになった。壊れるのは何故か PowerEdge 2970 ばかりになる。
並行コンピューティング技法という本を購入したが、ざっと斜め読みしただけなので、これから真面目に少しずつ読んでみることにする。ただし、この本で書かれている技法についてはほとんどすでに考慮済みであり、現在開発中のソフトウェアについては参考になりそうな文献は残念ながらあまり見られない。
この種の並列化(並行化)の本について、
１：並列化によって効果が得られる例を中心に扱っているが、効果が得られにくい問題に対してどのように対処して少しずつ性能を上げていくかという例があまり見られない。
２：具体的に実行環境(アーキテクチャ)を決めて、その特性を活用しながら実装を行っていくという例が無い。個別のアーキテクチャで論ずるのは一般性が無いように見えるが、実は普遍的に扱うことができる内容も多い。
という傾向が見られる。
この種の並列化(並行化)の本について、
１：並列化によって効果が得られる例を中心に扱っているが、効果が得られにくい問題に対してどのように対処して少しずつ性能を上げていくかという例があまり見られない。
２：具体的に実行環境(アーキテクチャ)を決めて、その特性を活用しながら実装を行っていくという例が無い。個別のアーキテクチャで論ずるのは一般性が無いように見えるが、実は普遍的に扱うことができる内容も多い。
という傾向が見られる。
NetWalker を本来の使い方(クラウド端末）をするのではなく、NetWalker 自体で最適化を行うという試みを幾つか行ってきた。この CPU (ARM Cortex-A8) は省電力を目標として設計されていて、浮動小数点演算もあまり重視されていないので、最適化ソフトウェアを動作させるという試みは本筋から外れているようにも思える。しかし、幾つかの実験で判明したことは、主に以下の点である。
1: 浮動小数点演算を多用するソフトウェアの実行には向かない
2: 整数演算の性能はそこそこ上がるので、それほど大きな最適化問題でなければ扱うこともできる。例えば最短路問題であれば数十万点以内のグラフで１クエリだけであれば数秒以内で最短路を求めることができる。
1: 浮動小数点演算を多用するソフトウェアの実行には向かない
2: 整数演算の性能はそこそこ上がるので、それほど大きな最適化問題でなければ扱うこともできる。例えば最短路問題であれば数十万点以内のグラフで１クエリだけであれば数秒以内で最短路を求めることができる。
最近の SDPA の開発においては、pthread だけではなく OpenMP も用いているが、ソフトウェア配布については以下のような問題がある。
1: gcc 4.1.x だと OpenMP 2.5 のプレビューサポートになっているため性能が非常に悪い。RedHat 5.x (CentOS 5.x)では gcc のバージョンが 4.1.2 になっている。Vine Linux 5.x でも gcc 4.1.2 だが、OpenMP 自体がサポートされていない。個人的には CentOS 5.x と Vine Linux 5.x に gcc 4.4.2 をインストールすることによって、この性能低下の問題を解決しているが、デフォルトの状態で SDPA を make すると、SDPA 7.3.1 (pthread 版)よりも性能が低下する。
2: OpenMP 3.0 には新機能が多いが、1 の理由にて利用することが難しい。
3: CPU 数とコア数が多い場合では(Istanbul 4-way 24 コアなど)、OpenMP の性能が pthread 版よりも下回るようになる。
論文だけ作成して、ソフトウェアを公開しないのであれば、このような問題を考慮する必要はないのだが、まだ公開用のソフトウェアで OpenMP を使うには様々な問題がある。
1: gcc 4.1.x だと OpenMP 2.5 のプレビューサポートになっているため性能が非常に悪い。RedHat 5.x (CentOS 5.x)では gcc のバージョンが 4.1.2 になっている。Vine Linux 5.x でも gcc 4.1.2 だが、OpenMP 自体がサポートされていない。個人的には CentOS 5.x と Vine Linux 5.x に gcc 4.4.2 をインストールすることによって、この性能低下の問題を解決しているが、デフォルトの状態で SDPA を make すると、SDPA 7.3.1 (pthread 版)よりも性能が低下する。
2: OpenMP 3.0 には新機能が多いが、1 の理由にて利用することが難しい。
3: CPU 数とコア数が多い場合では(Istanbul 4-way 24 コアなど)、OpenMP の性能が pthread 版よりも下回るようになる。
論文だけ作成して、ソフトウェアを公開しないのであれば、このような問題を考慮する必要はないのだが、まだ公開用のソフトウェアで OpenMP を使うには様々な問題がある。
以下の AMD Istanbul 4-way サーバが入手できたので、最新の SDPA を用いて簡単な実験を行った。このマシンは HyperTransport などの問題もあって使いこなすのは、なかなか難しい。やはり Intel Nehalem-EX の方が良さそう。
ソフトウェア
○: SDPA 7.3.2β : GotoBLAS2 1.09 + MUMPS 4.9.2
○計算サーバ１
CPU : AMD Opteron 8439 (2.80GHz / 6MB L3) x 4
Memory : 128GB (32 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 24
○計算サーバ２
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 8
●問題１ : FH2+.1A1.STO6G.pqgt1t2p.dat-s
計算サーバ１ : 71s(30回) 24スレッド; 103s(30回) 12 スレッド
計算サーバ２ : 96s(30回) 8 スレッド
●問題２ : thetaG51.dat-s
計算サーバ１ : 135s(28回) 24スレッド; 98s(28回) 12 スレッド
計算サーバ２ : 82s(28回) 8 スレッド
●問題３ : control11.dat-s
計算サーバ１ : 55s(47回) 24スレッド; 41s(47回) 12 スレッド
計算サーバ２ : 27s(30回) 8 スレッド
ソフトウェア
○: SDPA 7.3.2β : GotoBLAS2 1.09 + MUMPS 4.9.2
○計算サーバ１
CPU : AMD Opteron 8439 (2.80GHz / 6MB L3) x 4
Memory : 128GB (32 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 24
○計算サーバ２
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 8
●問題１ : FH2+.1A1.STO6G.pqgt1t2p.dat-s
計算サーバ１ : 71s(30回) 24スレッド; 103s(30回) 12 スレッド
計算サーバ２ : 96s(30回) 8 スレッド
●問題２ : thetaG51.dat-s
計算サーバ１ : 135s(28回) 24スレッド; 98s(28回) 12 スレッド
計算サーバ２ : 82s(28回) 8 スレッド
●問題３ : control11.dat-s
計算サーバ１ : 55s(47回) 24スレッド; 41s(47回) 12 スレッド
計算サーバ２ : 27s(30回) 8 スレッド
SDPA 7.3.2βと以下のソフトウェアの比較実験を行う。速度的には以下の通りであるが、SDPA はまだまだ高速化が可能である。MATLAB での実行というのは結構速いので、C/C++ でソフトウェアを作るときには、かなり力を入れて作らないと MATLAB で作ったものよりも遅くなることが多いだろう。反対に言えば MATLAB では最高速を狙うのは難しいとも言える。
○: SDPA 7.3.2β : GotoBLAS2 1.09 + MUMPS 4.9.2
○: CSDP 6.0.1 : GotoBLAS2 1.09
○: SDPT3-4.0β : MATLAB : 7.8.0.347 (R2009a) + Intel MKL + CHOLMOD
○: SeDuMi 1.21 : MATLAB : 7.8.0.347 (R2009a) + Intel MKL + CHOLMOD
○実験環境
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 8
●問題１ : FH2+.1A1.STO6G.pqgt1t2p.dat-s
SDPA 7.3.2β : 96s(30回)
CSDP 6.0.1 : 143s(31回)
SDPT3-4.0β : 1,089s(36回)
SeDuMi 1.21 : 384s(25回)
●問題２ : theta6.dat-s
SDPA 7.3.2β : 12s(18回)
CSDP 6.0.1 : 20s(17回)
SDPT3-4.0β : 24s(14回)
SeDuMi 1.21 : 327s(16回)
●問題３ : control11.dat-s
SDPA 7.3.2β : 27s(47回)
CSDP 6.0.1 : 27s(26回) : セグメンテーションフォルトの発生が起きることがある
SDPT3-4.0β : 53s(26回)
SeDuMi 1.21 : 87s(45回)
○: SDPA 7.3.2β : GotoBLAS2 1.09 + MUMPS 4.9.2
○: CSDP 6.0.1 : GotoBLAS2 1.09
○: SDPT3-4.0β : MATLAB : 7.8.0.347 (R2009a) + Intel MKL + CHOLMOD
○: SeDuMi 1.21 : MATLAB : 7.8.0.347 (R2009a) + Intel MKL + CHOLMOD
○実験環境
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2
Memory : 72GB (18 x 4GB / 800MHz)
gcc : 4.4.2
OS : Fedora 12 for x86_64
環境変数 : OMP_NUM_THREADS = 8
●問題１ : FH2+.1A1.STO6G.pqgt1t2p.dat-s
SDPA 7.3.2β : 96s(30回)
CSDP 6.0.1 : 143s(31回)
SDPT3-4.0β : 1,089s(36回)
SeDuMi 1.21 : 384s(25回)
●問題２ : theta6.dat-s
SDPA 7.3.2β : 12s(18回)
CSDP 6.0.1 : 20s(17回)
SDPT3-4.0β : 24s(14回)
SeDuMi 1.21 : 327s(16回)
●問題３ : control11.dat-s
SDPA 7.3.2β : 27s(47回)
CSDP 6.0.1 : 27s(26回) : セグメンテーションフォルトの発生が起きることがある
SDPT3-4.0β : 53s(26回)
SeDuMi 1.21 : 87s(45回)
アクセス
トータル
