最適化問題に対する超高速&安定計算

大規模最適化問題、グラフ探索、機械学習やデジタルツインなどの研究のお話が中心

64bit と Segmentation fault

2007年09月30日 23時57分04秒 | Weblog
あるアメリカの大学のユーザから以下の環境において 32bit で SDPA6 を make すると正常に動作するが、64bit で SDPA6 を make したときに Segmentation fault が発生するという報告をもらった。
CPU: Intel Xeon 5160 × 2
OS: Linux RHEL 4 64bit
少し環境は異なるが、
CPU: Intel Core2 E6600
OS: CentOS 4
上で SDPA-64bit を make したところ無事に終了。このバイナリを送ったところ先方のマシンでも正常に動いたらしい。普通は命令セットの異なるマシンで実行したりしない限り Segmentation fault が発生しないので、いまだに原因は不明。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

SDPARA と ATLAS と GotoBLAS

2007年09月29日 23時15分15秒 | Weblog
SDPARA 1.0.1 は SDPA 6.x をベースに一部を MPI 化したものなので、BLAS には SDPA 6.2.1 と同じく ATLAS を用いている。正確に言うと以下のように ATLAS を使用している。
1: SDPARA - - > ScaLAPACK - - > ATLAS
2: SDPARA - - > ATLAS (MPI 化されていない部分)

1 については SDPARA 本体のコードを変えずに ATLAS から GotoBLAS や MKL に変更できる。2 についても SDPARA コードを一部書き換えて ATLAS に依存しないようにすれば良いのだが、やはり SDPA 7.x のように LAPACK/BLAS, ATLAS, MKL, GotoBLAS どれでもリンクできるように直すのが好ましい。
実際 1 の変更だけでも SDPARA + ATLAS に対して SDPARA + GotoBLAS は 1 割程度の性能向上が見られる。マルチスレッド化を工夫すれば、もう 1 割ぐらいの改善が出来そうだ。適当にスレッド数を変えてもそんな効果が見られる。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Vista 認証エラー

2007年09月28日 22時58分53秒 | Weblog
唯一仕事場で持っている Windows Vista Home Premium のマシンが突然ログイン出来なくなった。画面にはこの Windows 品は正規品ではなく偽造品であると表示され、手元のプロダクトキーを入力しても、このキーはすでに利用されていると表示される。この Vista のディスクは今年の初めに DSP 版 Windows XP Media Center Edition から Vista Home Premium への無料アップグレードで手に入れたもので、パッケージからしても正規品にしか見えない(無料と言っても実際には手数料を幾らか払っているが)。実際には何かのマイクロソフト側の手違いか、手持ちのプロダクトキーが誰かに不正使用されているかのどちらかだろう。この Vista マシンは実際にはほとんど使用していないので実害は無いが、またまた Vista でトラブルに巻き込まれた。もともと Windows Media Center Edition のライセンスが一個あるわけなので、こちらに戻してしまおうかと思うが、自腹で手数料払って手に入れた Vista なので、このままにしておくわけにもいかない。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

1TFlops

2007年09月27日 02時18分31秒 | Weblog
来年度の予算申請書を作成しているが、来年こそ 1TFlops 超えのクラスタ計算機を構築したいと思っている。AIST Super Cluster の経験から言っても、数千×数千の行列、数万個の制約を持つ SDP をパラメトリックに解こうと思えば、1TFlops 級の計算能力が無いと大変苦しい(というかそんな実験する気も起きてこない)。非常に大きな SDP で退化していたりすると、何回か別のパラメータで解き直してみないと満足行く精度が得られないことが多い。少し前ではこんなに大きな SDP を誰が必要なのかと思っていたが、普通に SDPA Online Solver に投入してくるユーザがいる。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ワンセグと GPS 携帯

