SDPA クラスタで Linpack 測定 その９

mpich2-mx-1.0.7..2 + mx 1.2.6 から mpich-mx_1.2.7..7.tar.gz + mx 1.2.6 に変更したところ、少しだけ性能が上がって 1.434TFlops = 88.62% になった。

●新 SDPA クラスタ (2008年)
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
HDD : 6TB(RAID 5) / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.2 for x86_64
Linpack : R_max = 1.434TFlops, R_peak = 1.618TFlops, R_max / R_peak = 88.62%


============================================================================
T/V N NB P Q Time Gflops
----------------------------------------------------------------------------
WR11C2C4 310000 200 4 8 13848.83 1.434e+03
----------------------------------------------------------------------------
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0116097 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0008188 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0001353 ...... PASSED
============================================================================

SDPA クラスタで Linpack 測定 その８

まずは HugeTLBfs の設定を SDPA クラスタで行う。その後、HugeTLBfs を利用するように書き換えられた HPL を用いて Linpack 測定を行う。前回 1.423TFlops から 1.432TFlops へ 9GFlops の上昇が見られた。これで効率(R_max / R_peak)は 88% を突破して 88.50% になった。

●新 SDPA クラスタ (2008年)
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
HDD : 6TB(RAID 5) / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.2 for x86_64
Linpack : R_max = 1.432TFlops, R_peak = 1.618TFlops, R_max / R_peak = 88.50%

============================================================================
T/V N NB P Q Time Gflops
----------------------------------------------------------------------------
WR11C2C4 310000 200 4 8 13864.99 1.432e+03
----------------------------------------------------------------------------
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0228975 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0016148 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0002668 ...... PASSED
============================================================================

Amazon Elastic Compute Cloud (Amazon EC2)

Xen の仮想マシンが提供される Amazon EC2 は使用価格が安いのでランニングコストでの評判は良いようだ。
一番安い選択では以下のように 1 時間あたりで 0.1$ (現在のレート 1$ = 100円 だと1ヶ月で約 7200 円)になる。現在の最短路問題用のプログラムだと全米データでも 1.7GB メモリ, 160GB のストレージ量でも足りると思われる。ただし、仮想マシン上での性能低下についてはまだ調査を行っていない。
現時点では計算用のサーバは足りているので借りる必要はないのだが、将来的には拡張された Web サービスで Amazon EC2 などを利用することも十分考えられる。

Standard Instances
* $0.10 – Small Instance (Default) 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform

* $0.40 – Large Instance 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform

* $0.80 – Extra Large Instance 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform

SDPA クラスタで HugeTLBfs その２

SDPA クラスタで HugeTLBfs の設定を行い、HPL(Linpack)や SDPARA の実行を行いたいのだが、その前にいろいろと試して、どのようなプログラムが HugeTLBfs に適しているのかを調べている。

○SDPA 7.2.0 + GotoBLAS 1.26(4スレッド)

1: D512.dat(密な問題)
　　static link + HugeTLBfs なし : 12m41.672s
　　static link + HugeTLBfs あり : 13m8.273s
　　dynamic link + HugeTLBfs なし : 12m43.454s
　　dynamic link + HugeTLBfs あり : 10m19.297s

2: s4000n0r1g2FD_R.dat-s(疎な問題)
　　static link + HugeTLBfs なし : 56.150s
　　static link + HugeTLBfs あり : 58.488s
　　dynamic link + HugeTLBfs なし : 56.227s
　　dynamic link + HugeTLBfs あり : 55.611s

HugeTLBSfs 無しは static link, HugeTLBfs ありは dynamic link が良いのでもう一問。

3: CH2.1A1.STO6G.pqg.dat-s(疎な問題)
　　static link + HugeTLBfs なし : 4m14.096s
　　dynamic link + HugeTLBfs あり : 3m47.604s

全ての使用メモリで HugeTLBfs を使った方が良いかについては調査する必要があるが、とりあえずはこのような結果になった。　

Let's note 2008 年冬モデル F8 その２

