2016年 5月 の投稿一覧

この前の出張の際に新幹線の中で小物いれを落としたらしい。

その中に入っていた図書カードから図書館に連絡が行き、図書館から電話が我が家にやってきた。

てっきり届いたのかと思って図書館に赴くと、金沢の警察に連絡してくれとのこと。

なんだ、ただ図書館が連絡の中継ぎをしただけだったのか・・・

それなら直接行かないで電話でも良かったなぁ

まぁ、大したことでもないんでいいんだけど。

そして金沢の警察に電話したら今日は落し物係がお休みだという。

また明日とかに電話するか・・・

大したものは入っていなかったけど、かえってくるならそれに越したことはない。

しかし、どうやって帰ってくるのだろうか。

着払い？

まさか金沢まで取りに来いとか言わないよな・・・

それからまた腹くだした・・・

こんどはココナッツミルク飲料な気がする。

前は大丈夫だった気がするけど・・・まぁ、胃が弱っている時に飲んじゃダメってことだろうか。

あとここのところ、レッツノートのパームレストが熱くてやばいんですけど。

手がやけどしている気がする。

うーん、ノートPCのクーラー買わなきゃダメかね・・・

捨てたものは封筒類。

捨てたというより家族共有の方へ移動。自分使わないし。

体重は64.7kg

うーん、減量全然してないわー

普通に食べたいだけ食べてるからな～

そろそろ量を少し減らすか・・・

昨日夕方から頭痛で日記どころじゃなかったので遅れて日記。

原因は分かっている。

金曜日にストレスマッハでやばかったのでビタミンCを飲んだ時に、いくらなんでも飲み過ぎた。

あかん。

なにごとも限度というものをわきまえなければ。

ビタミンCを摂り過ぎるとお腹がゆるくなり、お腹がゆるくなるとなんか変な筋肉を使うようで首筋とかが激しく疲労する。

そして頭痛。

あ～・・・ひどかった・・・

頭痛寸前の時につくったNBODYっぽい計算をしてGUIに表示するJavaプログラム。

これが遅い遅い。

数にもよるけど画面の更新に数秒かかる。

そこでなかの処理をスレッドにしてマルチコア対応にして、EC2のm4.x4largeで実行。

そしたら十倍ぐらい速くて１６コアの威力を実感した。

いや～いいわこれ。

こういう使い方はちょこちょこしていこうと思う。

捨てたものは缶バッジのサンプル。

体重は64.2kg。

あのねー

なんだよこの仕事

しかも飯も食わずに残業体質だから困るこの会社

くそーーー

ってなわけで、遅いし余裕ないしで一日一新どころじゃありません。

あえていえばこの状況が一日一新。

うれしくない・・・

捨てたものは講義資料。

体重は54.8kg

PCケース用の12cmファンにDCDCコンバータを付けて、USBコネクタとつなげて、USB電源で回る扇風機を作った。

見た目はただのファンですが。

会社が暑すぎて死にそうなので隠れてそれを使おう。

でかすぎて隠れてないけど。

あとはRubyで遊んでいた。

そして今日は暑すぎて腹がおかしく・・・

本当に嫌だこの熱さ。

捨てたものは１００円のケース。

こういう変なケースにものを入れてゴミが増えるから。

体重は64.2kg。

食べてるはずなのにこの体重変化・・・汗かき過ぎだろうか。

大量の計算が必要になった時にEC2のメニーコアインスタンスで爆速で処理しようと画策している今日このごろ。

実際の所やる内容がないかもしれないけど、まぁそれはそれで。

とりあえず、念願のEC2の40コアインスタンスを立ち上げてベンチしてみた。

数十円とはいえ時間課金されるとなんか焦る（汗；

まずはjavaのujmpライブラリでのベンチマーク。

■ujmp　4096×4096の行列同士の掛け算

CF-N10(core i5 2core) 2.3Gflops

m4.x10large(xeon 40core) 40Gflops

コア数が20倍になるに従って性能も約20倍になっている。

順当に性能に上がってていい感じ。

■Intel® Math Kernel Library – LINPACK

CF-N10(core i5 2core)

Size   LDA    Align. Time(s)    GFlops   Residual     Residual(norm) Check
1000   1000   4      0.028      23.9587  1.029343e-12 3.510325e-02   pass
1000   1000   4      0.024      27.5654  1.029343e-12 3.510325e-02   pass
1000   1000   4      0.025      26.7145  1.029343e-12 3.510325e-02   pass
1000   1000   4      0.029      23.2995  1.029343e-12 3.510325e-02   pass
2000   2000   4      0.228      23.4613  4.298950e-12 3.739560e-02   pass
2000   2000   4      0.184      29.0951  4.298950e-12 3.739560e-02   pass
2000   2000   4      0.199      26.7769  4.298950e-12 3.739560e-02   pass
2000   2000   4      0.192      27.8177  4.298950e-12 3.739560e-02   pass
3000   3000   4      0.645      27.9251  8.755385e-12 3.371489e-02   pass
3000   3000   4      0.674      26.7217  8.755385e-12 3.371489e-02   pass
3000   3000   4      0.844      21.3360  8.755385e-12 3.371489e-02   pass
3000   3000   4      0.671      26.8487  8.755385e-12 3.371489e-02   pass
4000   4000   4      1.604      26.6195  1.896949e-11 4.134580e-02   pass
4000   4000   4      1.810      23.5945  1.896949e-11 4.134580e-02   pass
4000   4000   4      1.732      24.6560  1.896949e-11 4.134580e-02   pass
4000   4000   4      1.812      23.5583  1.896949e-11 4.134580e-02   pass
5000   5000   4      3.842      21.7044  2.581643e-11 3.599893e-02   pass
5000   5000   4      4.064      20.5198  2.581643e-11 3.599893e-02   pass
5000   5000   4      3.915      21.2976  2.581643e-11 3.599893e-02   pass
5000   5000   4      4.061      20.5329  2.581643e-11 3.599893e-02   pass
10000  10000  4      33.961     19.6364  9.603002e-11 3.386116e-02   pass
10000  10000  4      35.732     18.6631  9.603002e-11 3.386116e-02   pass

m4.x10large(xeon 40core)

Size   LDA    Align. Time(s)    GFlops   Residual     Residual(norm) Check
1000   1000   4      0.014      47.6095  8.866796e-13 3.023805e-02   pass
1000   1000   4      0.007      97.5988  8.866796e-13 3.023805e-02   pass
1000   1000   4      0.007      97.6123  8.866796e-13 3.023805e-02   pass
1000   1000   4      0.006      110.0105 8.866796e-13 3.023805e-02   pass
2000   2000   4      0.024      219.1916 4.667558e-12 4.060204e-02   pass
2000   2000   4      0.022      239.2903 4.667558e-12 4.060204e-02   pass
5000   5008   4      0.258      323.3306 2.258088e-11 3.148722e-02   pass
5000   5008   4      0.254      328.0522 2.455097e-11 3.423435e-02   pass
10000  10000  4      1.327      502.5286 1.004549e-10 3.542142e-02   pass
10000  10000  4      1.310      508.8807 9.048590e-11 3.190624e-02   pass
15000  15000  4      4.136      544.1181 2.212093e-10 3.484083e-02   pass
15000  15000  4      4.068      553.1527 2.370680e-10 3.733861e-02   pass
18000  18008  4      6.550      593.6765 2.972029e-10 3.254737e-02   pass
18000  18008  4      6.588      590.2303 2.972029e-10 3.254737e-02   pass
20000  20016  4      8.897      599.5097 3.369549e-10 2.982789e-02   pass
20000  20016  4      8.917      598.2119 3.369549e-10 2.982789e-02   pass
22000  22008  4      11.857     598.7819 4.105018e-10 3.006764e-02   pass
22000  22008  4      11.871     598.0661 4.105018e-10 3.006764e-02   pass
25000  25000  4      17.141     607.7839 5.664651e-10 3.221284e-02   pass
25000  25000  4      17.061     610.6244 5.664651e-10 3.221284e-02   pass
26000  26000  4      19.064     614.7131 5.956461e-10 3.132086e-02   pass

こちらも29GFlopsが599GFlopsと約20倍に速度アップ。

順当。

さすがに行列計算だからコアに比例して性能が上がる。

たださ・・・

ujmpで40コアフルに回して40Gflopsで、intel MLKなら2コアでも30Gflopでるのよね。

SSEとかAVXとかの拡張命令使っていないJavaと拡張命令使いまくりのMLKで性能差があるのは当然だけど、

こういうのを見ると「手持ちのノーパソで速いライブラリ使えば話済むんじゃね？」と思えてきてしまう。

まぁ、世の中行列計算みたいに超高速ライブラリがある処理ばかりじゃないけど。

あと、このインスタンスにVNCで接続していると、ベンチ走るとき以外CPUが0%に張り付いていてなんか不気味だった。

40コアもあれば1コア100%でも2.5%にしかならないので、当たり前といえば当たり前なんだけど、普段の感覚で見るとものすごい違和感。

今日捨てたものはマウスパッド

体重は55.2kg

さて、今日は会社が遅くなったのでなんか一日一新するネタがない。

ArrayFireなんて重たいネタは当然出来ないし。

あ～困った。ネタ切れだ。

しかたがないさすがに遅くて無理なので、今日はなし！

捨てたものは大学の時のテストとか。

体重は66.4kg

Javaで数値演算をしていて、なんだかスピードを極めたくなってしまった。

そこでなにを計算をするか決まっていないのに、なんかGPGPUを使いたくなってArrayFireというGPGPUのライブラリを入れてみた。

しかし、MinGWから使おうとしたところエラーが出てだめ。

調べると、ArrayFireはVisual Studioじゃないといけないらしい。

え～まじ～～

しかたがないのでインストールしてサンプルプロジェクトをコンパイル。

そこは素直に通る。

GPGPUなんてものを使おうとしたらもっと詰まると思ったけど、VisualStudioさえ入れれば特に問題はなかった。

しかし問題は実行。

サンプルを実行しても最後に強制終了が起こる。

一応最後まで走っているっぽいけど、なぜか最後が通常終了じゃなくてエラーが出て終了になる。

まぁいいか……とサンプルのbenchmarkを走らせてみる。

■CPU

ArrayFire v3.3.2 (CPU, 64-bit Windows, build f65dd97)
[0] Unknown: Unknown, 12246 MB, Max threads(1)
Benchmark N-by-N matrix multiply
128 x  128:    16 Gflops
256 x  256:    18 Gflops
384 x  384:    24 Gflops
512 x  512:    34 Gflops
640 x  640:    35 Gflops
768 x  768:    35 Gflops
896 x  896:    33 Gflops
1024 x 1024:    36 Gflops
1152 x 1152:    35 Gflops
1280 x 1280:    34 Gflops
1408 x 1408:    34 Gflops
1536 x 1536:    36 Gflops
1664 x 1664:    35 Gflops
1792 x 1792:    34 Gflops
1920 x 1920:    35 Gflops
2048 x 2048:    36 Gflops
### peak 36.4257 GFLOPS

■GPGPU(Radeon HD5770 512MB)

ArrayFire v3.3.2 (OpenCL, 64-bit Windows, build f65dd97)
[0] AMD     : Juniper, 512 MB
-1- AMD     : Intel(R) Celeron(R) CPU G1610 @ 2.60GHz, 12246 MB
Benchmark N-by-N matrix multiply
128 x  128:    40 Gflops
256 x  256:    47 Gflops
384 x  384:    78 Gflops
512 x  512:    23 Gflops
640 x  640:    25 Gflops
768 x  768:    84 Gflops
896 x  896:    25 Gflops
1024 x 1024:    25 Gflops
1152 x 1152:     3 Gflops
1280 x 1280:    26 Gflops
1408 x 1408:    26 Gflops
1536 x 1536:

は！？

実行できたのはいいけど、なにこの遅さ！