2007年09月26日 01時59分16秒 | Weblog
東京に巨大地震が来ても、初日は帰宅せずに都心に残留した方が良いと言われている(生きていて、建物が無事ならば)。これは本当に都心の話で周辺区域は火災の恐れがあるので、状況によっては広域避難所まで移動する必要がある。もしそれでも電車などに乗っていて中途半端な場所にいたら、やはり何とかして帰らなければならない。そんなときに役に立ちそうなのが、携帯電話のワンセグチューナーと GPS 機能だと思っている。在京キー局ならば地震ぐらいでは放送が中断することはないと思うので(核攻撃でもない限り)、携帯電話で通話は出来なくても地上ならばワンセグの視聴は出来る可能性が高い。携帯電話の GPS 機能はドコモだと iアプリだったりするので、iモードサーバと通信出来なくても GPS 機能が使えるのかは実際持っていないのでわからない。東京近辺では GPS の受信が出来て、携帯電話の圏外になっている場所はなかなか無さそうなので、試してみるのは結構難しい。夜に見知らぬ土地で明かりが消えていれば、GPS でも無いと道に迷う可能性が高い。予備の携帯電話の電池も必要。以前この目的のために VAIO TypeU を購入したが、購入後約1年でバッテリーでは起動しなくなってしまった。全く意味のないマシンになった。家庭用電源でしか点かない懐中電灯と同じこと。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

起動時が危険

2007年09月25日 04時05分24秒 | Weblog
クラスタ計算機などは長いこと電源を入れたまま使用しているが、意外とずっと稼働させている方が長持ちすることもある。こまめに電源を切って休ませる方法もあるが、何か月か放置しておいた後に起動したら壊れていたという経験は何回もしている。パソコンの寿命は4,5年というところかもしれないが、使っていた時間と寿命にはあまり相関が無いのではないかと思う(人間も良く働く人ほど長生きしたりするので)。老齢のパソコンは実は起動時が危険である。一時的に電力消費量は増大するので、パソコン内の様々な回路に高い負担がかかり、この瞬間が危険なのだそうだ。だから老齢のパソコンは電源切らないで使い続けていた方が余命が伸びるというのは根拠のないことではない。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

CEATEC Japan 2007 10/5

2007年09月24日 04時02分32秒 | Weblog
CEATEC Japan 2007 は10/5 の午後に行きますので、事前登録していない人は早めにお願いします(業務連絡)。
幕張メッセというと広い、遠いというイメージだが、以下のように今年は 11 ホール全部使用するそうだ(全部見るのは無理か?)。昨年は東京ゲームショウも行ったが、これと比べる空いている。昨年までは一般参加者は確かに少なそうだったが、今年は一般消費者向け展示が強化されることになる。確かに今までの展示だと業界関係者や専門家などには興味深いだろうが、一般向けでは無かった。自動車関係の完成品の展示も増えて賑やかな感じになりそうだ。


CEATEC JAPAN 2007は20万人の来場を見込む,一般消費者向けの展示も強化

主催者あいさつを行う半田力 電子情報技術産業協会専務理事
 2007年10月2日~6日まで開催予定の「CEATEC JAPAN 2007」は,前回まで8つ使用していた幕張メッセのホールを今回はすべて(11ホール)使用し,来場者数も過去最高となる20万人を見込んでいる。2007年7月19日に行われた記者会見の中で主催者側が明らかにした。
 CEATEC JAPANは,エレクトロニクスやITの関連企業が参加して毎年行われる展示会で,8回目の開催となる。テーマは「見える,感じる,デジタルコンバージェンス最前線」である。情報通信ネットワーク産業協会(CIAJ)とコンピュータソフトウェア協会(CSAJ),電子情報技術産業協会(JEITA)の3団体が主催する。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Linpack 測定その2

2007年09月23日 04時38分38秒 | Weblog
前回に行き続いて Power クラスタの Linpack 測定を行った。HPL 用の強化版 GotoBLAS とパラメータチューニングなどによって、227.6GFlops から 239.4GFlops に向上した。このクラスタのピーク性能は 298.24GFlops (2.33GHz × 4 × 32 コア = 298.24) なので性能効率は 80.2パーセント(239.4 / 298.24)になる。とりあえず当面の目標(80パーセント)をクリアした。まだ出来ることはあるので、もう少し行けそうな感じがする。そろそろバトンタッチしてもいいだろう。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

首都高新料金