Let's note は確かに良いところが多いのだが、現在使っている CF-W7 シリーズでは突然、無線 LAN の機能が使えなくなった。無線 LAN 機能は、インテル® Wireless WiFi Link 4965AGN なので、この部分にトラブルが生じたと思われる。OS から無線 LAN のチップが認識されないだけではなく、BIOS の画面からも無線 LAN の項目が消えてしまった。
それはともかく、まだ発売前の 冬モデル F8 だが、実際に持ってみたり、動かしてみる機会があった。ただし、OS が Vista で初期状態なので、どれくらいの性能が出るのかイマイチ良くわからない。XP でいろいろとインストールした後の速さを見てみたいのだが、これは無理なので過去の経験から推測するしかない。Panasonic 側としては、持ち運びハンドルの評判が気になるようで、ブルーレイのドライブ搭載はまだもう少し先になるとのこと。

UPS

Web & メールサーバ等 3 台, クラスタ計算機 PowerEdge 2900III 16 台, PowerEdge 1900 4 台などを稼働させている。他にも稼働しているノードは多数あるが、これらは動作検証用などのマシンなので、サーバとして重要なのは上記の 23 台である。今まで UPS については真面目に考えていなかったので、ファイルサーバなどの数台だけを UPS に繋いであるだけである。停電時の自動 shutdown には対応させていないので、瞬間停電には対応できても、長期停電になった場合には、やはり対応できない。そのため上記の 23 台の電源バックアップと自動シャットダウンなどについて真面目に検討することにした。
例えば PowerEdge 2900III だと、最大で 5A ぐらいなので、16 台 x 100V x 5A = 8kVA となり、これだけならば 10kVA の UPS で十分である。全部で 15kVA もあれば、将来的な拡張にも十分対応できる見込みだ。

SDPA クラスタで HugeTLBfs その１

●新 SDPA クラスタ (2008年)
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
HDD : 6TB(RAID 5) / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.2 for x86_64
Linpack : R_max = 1.423TFlops, R_peak = 1.618TFlops, R_max / R_peak = 87.94%

SDPA クラスタで HugeTLBfs を使用してみることにしたので、以下のように設定を開始する。
まずは /huge 等を作る。

mkdir /huge　として、その後に /etc/rc.local に以下の２行を加える。

/bin/mount -t hugetlbfs hugetlbfs /huge -o rw,mode=0777
/bin/echo 23808 > /proc/sys/vm/nr_hugepages

この場合では、1 単位で 2Mbyte なので、23808 個分 HUgeTLBfs を定義すると、 23808 x 2Mbyte によって、46.5Gbytes を確保したことにある。その後で以下のように書いて実行を行う,

HUGETLB_MORECORE=yes LD_PRELOAD=libhugetlbfs.so ./sdpa .........................

Let's note 2008 年冬モデル F8

Let's note の冬モデルが発表されていて、W シリーズだと夏モデルとあまり変わらない感じがするが、新しく F シリーズが発表されている。現在では 5 万円程度のノートパソコンも多く出荷されているので、それが４、５台変えるようなこの値段帯のノートパソコンには相当大きな付加価値が求められている。Let's note は結構人気があるようで、職場などの周りでも非常に多くの Let's note を見かける。やはり大事なことは、軽い、丈夫で壊れにくい、長時間バッテリーそれに Windows XP が選べるということらしい。それに加えてこの F8 シリーズは Intel Core2 Duo SP9300 2.26GHz 搭載で画面も 14.1 インチ型、1440 X 900 ドットということで、ちょっと欲しくなってきた。

SDPA クラスタで Linpack 測定 その７

最適化オプションの指定を変えて変更したところ、1.423TFlops(87.94%)まで性能が上がった。

●新 SDPA クラスタ (2008年)
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
HDD : 6TB(RAID 5) / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.2 for x86_64
Linpack : R_max = 1.423TFlops, R_peak = 1.618TFlops, R_max / R_peak = 87.94%

============================================================================
T/V N NB P Q Time Gflops
----------------------------------------------------------------------------
WR10R2R4 310000 200 4 8 13955.11 1.423e+03
----------------------------------------------------------------------------
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0234535 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0016540 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0002733 ...... PASSED
============================================================================

SDPA クラスタで Linpack 測定 その６

