SDPA と affinity の設定

以下の結果等から考察してみると 4-way のシステムでは affinity の設定が重要となる。計算サーバ２においても affinity の設定の効果を見てみないとわからないが、ベストの設定を行えば、SDPA の性能的には Nehalem-EX 32 コア > Magny-Cours 48 コアになると予想される。

◯FH2+.1A1.STO6G.pqgt1t2p.dat-s
計算サーバ１： 53.01s
計算サーバ１： 45.68s (numactl -i all)
計算サーバ２： 47.23s

◯Be.1S.SV.pqgt1t2p.dat-s
計算サーバ１： 2042.51s
計算サーバ１： 723.74s (numactl -i all)
計算サーバ２： 786.97s

○計算サーバ１ (4 CPU x 12 コア = 48 コア)
CPU : AMD Opteron 6174 (2.20GHz / 12MB L3) x 4個
メモリ : 256GB

◯計算サーバ２ (4CPU x 8 コア = 32 コア)
CPU : Intel Xeon X7550 (2.0GHz / 18MB L3) x 4個
メモリ : 512GB

SCOPE 研究会（次回）と JORSJ 特集号

次回の SCOPE 研究会は以下の日程と内容で行います。場所がいつもの６号館ではなく３号館となっています。当日参加できない方からは USTREAM 中継等を行って欲しいという希望がありますが、講演者の承諾を得られるのか難しいところです（主催者側としては前向きに考えてはいます）。

また、JORSJ の論文誌で”計算と最適化の新展開”関連の特集号を組む可能性もありますので、その際はご協力等をお願い致します。

○2011年度第1回 SCOPE
日　時 ： 2011年3月19日（土）14:00～
会　場 ： 中央大学 後楽園キャンパス 3 号館 3300 号室（いつもと場所が異なります）
講演1
講演者 ： 北原知就氏 (東京工業大学 大学院社会理工学研究科 経営工学専攻)
題目 ： 単体法によって生成される実行可能基底解の個数の上界について
概要　 ： 単体法は線形計画問題に対する最初の解法で，実用上は非常に効率的であることが知られている。しかし，一般的な線形計画問題に対する単体法の反復回数の評価はほとんど知られていない．その大きな障害となっているのが，Klee-Mintyによって発表された単体法が指数回の反復回数を必要とし得るという事実である．北原-水野(2010年)はマルコフ決定問題に対するYeの解析(2010年)を応用し，単体法が生成する実行可能基底解の上界を示した。得られた上界は問題の制約式の個数、変数の個数，およびすべての実行可能基底解の正の要素の最大値と最小値の比，の多項式で表される．そして問題が非退化のとき，この上界は反復回数の上界となる。本講演では、上界を得るための解析について詳しく説明する。また，新たに開発した簡易版Klee-Minty問題を使い，良い上界が得られていることを示す．

講演2
講演者 ： 今野浩氏　 (中央大学 理工学部 経営システム工学科)
題目 ： TBA

2010年度第5回 SCOPE講演会

2010年度最後の SCOPE 講演会は本日開催です。是非ご参加下さい。

○2010年度第5回 SCOPE 講演会
日　時 ： 2011年2月26日（土）14:00～
会　場 ： 中央大学 後楽園キャンパス 6 号館　6402号室
講演1
講演者 ： Thorsten Koch氏 （Zuse Institute Berlin(ZIB), Berlin）
Title: How to survive Real-World Projects as a Mathematician
(Lessons and experiences from 10 years of industry projects)

Abstract: This talks aims at sharing the experience from 10 years of
successfully employing integer programming in industry projects with the
audience. After numerous research-industry collaboration projects we
found that there are several reoccurring topics during these projects.
The problems encountered seem to be universally the same, as there are
very common misunderstandings between the partners. We will try to draw
some general conclusions and using the projects of the author as
examples to show some common pitfalls. We will talk about acquiring
projects, getting them running and how to explain the results to
practitioners. Listening to this talk requires no particular knowledge
of mathematics.