2007年09月22日 03時33分55秒 | Weblog
首都高も ETC を必須として新料金を導入すると言われていたが、その新料金案が出てきた。自分自身も今までの利用方法を振り返るとほとんどの場合において、値上げになることは確実だ。ETC が無く現金で払う場合には 1200 円と大幅値上げなので、まずこの料金案を歓迎する人は少ないように思う。
首都高以外にも ETC を利用した様々な割引があるが、次世代のカーナビゲーションシステムはこれらの料金体系に対応する必要がある。カーナビ自体が多目的になるが、首都高を短い区間で2回乗り降りしても 600円で、現行の 700 円よりも安いので、最短路の計算がかなり複雑になる。

首都高がETC優遇の新料金案、現金は都内一律1200円

 距離別料金の導入を検討している首都高速道路会社は20日、新料金案を公表した。東京都内で現在、一律700円の普通車は、距離に応じて400~1200円となる。いずれも、ノンストップ自動料金収受システム(ETC)の利用を前提にした料金体系で、現金払いの場合は上限料金1200円が適用される。来年10月をめどに実施予定だが、距離によっては大幅な値上げとなるため、利用者の反発も予想される。 新料金案は、ETC利用の普通車について、都内のほか、一律600円の神奈川県内では400~1100円に、一律400円の埼玉県内では300~550円とし、利用距離に応じて、初乗り料金に50円刻みで上積みする仕組みだ。
 都内の場合、利用距離が3キロ未満では現在より300円安い400円になるが、19キロ以上から現在の料金を上回り、32・5キロ以上は500円の値上げの1200円になる計算だ。
 一方、ETCを搭載しない現金支払いの利用者は、それぞれの路線の上限料金を入り口で支払わなければならない。大型車の料金は普通車の倍となる。
 首都高のETC利用率は平均約76%(今年7月)だが、国土交通省によると、都内で登録されている四輪車両のETC搭載率は約64%(8月末)にとどまっている。同社では、ETC未搭載車については、電子マネーを使った支払い方法を取り入れるなど、軽減策も検討している。
 同社では、ホームページで利用者の意見を募集し、来春までに最終案をまとめる。
(2007年9月20日22時58分 読売新聞)
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Linpack 測定

2007年09月21日 01時18分09秒 | Weblog
研究の合間?に Power クラスタの Linpack 測定を行った(227.6GFlops)。

HPLinpack benchmark input file
Innovative Computing Laboratory, University of Tennessee
HPL.out output file name (if any)
6 device out (6=stdout,7=stderr,file)
1 # of problems sizes (N)
60000 Ns
1 # of NBs
200 NBs
0 PMAP process mapping (0=Row-,1=Column-major)
1 # of process grids (P x Q)
4 Ps
8 Qs
16.0 threshold
1 # of panel fact
1 PFACTs (0=left, 1=Crout, 2=Right)
1 # of recursive stopping criterium
4 NBMINs (>= 1)
1 # of panels in recursion
2 NDIVs
1 # of recursive panel fact.
1 RFACTs (0=left, 1=Crout, 2=Right)
1 # of broadcast
1 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM)
1 # of lookahead depth
0 DEPTHs (>=0)
2 SWAP (0=bin-exch,1=long,2=mix)
64 swapping threshold
0 L1 in (0=transposed,1=no-transposed) form
0 U in (0=transposed,1=no-transposed) form
1 Equilibration (0=no,1=yes)
16 memory alignment in double (> 0)

----------------------------------------------------------------------------

- The matrix A is randomly generated for each test.
- The following scaled residual checks will be computed:
1) ||Ax-b||_oo / ( eps * ||A||_1 * N )
2) ||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 )
3) ||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo )
- The relative machine precision (eps) is taken to be 1.110223e-16
- Computational tests pass if scaled residuals are less than 16.0

============================================================================
T/V N NB P Q Time Gflops
----------------------------------------------------------------------------
WR01C2C4 60000 200 4 8 632.75 2.276e+02
----------------------------------------------------------------------------
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0147240 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0035790 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0006828 ...... PASSED
============================================================================

Finished 1 tests with the following results:
1 tests completed and passed residual checks,
0 tests completed and failed residual checks,
0 tests skipped because of illegal input values.
----------------------------------------------------------------------------

End of Tests.
============================================================================
コメント (2)
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

SDPA Online Solver 変更 その2