たしかに途中で84GflopsとかCPUを上回る性能を出してはいるけど、3Gflopsとかもある。

そして最後はエラーが出て終了。

おそらくメモリが512MBじゃこんな大きな配列を保持できていないんだろう。

そして、その前のパフォーマンスもRAM足りてなくてシステムメモリとシェアしているんじゃないかという疑いが残る。

パフォーマンスもいまいちだし、強制終了とか不安定じゃ実際使いものにならない。

メモリが潤沢な上位GPUを買えば意味があるのだろうけど、HD5770クラスだとGPGPUをやるメリットは薄そうだ。

素直にCPUを使ったほうが良さそう。

捨てたものは単一の電池ボックス。

あると、また意味もなくやすい乾電池買っちゃって用途に困りそうだから。

体重は66.1kg

あれ、戻った。

昔にEC2のLinuxインスタンスは使ったことが合ったんだけど、

Windowsのインスタンスは使ったことがなかった。

microインスタンスだけど東京リージョンにWindowsインスタンスを作って、リモートデスクトップ接続。

感想：意外と速いけど、たまにつまる

東京リージョンなので遅延は最低限なので当たり前といえば当たり前だけど、サクサク動く。

ほんの少しの遅れはあるけど、でもマウス操作に限っては我慢できるレベル。

もっと遅れがひどい感じかと思ったらそうでもなかった。

ただ、ときどきなんかコンマ数秒固まってしまい、それがとっても気になる。

キーボードで打ってみるとやはりスラスラ動く時と体感できる遅延が出る時がある。

感想２：マウス操作ならかなり実用的。キーボード操作はストレスあり。

EC2を計算マシンとして使いたかったけど、この感じだと作ったものを実行するぐらいなら問題ないけど、

コードいじりながら実行するには相当ストレスたまりそうな雰囲気。

コードをいじるならたまにある遅延が致命的だし、

コードをいじらないならもっと遅延があっても困らないので、別リージョンにしたほうがリーズナブル。

うーん、むずかしいところだ。

仮に計算マシンとして使う場合はやっぱりケチな人間としては、海外リージョンのLinuxマシンのスポットインスタンスになってしまう気がする・・・

P.S.

スポットインスタンスが安いバージニアにmicroでLinuxなインスタンス立ててみた。

そしたらCUIなのに遅延が酷い。

よく考えればさっき「キーボードだと遅延が気になる」って言ってたんだから、CUIこそ遅延が気になるじゃないか（汗；

やっぱり東京リージョンで立てよう。

最初からケチらずに東京でやればよかった。

まぁ、やってみて分かることってあるよね・・・

捨てたものはメモ類。

体重は65.4kg

javaの数値演算ライブラリのujmpは高機能そうだけど、それゆえ遅いんじゃないか。

そう思って自分で書いた行列掛け算と比較してみたら……

正確な数値は記録しなかったけど数十倍違う。

ファ！？

なんで！？

だってJavaだよ！

アセンブラとかで最適化出来ないんだよ！

なんで！？

と調べてみると、どうやらメモリアクセスが連続になるようにデータを詰めてから計算している模様。

要は行列の掛け算って、左の行列の行方向と右の行列の列方向をなめて足し算していくわけだけど、

普通にやるとどちらか片方の行列へのアクセスが飛び飛びの番地になる。

飛び飛びになる部分を先に別の配列に詰めておいてからそこから読んでいる。

自分も真似てみるとたしかに１０倍早くなった。

うを……メモリアクセスの考慮がこんなにきくとは。

しかしそれでも数倍違う。

どうもujmpはマルチスレッドでCPUのパイプラインに命令を詰め込んでいるので効率がいいっぽい。

すげ～。

高機能すぎて遅いんじゃないかという懸念は完全に払拭された。

アセンブラでもないのにJavaでコーディング次第でこんなにパフォーマンスを改善できるとは驚き。

すごいもんだ～

それからergoproxyを一気に全部見てしまった。

うう、やりすぎ。

でも見始めると止まらないんだよな。

今日捨てたものはメモ。

体重64.9kg。

あれ、なぜか減った。