講演2
講演者 ： 品野勇治氏　（Zuse Institute Berlin(ZIB), Berlin）
Title: Parallel MIP solvers developed at ZIB: current state of the art
Abstract:
混合整数計画(MIP: Mixed Integer Programming)ソルバの近年の性能向上は著しく，
様々な現実問題が混合整数計画問題に定式化され解かれるケースも増えつつある．
商用の混合整数計画ソルバの多くは，既にマルチ・スレッド化され並列化されて
いる．本講演では，ZIB(Zuse Institute Berlin)で開発されている並列混合整数
計画ソルバ群について紹介する．並列混合整数計画ソルバは，既存の混合整数計画
ソルバを並列化する共通のソフトウェア・フレームワーク上に構築されている．
そのフレームワークの概要と，北ドイツ最大のスーパーコンピュータHLRN IIによる
最新の数値実験結果（１ジョブの実行に最大7,168コアを利用）について報告する．

巨大 SDP での比較実験 その２

以下の巨大な SDP を用いて SDPA と CSDP の比較実験を行った。実行時間(反復回数）や DIMACS の指標などを掲載している。

ELEMENS : Schur complement matrix の要素の計算
CHOLESKY : Schur complement matrix の Cholesky 分解

○問題１：H2O.1A1.DZ.pqgt1t2p.dat-s
○問題２：esc32a_r2.dat-s
○問題３：TSPeil51.dat-s
○問題４：r3_l.dat-s



○計算サーバ (2 CPU x 6 コア = 12 コア)
CPU : Intel Xeon X5670(2.93GHz / 12MB L3, 6.4 GT/s QPI) x 2個
メモリ： 128GB (16X8GB/2R/1333MHz/DDR3 RDIMM/CPUx2)
OS : Fedora 14 for x86_64

Intel® Math Kernel Library Link Line Advisor

Intel の MKL ライブラリは以下のように様々な種類が存在するので、実際に使用する場合ではどのライブラリをどんな順番でリンクするかについてはわかりにくいとの評判になっている。

libmkl_avx.so libmkl_blas95_lp64.a libmkl_intel_ilp64.a libmkl_p4n.so libmkl_solver_lp64.a
libmkl_blacs_ilp64.a libmkl_cdft_core.a libmkl_intel_ilp64.so libmkl_pgi_thread.a libmkl_solver_lp64_sequential.a
libmkl_blacs_intelmpi_ilp64.a libmkl_cdft_core.so libmkl_intel_lp64.a libmkl_pgi_thread.so libmkl_vml_avx.so
libmkl_blacs_intelmpi_ilp64.so libmkl_core.a libmkl_intel_lp64.so libmkl_rt.so libmkl_vml_def.so
libmkl_blacs_intelmpi_lp64.a libmkl_core.so libmkl_intel_sp2dp.a libmkl_scalapack_ilp64.a libmkl_vml_mc.so
libmkl_blacs_intelmpi_lp64.so libmkl_def.so libmkl_intel_sp2dp.so libmkl_scalapack_ilp64.so libmkl_vml_mc2.so
libmkl_blacs_lp64.a libmkl_gf_ilp64.a libmkl_intel_thread.a libmkl_scalapack_lp64.a libmkl_vml_mc3.so
libmkl_blacs_openmpi_ilp64.a libmkl_gf_ilp64.so libmkl_intel_thread.so libmkl_scalapack_lp64.so libmkl_vml_p4n.so
libmkl_blacs_openmpi_lp64.a libmkl_gf_lp64.a libmkl_lapack95_ilp64.a libmkl_sequential.a locale
libmkl_blacs_sgimpt_ilp64.a libmkl_gf_lp64.so libmkl_lapack95_lp64.a libmkl_sequential.so
libmkl_blacs_sgimpt_lp64.a libmkl_gnu_thread.a libmkl_mc.so libmkl_solver_ilp64.a
libmkl_blas95_ilp64.a libmkl_gnu_thread.so libmkl_mc3.so libmkl_solver_ilp64_sequential.a

そのため、以下のように Intel® Math Kernel Library Link Line Advisor という Web ページが用意されている。

http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/

例えば Linux + Intel64 + Intel C/C++ + Static link + ILP64 (64bit integer) + multi-threaded + OpenMP の場合では、以下のオプションを使用することになる。MPI 関係の呼び出しにも対応している。

-Wl,--start-group $(MKLROOT)/lib/intel64/libmkl_intel_ilp64.a $(MKLROOT)/lib/intel64/libmkl_intel_thread.a $(MKLROOT)/lib/intel64/libmkl_core.a -Wl,--end-group -openmp -lpthread

四つの中心性と DIMACS USA データ

以前にも説明したように、グラフの各点の重要度を計る指標として中心性(Centrality)があり、以下の４つなどが有名である。お勧めは Betweenness Centrality
である。クラスタリングやグラフ分割等とは異なり大域的な情報を用いて簡単に各点の重要度を判定することができる。

1: Closeness Centrality
2: Graph Centrality
3: Stress Centrality
4: Betweenness Centrality



厳密な計算ではなく、1000 点のランダムサンプリングによる中心性の計算結果になる。プログラムの工夫によって４つの中心性を同時に効率良く計算することができる。色が青から赤になるに連れて重要度は上がっていく。

巨大 SDP(H2O)と計算結果 その３

以下のブロック対角構造を持つ大きな SDP(量子化学の T2Prime 条件が付いた水分子(H2O)の基底状態でのエネルギー計算)に関する記事は過去にも何回か書いているので、例えばこちらなどを参照していただきたい。以前は解くのに大変苦労した大きなサイズの SDP であるが、最近のソルバーと計算機の能力から見ると気軽にベンチマーク問題として使用できるレベルになってきた。

問題名 : H2O.1A1.DZ.pqgt1t2p.dat-s


SDPARAによる、これまでの結果（実行マシンと計算時間等）は以下の通りである。

2006年
○産総研 AIST Super Cluster M64
2,060,237.619s(8CPU) ～ 24 日
2010年
○SDPA クラスタ
49,037.9s(32CPU x 4コア = 128コア) ～ 13.6 時間
○京大 T2K スパコン
27,523.8s(512CPU x 4コア = 2048コア) ～ 7.6 時間
○計算サーバ
809,261.3s(12コア) ～ 224.8時間(9.4日)
○新クラスタ計算機
32,379.1s(32CPU x 6コア = 192コア) ～ 9時間

クラスタ計算機等で SDPARA を用いなくても、メモリ搭載量の大きなサーバ上で SDPA を用いることによって解くことができる。
以下の計算サーバ２(48コア : Magny-Cours)では、遂に 52.7 時間で解くことができた（１サーバでは新記録)。