2007年09月20日 03時37分05秒 | Weblog
今回の変更点

Power クラスタにおいて SDPARA, SDPARA-C を実行するときの環境を変更した。Myrinet-10G では mx ドライバ(1.2.2)を用いて、MPI は mpich2-mx-1.0.5p4-beta2 を用いた。SDPA Online Solver からは使用しないが、mpich-mx-1.2.7..5 もインストールした。mx ドライバ + mpich-mx の組み合わせは、かなり強烈であり、Linpack の測定(HPL + GotoBLAS)で今までの研究室記録をあっさりと抜いてしまった(パラメータチューニングでまだまだ上がりそうだ)。

旧 SDPA クラスタ(40台:80CPU) : CPU Athlon MP 2400+ (2GHz), ネットワーク 1000BASE-T × 2 (SCore 5.8.x による network trunking : MTU=9000)
Linpack = 約 160GFlops (BLAS = ATLAS)

Power クラスタ(4台:8CPU:32コア) : CPU Xeon E5345 (2.33GHz), ネットワーク Myrinet-10G (mx モード : MTU=9000)
Linpack = 軽く 217 GFlops (BLAS = GotoBLAS)

mpich2-mx がベータ版という理由があるかもしれないが、mx + mpich2-mx の方が mx + mpich-mx よりもやや遅めになっている。それでも mx ドライバなしの mpich2 よりは相当速くなっている。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

SDPA Online Solver 変更

2007年09月19日 20時42分31秒 | Weblog
SDPA Online Solver の変更点

1: SDPA 7.0.2 を使用するときに LP ブロック(対角ブロック)が最後のブロックでないと問題が解けなくなる事態を回避した。当面はこの対策で十分だが、根本的な対策ではない。

2: Power クラスタにおいて SDPARA, SDPARA-C を実行するときに MPICH2 で用いるネットワークカードを Gigabit Ethernet から Myrinet-10G (MX ドライバ上で 10G Ethernet として使用)に変更

3: SDPA 7.0.2 とリンクする GotoBLAS を最新の Ver. 1.19 に変更
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

密なSDP と SDPA その2

2007年09月18日 02時23分31秒 | Weblog
以前のブログで紹介した実験だが、もう少し大きな問題を解いてみる。基本的にはκが大きくなると ddot が減って、dgemm の時間が増えていくの変わらないが、daxpy の実行時間が大きく変動するので、全体の実行時間にもこの変動に影響されている。
しかしこれはデータが密な場合なので、疎な場合には量子化学などでκの影響をほとんど受けないという結果になっている。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Myrinet-10G

2007年09月17日 01時50分35秒 | Weblog
Myrinet-10G が到着したので写真のように Dell の PowerEdge の PCI-Express x8 に挿入した。あとは HP 製の ProCurve Switch 5406zl スイッチに 10GbE のモジュールを付けて CX4 のケーブルで各マシンの Myrinet-10G まで接続した。
次は Myrinet-10G のイーサネットドライバをダウンロードして make する(その前に yum install kernel-devel が必要)。スイッチにシリアル接続して Jumbo Frame の設定を行う。これでとりあえず Myrinet-10G が MTU=9000 で動作するようになった。性能はイマイチなので、チューニングを行ったり、MX ドライバを入れる必要がある。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

密なSDP と SDPA

2007年09月16日 04時01分40秒 | Weblog
SDPA では dgemm 演算(倍精度行列積)が大変の実行時間を占めていることが多いのだが、良く考えたら密(Dense)な SDP ではそのようにならないことに気がついた。画像中のパラメータκは Schur complement 行列の計算方法を決定するためのもので、通常は固定している。この場合は三つの演算(daxpy : 倍精度ベクトルの乗算と加算, ddot : 倍精度ベクトルの内積, dgemm)の実行時間が多くを占めている。κが大きくなると ddot 演算の回数が減るので、dddot の実行時間も減って、結果的に全体の実行時間も減ることがわかる(dgemm の実行時間はあまり増えない)。やはり Level 1 の演算はデータ再利用性が低く、CPU の性能が活かせないので、Level 3 の演算に変換できるならば変換してしまった方が良い場合もあるだろう。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする