gnuplotでeps

gnuplot> set terminal postscript eps
gnuplot> set output 'random.eps'
gnuplot> plot "random.mtx" using 1:2

これでOK。
しかし、Windows環境ならMetafile to EPS Converter使ったほうが楽で綺麗なときも。

今後の作業メモ

・StreamAPU 改善
解析的な手法を導入
　どのようなパラメータなら提案手法が用いることができるのか解析する
　並列数数、それぞれのコアの速度、性能、通信回数など
英語化

・ドキュメント化
サーバ管理関係（リストアップする）
　U君と連携して考えておく
StreamAPUのプログラムなどのSVNへの追加、使い方のPP化

修士論文

無事修士論文とSACSISを提出することができた。
自分なりにちゃんと取り組んだつもりだったが、
結果的に時間が足りずに適当になってしまった部分も多く、
スケジューリングが今後の課題だと思う。
特に修士論文やSACSISのはじめのほうの稿は文章を推敲する余裕がなく、
かなり酷い状態で添削していただかなくてはならなかったのが反省点だ。
せめてあと一週間でも早く全ての実験・実装が終わり、推敲時間を取れたなら、
最終日の昼レベルの原稿なら自力で持っていけたと思う。

研究の今後の課題として、VWAPのもう少しマシな実装とSSTに代わるアプリの調査がある。
今回のVWAPはCPUに絶対負けないために全てTRADEのときを想定したが、
QUOTEも混ざった場合にどのような挙動になるのかは一度試してみたい。

また、SSTはどうしても提案手法の優位性の検証には使えそうもないので、
新しくCPUとGPUが混在した処理を探して高速化してみたい。
昔痛い目に合ったXMLなんかが案外いけるかもしれないと考えている。
前回は全てGPUでやる前提だったのでダメだったが、
理想的なAPUを想定して適宜2つのデバイス間で適切に処理を割り振れば何とかなるかもしれない。

gnuplot

たびたび書いているような気がするが、gnuplotの使い方。


gnuplot> set term png nocrop medium size 450,160
Terminal type set to 'png'
Options are 'nocrop medium size 450,160 '
gnuplot> set output 'wiki.png'
gnuplot> plot "wiki-sort.mtx" using 1:2

これでファイルの1,2番目の要素をx,yとして指定したサイズのグラフをpngで吐ける。

VWAPの実験

修論の実験でVWAPの再試が必要だったのだが、、Teslaで書き直したものと、
OpenMPでCPUに最適化したもののテストが終わり、ただいま本実験のデータを取っている。

OpenMPは非常に簡単にマルチスレッドプログラムが書けるので使うのは楽だったっが、
TSUBAMEでのスレッド数の初期設定が1になっているのに気づかず、ちょっと時間を浪費した。
それ以外はすんなり動き、4スレッドくらいまではリニアスケールしたのを確認したのでひと安心。
ハイパースレッディングはあまり意味がないようで、12スレッドの結果が24スレッドに勝つ場合も。

行列生成スクリプト

行列生成スクリプトだが、Perlのものは遅すぎるため結局C++で書きなおした。
STLのstringでは文字列の分割がサポートされていないようなので、
ファイルの読み込みはCのfgetsでcharの配列に読んでstrtokしてからSTLのqueueで保持し、
書き込みはofstreamで行うという何ともちぐはぐで変な実装になってしまった。

Perlでは27+47行のスクリプトが、C+では39+101行のコードになり、倍ほどの差がある。
全く同じ処理のフローなのだが、いかにPerlでは略記が可能かがよくわかる。
その分処理は遅いので致し方ないが。

グラフサイズの概算

疎行列をCSRで持つとすると、AAとJCが非ゼロ要素数nz個分、
IAとV1,V2が行列の一辺の長さn個分の格納領域が必要となる。
単精度の場合、全ての配列は長さ*4Byteになるので、8nz+12n Byteになる。

nとnzはエッジファクタefを用いるとnz=n*efとなる。
だいたいefは16程度で生成するらしいので、これを適用すると140n Byte！！
倍精度だと、AAとV1,V2が2倍に増えるので、12nz+20n Byte = 212n Byteだ。


今回ターゲットとするメモリ必要量は、3～6GBには収まらず128～256GBよりは小さい領域。
よって、nは2^26～2^30程度の領域を相手にすればよいようだ。メモリ量は8.75GBから140GB程度。

n=2^26(scale s=26)だと、ベクトル1本が256MBで、どうにか扱えそうな感じだ。
n=2^30(scale s=30)だと4GBになるので、現状のFermiでも扱うのは不可能になる。
s=26のときAAとJCはそれぞれ16*2^26で、4GBになる。s=30では64GB。
s=26だとFermiのC2070なら全てメモリに乗ってしまうのであまり面白くなさそう。
ただし、現状のハードと実装ではBlock=2^15, Thread=2^10で合計2^25がベクトル長の最大になる。
ベクトルの分割を実装するのはちょっと面倒だが、s=25では行列分割の必要性がなく何かぱっとしない。

Pregelなどの評価ではef=128くらいらしいので、この場合も考えておく。
これを適用すると、メモリ量は8nz+12n = 1036n Byteで、scaleは23～28で、メモリ量は8.09GB～259GB。
ベクトルの容量はscaleでのみ決まるのでs=23なら8MB、s=26は変わらず256MB、s=28で1GB。
AAやJCはefの影響も受け、s=23で1GB、s=26で8GB、s=28だと32GBになる。
これくらい大きいと行列の分割の必要性、正当性も大いに主張できるし、ちょうどいいとは思う。