◯ソフトウェア SDPA 7.3.3 + GotoBLAS2 1.09 + MUMPS 4.9.2(全て ILP64 対応済み)

○計算サーバ１ (2 CPU x 6 コア = 12 コア)
CPU : Intel Xeon X5670(2.93GHz / 12MB L3, 6.4 GT/s QPI) x 2個
メモリ： 128GB (16X8GB/2R/1333MHz/DDR3 RDIMM/CPUx2)
OS : Fedora 14 for x86_64

Make bMat time = 325615.410191, 98.967555
Cholesky bMat = 2224.704378, 0.676177
makedX = 358.400734, 0.108932
makedXdZ = 423.330152, 0.128667
Main Loop = 329012.280619, 100.000000
Total = 329022.309176, 100.003048

329,022.30秒 = 91.4時間(38反復)


○計算サーバ２ (4 CPU x 12 コア = 48 コア)
CPU : AMD Opteron 6174 (2.20GHz / 12MB L3) x 4個
メモリ : 256GB (16 x 16GB / 1066MHz)
OS : Fedora 14 for x86_64

Make bMat time = 188045.009399, 99.007619
Cholesky bMat = 948.128923, 0.499200
makedX = 169.111246, 0.089039
makedXdZ = 303.963261, 0.160040
Main Loop = 189929.837494, 100.000000
Total = 189947.080959, 100.009079