SDPA クラスタでの Linpack 測定だが、後藤さんのおかげで 1.415 TFlops に達した。性能比率は 1.415 / 1.61792 = 87.45% となった。いつものようにマルチスレッドで動作させるときのコアの割り当てだけではなく、MPI の Rank によって割り当てる CPU を指定する必要がある。
今後は OpenMPI の採用、HugeTLBfs の使用、不必要なプロセスの停止などを予定している。これらは SDPARA の実行にも影響を与えるかもしれない。

●新 SDPA クラスタ (2008年)
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
HDD : 6TB(RAID 5) / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.2 for x86_64
Linpack : R_max = 1.415TFlops, R_peak = 1.618TFlops, R_max / R_peak = 87.45%

============================================================================
T/V N NB P Q Time Gflops
----------------------------------------------------------------------------
WR10R2R4 300000 200 4 8 12719.44 1.415e+03
----------------------------------------------------------------------------
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0011071 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0017166 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0002822 ...... PASSED
===========================================================================

初代 Opteron 対 Pentium 4 対 Atom

恒例？のベンチマークテストで今回は Pentium 4 (2002 年)が参加する。Pentium 4 で初めて hyperthreading technology に対応したチップでクロック周波数は 3.06GHz になる。今回も Atom の負けなので現在全敗中。Celeron 466MHz (1999年)というマシンがあるがさすがにこれは Atom が勝てそうだ。Opteron と Pentium 4 の性能は同じような感じなのに、SDPA (特に疎な問題)では Pentium 4 の方がかなり速い。

○ Opteron
自作 PC
CPU : AMD Opteron 240 1.4GHz
メモリ : 2GB
OS : Fedora 9 for x86_64

○ Pentium 4
Dell Dimension 8250
CPU : Pentium 4 3.06GHz
メモリ : 2GB
OS : Fefora 9 for x86

○ Atom
MSI Wind PC
CPU : Intel Atom 230 1.6GHz
メモリ : 1GB
OS : Ubuntu 8.04 Server for x86_64

1: GLPK 4.31 整数計画問題
○ stein27.mps
Opteron : 4.045s
Pentium 4 : 5.647s
Atom : 10.140s
○ air06
Opteron : 44.296s
Pentium 4 : 49.989s
Atom : 57.911s
○ min_rep_under_thput_39600.0_test18.dat(ファイル配置最適化問題)
Opteron : 11.172s
Pentium 4 : 11.455s
Atom : 20.955s


2: 最短路問題
○ FLA 10 クエリ(データ名は最短路問題オンライン・ソルバーと同じ)
Opteron : 2.021s
Pentium 4 : 2.023s
Atom : 2.940s
○ LKS 10 クエリ
Opteron : 6.071s
Pentium 4 : 6.679s
Atom : 9.718s

3: SDP (半正定値計画問題) : SDPA 7.2.0 + GotoBLAS 1.26(Opteron & Pentium 4) or GotoBLAS 1.27(Atom) : 1 スレッド
○ mcp500-1.dat-s
Opteron : 17.203s
Pentium 4 : 10.456s
Atom : 28.956s
○ theta5.dat-s
Opteron : 105.367s
Pentium 4 : 70.017s
Atom : 182.914s
○ mater-4.dat-s
Opteron : 21.116s
Pentium 4 : 15.970s
Atom : 28.589s

SDPARA の SDPA クラスタ上での実行 その２

本の原稿のために実験結果を最新のものに変更した。昨日の図を見てもらえればわかるのだが、MPI で 128 プロセス(16ノード×8コア)使うということは、1ノードで 8 プロセス使うということなので、二つのコアが一つの L2 キャッシュを共有することになって、性能が落ちることになる。実際に添付の表の結果を見ると 64 台（プロセス）と 128 台（プロセス）では、64 台の方が速くなっている。これが Linpack 測定だと 64 台よりも 128 台の方が速いので、SDPARA の方がキャッシュやメモリ使用などで改善の余地があることがわかる。今考えている方法は、
１：問題自体を前処理して、現在のプログラムでも性能が出るようにする。
２：プログラムの疎性を扱う部分のアルゴリズムを変更する。
ということなので、両方行うことになる可能性が高い。昔は１ノードで 1CPU か 2CPU(しかもシングルコア）だったので、台数効果がわかりやすい形で出てきたが、現在はマルチコアの CPU なので、その辺の効果はやや複雑になっている。

SDPARA の SDPA クラスタ上での実行 その１

TORQUE を SDPA クラスタにインストールしたので、大規模実験が随分楽になった（もっと早めにすれば良かった）。CentOS 5.2 を使用しているので kernel 2.6.18 になるが、各コアに対するジョブの割り当ては思ったよりも優秀だ。例えば添付の図は Intel Xeon 5460 (クアッドコア) × 2 個のときの、各コアの通し番号を示しているが、このノードに MPI で４個のプロセスを割り当てたときには、コア 0, 2, 1, 3 のように同じ L2 キャッシュを共有しないようにコアを使用している。とは言っても実行中に コア 0 を使ったり、コア 4 を使ったりと動的に変化するので、やはり numactl で固定した方が良い。

初代 Opteron 対 Atom

Intel Atom (Atom 230 : 1.6GHz : 2008年) と初代 AMD Opteron (Opteron : 1.4GHz : 2003年)を比較したところ、Opteron の圧勝だった。

○ Opteron
自作 PC
CPU : AMD Opteron 240 1.4GHz
メモリ : 2GB
OS : Fedora 9 for x86_64

○ Atom
MSI Wind PC
CPU : Intel Atom 230 1.6GHz
メモリ : 1GB
OS : Ubuntu 8.04 Server for x86_64

○ Pentium M
自作 PC
CPU : Pentium M 2.0GHz
メモリ : 1GB
OS : Vine Linux 4.2 for x86


1: GLPK 4.29 整数計画問題
○ stein27.mps
Opteron : 4.045s
Atom : 10.140s
Pentium M : 3.857s
○ air06
Opteron : 44.296s
Atom : 57.911s
Pentium M : 26.042s
○ min_rep_under_thput_39600.0_test18.dat(ファイル配置最適化問題)
Opteron : 11.172s
Atom : 20.955s
Pentium M : 39.298s

2: 最短路問題
○ FLA 10 クエリ(データ名は最短路問題オンライン・ソルバーと同じ)
Opteron : 2.021s
Atom : 2.940s
Pentium M : 2.405s
○ LKS 10 クエリ
Opteron : 6.071s
Atom : 9.718s
Pentium M : 6.437s

3: SDP (半正定値計画問題) : SDPA 7.2.0 + GotoBLAS 1.26(Opteron & Pentium M) or GotoBLAS 1.27(Atom) : 1 スレッド
○ mcp500-1.dat-s
Opteron : 17.203s
Atom : 28.956s
Pentium M : 24.394s
○ theta5.dat-s
Opteron : 105.367s
Atom : 182.914s
Pentium M : 119.425s
○ mater-4.dat-s
Opteron : 21.116s
Atom : 28.589s
Pentium M : 20.134s

SDPA クラスタと TORQUE

SDPA クラスタに TORQUE Resource Manager をインストールした(Ver. 2.3.3)。/var/spool/torque/server.conf はとりあえず以下のように設定した。これで SDPA クラスタも Online Solver に参加可能だが、しばらく SDPARA や最短路の研究に使うので、公開はその後の予定になる。

○server.conf

#
# Create and define queue dque
#
create queue sdpa@sdpa01.indsys.chuo-u.ac.jp
set queue sdpa@sdpa01.indsys.chuo-u.ac.jp queue_type = Execution
set queue sdpa@sdpa01.indsys.chuo-u.ac.jp enabled = True
set queue sdpa@sdpa01.indsys.chuo-u.ac.jp started = True
#set queue sdpa@sdpa01.indsys.chuo-u.ac.jp resources_max.nodect=4
#set queue sdpa@sdpa01.indsys.chuo-u.ac.jp resources_max.nodes=4
set queue sdpa@sdpa01.indsys.chuo-u.ac.jp resources_max.ncpus=8
set queue sdpa@sdpa01.indsys.chuo-u.ac.jp resources_max.mem=40gb

#
# Set server attributes.
#
set server sdpa01.indsys.chuo-u.ac.jp scheduling = True
#set server default_queue = sdpa@sdpa01.indsys.chuo-u.ac.jp
#set server log_events = 511
#set server mail_from = adm
#set server scheduler_iteration = 600