そのうちやります。
・親スレッドも含めて、OMP_NUM_THREADS と同じ数にする。
現在の実装では、親スレッドはスレッドを起動して終了するまで、待ちになっている。
・スレッド毎にメモリを確保する。
ソケット直下のメモリに作業領域を作成したい。
・親スレッドも含めて、OMP_NUM_THREADS と同じ数にする。
現在の実装では、親スレッドはスレッドを起動して終了するまで、待ちになっている。
・スレッド毎にメモリを確保する。
ソケット直下のメモリに作業領域を作成したい。
PHP から直にソルバを呼ぶスタイルから、スクリプト言語をかませる方向をシフト中。そうすれば、ソルバを更新する際にも、PHP を触る必要が少なくなる。やはり更新するファイルと、固定するファイルは分けておいたほうが保守しやすそうだ。
アルバイトでお世話になった塾の社員同士が結婚するということで２次会に出席。お二人ともとても素敵でした。おめでとうございます。ビンゴ大会では、馴染みのメンバー内で Wii などの商品が当り、大変驚いた。
前回の記事で性能に関係する部分はいじっていないのだが、若干性能が向上している。ファイル間の依存関係が弱まったことで、最適化がかかりやすくなったのかも知れないし、もっと別のことかもしれない。見やすくなって性能が上がったのはうれしい限りである。
それから、2-heap の優先キューで使用する領域を動的に広げるバージョン（以後、2-heap* とする）では、マルチスレッドでスレッド数を増やしていくと”静的に確保するもの”と比べ性能が向上する。メモリ要求量が抑えられることが効いているのだろう。
それから、2-heap の優先キューで使用する領域を動的に広げるバージョン（以後、2-heap* とする）では、マルチスレッドでスレッド数を増やしていくと”静的に確保するもの”と比べ性能が向上する。メモリ要求量が抑えられることが効いているのだろう。
最短路ソルバを更新した。特に性能に影響をする部分はいじらずに、各ファイルの依存関係をできるだけ排除するようにした。
・バイナリを統合
優先キューの種類毎（2-heap と Buckets）にバイナリを用意していたものを１つに統合。環境変数にて選べるようにした。
・2-heap は、優先キューに利用する領域を、動的に増やすものを追加。
サンプルプログラムだけ実装して、元のソルバーには組み込んでなかった。ほとんど無駄になってしまう領域を動的に広げることで、メモリ消費量を抑えることができる。マルチスレッドで効果あり。
・メモリ確保ルーチンを大幅改良
これだけでもライブラリとして使用できるように切り出し、それをリンクする形をとっている。
・バイナリを統合
優先キューの種類毎（2-heap と Buckets）にバイナリを用意していたものを１つに統合。環境変数にて選べるようにした。
・2-heap は、優先キューに利用する領域を、動的に増やすものを追加。
サンプルプログラムだけ実装して、元のソルバーには組み込んでなかった。ほとんど無駄になってしまう領域を動的に広げることで、メモリ消費量を抑えることができる。マルチスレッドで効果あり。
・メモリ確保ルーチンを大幅改良
これだけでもライブラリとして使用できるように切り出し、それをリンクする形をとっている。
前回に引き続き。今度は細かいものを中心に。
・座標を素の緯度経度に
これにより _GET[] で渡す変数が減るので、多少すっきりするだろう。
・NY や BAY などでも、入力に Google Maps をする版も
DIMACS グラフは直線でエリアを分けているので、可能。
・ユーザがグラフをアップロードできるように。
小さなグラフなら、アップロードできるようにしたい。
イメージ的には SDPA Online Solver なので、別物になるだろう。
・座標を素の緯度経度に
これにより _GET[] で渡す変数が減るので、多少すっきりするだろう。
・NY や BAY などでも、入力に Google Maps をする版も
DIMACS グラフは直線でエリアを分けているので、可能。
・ユーザがグラフをアップロードできるように。
小さなグラフなら、アップロードできるようにしたい。
イメージ的には SDPA Online Solver なので、別物になるだろう。
ほとんど TODO。まずは全体に関する目標。
・使用するデータファイルは一ヶ所にまとめる。
現在の仕様では種類毎に分けてしまっているので、改善。他のサーバで動かす際にも便利。
・グラフデータを記述するファイルを１つに統合
新たにデータが手に入った時にも、素早く対応できる。小さなファイルでも upload させて実行するような需要を見込んでいる。
・設定は Makefile で自動化
面倒な操作は全て自動化へ。可能であれば Map の追加も。将来 Online Solver 自体を配ることもできる。
・インターフェイスの統一
大きく分けて {Graphic, GoogleMaps}-{Graphic, GoogleMaps} の４パターンがあるが、これらを統合したい。内部的に必要な変更は、クエリを全てファイルで渡すことと、出力はパスファイル(GoogleMaps用)と EPS ファイル(Graphic用)の両方とするくらいか。
・使用するデータファイルは一ヶ所にまとめる。
現在の仕様では種類毎に分けてしまっているので、改善。他のサーバで動かす際にも便利。
・グラフデータを記述するファイルを１つに統合
新たにデータが手に入った時にも、素早く対応できる。小さなファイルでも upload させて実行するような需要を見込んでいる。
・設定は Makefile で自動化
面倒な操作は全て自動化へ。可能であれば Map の追加も。将来 Online Solver 自体を配ることもできる。
・インターフェイスの統一
大きく分けて {Graphic, GoogleMaps}-{Graphic, GoogleMaps} の４パターンがあるが、これらを統合したい。内部的に必要な変更は、クエリを全てファイルで渡すことと、出力はパスファイル(GoogleMaps用)と EPS ファイル(Graphic用)の両方とするくらいか。
まずは Istanbul から。２コアでは同一ソケットの方が性能が良い。numactl で指定しないと "1core + 1core" で実行されてしまうが指定した方が良いようである。
Nehalem の結果の方が納得がいく。２コア、４コアともに、うまく割り振った方が性能が良い。しかしながら、ほとんど性能は劣化せず。
◆表の読み方
"仕様コアID" "256クエリの実行時間 "クエリあたりの実行時間" "コアの割り振り"
* … 理想的と思われる割り振り
Istanbul [sec.]
total ave.
* 0,1 539.38 2.107 (1core + 1core )
0,2 522.73 2.042 (2core + 0core )
* 0,1,2,3 282.43 1.103 (2cores + 2cores)
0,2,4,6 278.10 1.086 (4cores + 0core )
* 0,1,2,3,4,5 200.04 0.781 (3cores + 3cores)
0,2,4,6,8,10 200.84 0.785 (6cores + 0core )Nehalem の結果の方が納得がいく。２コア、４コアともに、うまく割り振った方が性能が良い。しかしながら、ほとんど性能は劣化せず。
Nehalem-EP [sec.]
total ave.
* 0,1 349.42 1.365 (1core + 1core )
0,2 343.25 1.341 (0core + 2cores)
* 0,1,2,3 185.47 0.725 (2cores + 2cores)
1,3,5,7 189.04 0.738 (4core + 0core )◆表の読み方
"仕様コアID" "256クエリの実行時間 "クエリあたりの実行時間" "コアの割り振り"
* … 理想的と思われる割り振り
当研究室最速マシンはどちらかということで、ベンチマークしてみました。Istanbul での HugeTLBfs による改善率は大変大きいが、NehalemEP の方に軍配が上がる結果となった。Linpack では逆の結果になったようで、気になるところである。
Graph Data: USA-road-d.USA.gr (23,947,347 nodes 58,333,344 arcs)
Graph Data: USA-road-d.USA.gr (23,947,347 nodes 58,333,344 arcs)
◆ Execution Time [sec./query]
1 2 4 6 8 10 12
NehalemEP 2.58 1.36 0.72 - 0.42 - -
NehalemEP(Huge) 2.33 1.23 0.65 - 0.37 - -
Istanbul* 3.99 2.15 1.16 0.86 0.71 0.65 0.62
Istanbul*(Huge) 2.86 1.52 0.81 0.58 0.48 0.42 0.39
某インターネットラジオのジングル（CMソングのような短い曲）の依頼をいただいた。パソコンの外部端子に外付けマイクというしょうもない機材(?)で録音した。放送される予定である。
３カラムはちょっと狭いのでこれを期に変えてみた。これだと CSS を変更できないのが難点ではあるがそのうち慣れるだろう。
Beagle Board を使用する機会を頂いたので、最短路ソルバーを実験した結果である。メモリが 256 MB しか搭載されていないので、各優先キューで動くもので実行を行った。思ったよりも Xeon に似たような特性を示している。
[ OMAP3 Beagle Board ]
Processor : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 470.56
[ OMAP3 Beagle Board ]
Processor : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 470.56
[Graph Data]
#nodes #arcs
NY 264,346 733,846
CAL 1,890,815 4,657,742
E 3,598,623 8,778,114[Execution Time [msec/query]]
NY CAL E
2-heap@beagle 247 3108 5844
buckets@beagle 160 2034 3498
MLB@beagle 251 3179 -
2-heap@xeon 16 185 323
buckets@xeon 12 135 227
MLB@xeon 15 187 316
リリースされたそうだ。共通のバイナリで複数のマシン上で実行できるそうで、マシンごとにメイクする必要がなくなったのは非常に便利だろう。
個人的に大変興味のあるメモリ確保ルーチンを眺めていると、小さなベンチマークを行い性能の良い領域を確保するような機能が追加されている。また、CPU コアの割付関係のルーチンもある。
勉強にさせてもらいます。
個人的に大変興味のあるメモリ確保ルーチンを眺めていると、小さなベンチマークを行い性能の良い領域を確保するような機能が追加されている。また、CPU コアの割付関係のルーチンもある。
勉強にさせてもらいます。
CPU : AMD Opteron 2435（2.6GHz / 6MB L3）x 2
Memory : 64GB（16 x 4GB / 800MHz）
HDD : 300GB（10,000RPM, SAS, 2.5inch）x 2 (RAID 1)
12 コアでも台数効果は出ているが、8 コアの Nehalem-EP や Harpertown の方が有効なようである。
Memory : 64GB（16 x 4GB / 800MHz）
HDD : 300GB（10,000RPM, SAS, 2.5inch）x 2 (RAID 1)
12 コアでも台数効果は出ているが、8 コアの Nehalem-EP や Harpertown の方が有効なようである。