189,947.08秒 = 52.7時間(38反復)

2010年度第5回 SCOPE講演会

2010年度最後の SCOPE 講演会開催は今週の土曜日となりました。是非ご参加下さい。

○2010年度第5回 SCOPE 講演会
日　時 ： 2011年2月26日（土）14:00～
会　場 ： 中央大学 後楽園キャンパス 6 号館
講演1
講演者 ： Thorsten Koch氏 （Zuse Institute Berlin(ZIB), Berlin）
Title: How to survive Real-World Projects as a Mathematician
(Lessons and experiences from 10 years of industry projects)

Abstract: This talks aims at sharing the experience from 10 years of
successfully employing integer programming in industry projects with the
audience. After numerous research-industry collaboration projects we
found that there are several reoccurring topics during these projects.
The problems encountered seem to be universally the same, as there are
very common misunderstandings between the partners. We will try to draw
some general conclusions and using the projects of the author as
examples to show some common pitfalls. We will talk about acquiring
projects, getting them running and how to explain the results to
practitioners. Listening to this talk requires no particular knowledge
of mathematics.

講演2
講演者 ： 品野勇治氏　（Zuse Institute Berlin(ZIB), Berlin）
Title: Parallel MIP solvers developed at ZIB: current state of the art
Abstract:
混合整数計画(MIP: Mixed Integer Programming)ソルバの近年の性能向上は著しく，
様々な現実問題が混合整数計画問題に定式化され解かれるケースも増えつつある．
商用の混合整数計画ソルバの多くは，既にマルチ・スレッド化され並列化されて
いる．本講演では，ZIB(Zuse Institute Berlin)で開発されている並列混合整数
計画ソルバ群について紹介する．並列混合整数計画ソルバは，既存の混合整数計画
ソルバを並列化する共通のソフトウェア・フレームワーク上に構築されている．
そのフレームワークの概要と，北ドイツ最大のスーパーコンピュータHLRN IIによる
最新の数値実験結果（１ジョブの実行に最大7,168コアを利用）について報告する．

Magny-Cours v.s. Istanbul その３

次には SDPA による両者の比較を行う。結果はほぼ予想通りで、一つ行列の領域を分割して同時に並列処理するような場合(行列積、Cholesky 分解等)では、Magny-Cours(計算サーバ２）を導入するメリットはほとんど無い。一方、データ依存関係が少なく、独立した形で並列計算出来る場合では導入のメリットが出てくるようだ。

○問題１：mcp2000-10.dat-s (行列積 dgemm 依存型)
計算サーバ１：57.68秒
計算サーバ１：28.24秒 (numactl -i all)
計算サーバ２：53.32秒
計算サーバ２：31.43秒 (numactl -i all)

○問題２：nug12_r2.dat-s (Cholesky 分解依存型)
計算サーバ１：200.62秒
計算サーバ１：93.32秒 (numactl -i all)
計算サーバ２：133.59秒
計算サーバ２：97.73秒 (numactl -i all)

○問題３：NH3+.2A2\".STO6G.pqgt1t2p.dat-s (F3 式：メモリアクセス依存型)
計算サーバ１：258.94秒
計算サーバ１：227.96秒 (numactl -i all)
計算サーバ２：261.41秒
計算サーバ２：162.21秒 (numactl -i all)

問題３の型であれば、Magny-Cours も意外と使えそうな感じではある。


○計算サーバ１ (4 CPU x 6 コア = 24 コア)
CPU : AMD Opteron 8439 (2.80GHz / 6MB L3) x 4
Memory : 128GB (32 x 4GB / 800MHz)
OS : Fedora 14 for x86_64

○計算サーバ２ (4 CPU x 12 コア = 48 コア)
CPU : AMD Opteron 6174 (2.20GHz / 12MB L3) x 4
Memory : 256GB (16 x 16GB / 1066MHz)
OS : Fedora 14 for x86_64

Magny-Cours v.s. Istanbul その２

今度は計算サーバ１と２を用いて最短路問題を解いてみた。今度は MIP の場合と異なっていて、両者の性能差がはっきりとわかる結果になっている。さらに affinity の設定を行うことによる性能向上も顕著に現れてくる。グラフ探索系では Magny-Cours を有効に使用することもできるだろう。

１：問題 DIMACS LKS データ：1000クエリ
○計算サーバ１；
affinity 設定無し：22.36秒
affinity 設定有り：15.56秒

○計算サーバ２；
affinity 設定無し：14.85秒
affinity 設定有り：9.39秒

２：問題 DIMACS CTR データ：1000クエリ
○計算サーバ１；
affinity 設定無し：231.29秒
affinity 設定有り：173.08秒

○計算サーバ２；
affinity 設定無し：166.44秒
affinity 設定有り：99.53秒

３：問題 DIMACS USA データ：1000クエリ
○計算サーバ１；
affinity 設定無し：278.68秒
affinity 設定有り：212.87秒

○計算サーバ２；
affinity 設定無し：185.77秒
affinity 設定有り：122.07秒

○計算サーバ１ (4 CPU x 6 コア = 24 コア)
CPU : AMD Opteron 8439 (2.80GHz / 6MB L3) x 4
Memory : 128GB (32 x 4GB / 800MHz)
OS : Fedora 14 for x86_64

○計算サーバ２ (4 CPU x 12 コア = 48 コア)
CPU : AMD Opteron 6174 (2.20GHz / 12MB L3) x 4
Memory : 256GB (16 x 16GB / 1066MHz)
OS : Fedora 14 for x86_64

Magny-Cours v.s. Istanbul その１

以下の二つの計算サーバを用いて比較実験を行う。計算サーバ２(Magny-Cours) と計算サーバ１(Istanbul) の理論的な計算性能比は 2.2GHz x 48コア : 2.8GHz x 24 コア = 105.6 : 67.2 = 1.57 : 1 となる。MIP を CPLEX と Gurobi を用いて解いてみたのだが、計算サーバ２の方が遅い例が出てきた。以下の例では Magny-Cours の優位性ははっきりしない。

○問題 S-20-20-2-3.mps（ロットサイズ決定問題）: 最適解 337697
○計算サーバ１
１：CPLEX 12.2.0.2 : 218.55秒

Implied bound cuts applied: 4
Flow cuts applied: 219
Mixed integer rounding cuts applied: 39
Flow path cuts applied: 289
Gomory fractional cuts applied: 19

Root node processing (before b&c):
Real time = 1.27
Parallel b&c, 24 threads:
Real time = 217.28
Sync time (average) = 7.74
Wait time (average) = 0.19
-------
Total (root+branch&cut) = 218.55 sec.

MIP - Integer optimal, tolerance (0.0001/1e-06): Objective = 3.3769700000e+05
Current MIP best bound = 3.3766323187e+05 (gap = 33.7681, 0.01%)
Solution time = 218.59 sec. Iterations = 20676442 Nodes = 1325256 (15413)

２：Gurobi 4.0.1 : 78.02秒
289562 16724 cutoff 42 337696.998 337524.559 0.05% 18.2 75s

Cutting planes:
Gomory: 34
Cover: 37
Flow cover: 269
Flow path: 192

Explored 308448 nodes (5431613 simplex iterations) in 78.02 seconds
Thread count was 24 (of 24 available processors)

○計算サーバ２
１：CPLEX 12.2.0.2 : 162.29秒
Implied bound cuts applied: 7
Flow cuts applied: 230
Mixed integer rounding cuts applied: 41
Flow path cuts applied: 300
Gomory fractional cuts applied: 20

Root node processing (before b&c):
Real time = 1.57
Parallel b&c, 48 threads:
Real time = 160.73
Sync time (average) = 3.89
Wait time (average) = 0.09
-------
Total (root+branch&cut) = 162.29 sec.

Solution pool: 71 solutions saved.

MIP - Integer optimal, tolerance (0.0001/1e-06): Objective = 3.3769700000e+05
Current MIP best bound = 3.3766323062e+05 (gap = 33.7694, 0.01%)
Solution time = 162.33 sec. Iterations = 25689460 Nodes = 1736077 (19169)

２：Gurobi 4.0.1 : 118.31秒
574562 23307 cutoff 53 337697.000 337539.109 0.05% 21.9 115s

Cutting planes:
Gomory: 46
Cover: 50
Flow cover: 325
Flow path: 348

Explored 599849 nodes (12807576 simplex iterations) in 118.31 seconds
Thread count was 48 (of 48 available processors)

--------------------------------------------------------------------------------------------------
○問題 gmpl-10-0.2.mps (仮想マシンマイグレーション問題)：最適解 155
○計算サーバ１
１：CPLEX 12.2.0.2 : 226.91秒
Clique cuts applied: 33
Cover cuts applied: 233
Implied bound cuts applied: 14
Zero-half cuts applied: 10
Gomory fractional cuts applied: 10

Root node processing (before b&c):
Real time = 0.07
Parallel b&c, 24 threads:
Real time = 226.84
Sync time (average) = 10.37
Wait time (average) = 0.92
-------
Total (root+branch&cut) = 226.91 sec.

Solution pool: 5 solutions saved.

MIP - Integer optimal solution: Objective = 1.5500000000e+02
Solution time = 227.01 sec. Iterations = 39342639 Nodes = 8550323

２：Gurobi 4.0.1 : 332.10秒
17036680 2823 154.00000 41 4 155.00000 154.00000 0.65% 4.6 330s

Cutting planes:
Clique: 2
MIR: 10

Explored 17166935 nodes (78343888 simplex iterations) in 332.1 seconds
Thread count was 24 (of 24 available processors)

○計算サーバ２
１：CPLEX 12.2.0.2 : 345.42秒
Clique cuts applied: 33
Cover cuts applied: 239
Implied bound cuts applied: 15
Zero-half cuts applied: 10
Gomory fractional cuts applied: 10

Root node processing (before b&c):
Real time = 0.11
Parallel b&c, 48 threads:
Real time = 345.30
Sync time (average) = 12.58
Wait time (average) = 2.00
-------
Total (root+branch&cut) = 345.42 sec.

Solution pool: 5 solutions saved.

MIP - Integer optimal solution: Objective = 1.5499999179e+02
Solution time = 345.63 sec. Iterations = 72239030 Nodes = 10974216

２：Gurobi 4.0.1 : 221.57秒
H13587647 122 154.0000920 154.00000 0.00% 4.9 221s

Cutting planes:
Cover: 1
Clique: 2
MIR: 10

Explored 13588519 nodes (66009101 simplex iterations) in 221.57 seconds
Thread count was 48 (of 48 available processors)


○計算サーバ１ (4 CPU x 6 コア = 24 コア)
CPU : AMD Opteron 8439 (2.80GHz / 6MB L3) x 4
Memory : 128GB (32 x 4GB / 800MHz)
OS : Fedora 14 for x86_64

○計算サーバ２ (4 CPU x 12 コア = 48 コア)
CPU : AMD Opteron 6174 (2.20GHz / 12MB L3) x 4
Memory : 256GB (16 x 16GB / 1066MHz)
OS : Fedora 14 for x86_64

巨大 SDP での比較実験

巨大な SDP を幾つか選んで SDPA と CSDP の比較実験を行った。やはり競争の激しい分野で世界最高速になるのは簡単ではない。SDPA を使いこなすには大変な面があるものの、多くの SDP において SDPA が最高速であると言っても良いだろう(もちろんスパコン上での SDPARA を除く)。

○問題１：H2O.1A1.DZ.pqgt1t2p.dat-s


SDPA 最新版 + GotoBLAS2 1.09 : 329,022.30秒(38反復)
CSDP 6.1.1 + GotoBLAS2 1.09 : 502,459.12秒(48反復)

○問題２：esc32a_r2.dat-s
SDPA 最新版 + GotoBLAS2 1.09 : 133,039.98秒(46反復)
CSDP 6.1.1 + GotoBLAS2 1.09 : 359,520.69秒(100反復)

○問題３：r3_l.dat-s
SDPA 最新版 + GotoBLAS2 1.09 : 104.40秒(50反復) ; 参考(51.33秒(50反復) : SDPA 最新版 + Intel MKL 10.3)
CSDP 6.1.1 + GotoBLAS2 1.09 : 2816.17秒(38反復)

○問題４：TSPeil51.dat-s
SDPA 最新版 + GotoBLAS2 1.09 : 17,296.57秒(44反復)
CSDP 6.1.1 + GotoBLAS2 1.09 : 39,390.09秒(98反復)

○１サーバ
CPU : インテル(R) Xeon(R) プロセッサー X5670(2.93GHz、12MB キャッシュ、6.4 GT/s QPI) x 2個
メモリ： 128GB (16X8GB/2R/1333MHz/DDR3 RDIMM/CPUx2)
329,022.30秒(1CPU x 12コア = 12コア) ～ 3.8日(91.4時間)

SDPA の Windows 版

SDPA もこちらのページを参考に make すれば Windows 版のバイナリを作成することができる。こちらのソースは Debian パッケージで用いられている SDPA 7.3.4 のソースだが、最新版のソースというわけではない。最新版のソースは現在、Intel コンパイラのみで make することができる(MUMPS の関係で gcc は不可)。以下の結果は同じ計算機で Windows 版バイナリ(SDPA 7.3.4) と Linux 版バイナリ(SDPA 最新版)の性能を比較したものになる。

問題１：control11.dat-s
Windows 版バイナリ + GotoBLAS2 : 458.15秒
Linux 版バイナリ + GotoBLAS2 : 36.92秒

問題２：theta6.dat-s
Windows 版バイナリ + GotoBLAS2 : 34.94秒
Linux 版バイナリ + GotoBLAS2 : 17.87秒

問題３：QC.w.dat-s
Windows 版バイナリ + GotoBLAS2 : 18.56秒
Linux 版バイナリ + GotoBLAS2 : 4.27秒

○計算サーバ
CPU : Intel Corei7 i860 2.8GHz
メモリ : 8GB

効率的な社会インフラシステムを実現する数理最適化技術

発行自体は結構前になるが、昨日以下の冊子を頂いた。ただし、全文を以下のページから入手することができる。東芝における最適化関連の取り組みが数多く紹介されている。最適化の事例を探している方は参考にして頂きたい。社会インフラシステムの世界展開を支える数理最適化技術という記事を最初に見るのがお勧めである。

効率的な社会インフラシステムを実現する数理最適化技術

電力，交通，水道，医療など，社会インフラを支えるシステムの効率的な運用のため，様々な数理最適化の技術が適用されています。東芝は今後も，世界各地の絶え間なく変化するビジネスに適応し，地球環境負荷にも配慮した，統合的な効率化を実現する基盤技術として，数理最適化技術の開発を進めていきます。

空調機のトラブル

２ヶ月近くも悩まされてきた空調機のトラブルの件だが、とりあえず前回の修理で安定して２台とも動作しているようだ。

このクラスタの上にある天吊り型のエアコンがずっと不調だった。室内機ではなく室外機側のトラブルで一定の負荷がかかると自動停止するのが原因だそうだが、詳しいことは良くわからない。


こちらの上にも一台エアコンがあるが、幸い順調に動作している。