コグノスケ

自分のマシンは何 GFLOPS か？ その 3

その 1、 その 2、 その 3

LINPACK を単独のマシンで実行してもあまり面白くないので、クラスタで実行したいと思います。役割としてはマスタが 1台、スレーブが他全部という分担になります。LINPACK の場合、マスタからスレーブに ssh でログインして、ログイン後 xhpl を実行するようです。

スレーブ側の設定

スレーブ側は LINPACK をコンパイルして、xhpl をマスタと同じパスに配置すれば OK です（HPL.dat は要らない）。マスタ側のバイナリが /home/username/a/b/c/xhpl に置かれているとしたら、スレーブ側も同じ /home/username/a/b/c/xhpl ディレクトリに置かなければ起動できないようです。

一番簡単なのはマスタ、スレーブ、全てのノードに同じユーザを作成して、MPI 実行用のバイナリを入れるディレクトリを作成することですね。

さらにスレーブは ssh の公開鍵認証にしておくと、LINPACK 起動時にパスワードを打たなくて良いので楽です。マスタからスレーブにログインできれば OK で、スレーブからマスタにログインする設定は不要です。

マスタ側の設定

マスタ側は LINPACK をコンパイルするのは当然として、少しだけ特別な設定が必要です。私は hostfile の存在に気づくまでにかなり時間がかかりました…。

• HPL.dat: 単独で実行していたときにも使っていた LINPACK パラメータを書いたファイル
• hostfile: クラスタのノード一覧を書いたファイル

HPL.dat は単独動作と同じで良いです。性能は後で考えるとして、とりあえず動作するはずです。

クラスタのノード一覧 hostfile は単独のときには使っていませんでした。基本的にはクラスタを構成するノードのホスト名（IP アドレスでも良いです）を並べるだけです。

localhost slots=4
192.168.1.109 slots=4

上記は 2台構成（Rock64 が localhost、Raspberry Pi 3 が 192.168.1.109）の記述です。slots= にはそのノードがいくつのプロセスを扱えるかを記述します。どちらも 4コア 4スレッドの CPU なので slots=4 としています。まあ 2 とか 8 とかにしても動きますが、効率は下がります。

クラスタ起動

実行は下記のようにします。Rock64 がマスタ、Raspberry Pi 3 がスレーブです。下記のコマンドはマスタ側で実行してください。

$ cd bin/Linux_ATHLON_CBLAS
$ ls
HPL.dat  hostfile  xhpl

$ mpirun -n 8 -hostfile hostfile -host localhost,192.168.1.109 xhpl
...
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00L2L2        2000    64     1     4               3.74              1.429e+00
HPL_pdgesv() start time Wed Aug 15 00:11:49 2018

HPL_pdgesv() end time   Wed Aug 15 00:11:53 2018

--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0037309 ...... PASSED
...

MPI の凄いところは Rock64（arm64）と RasPi（arm）のようにアーキテクチャが違うクラスタでも実行できてしまうところです。メッセージパッシングの隠れた利点かもしれません。

動作しているかどうか確認するには Raspberry Pi 3 側で top などで見るのが確実だと思います。LINPACK 実行中に xhpl が 4プロセス実行されているはずです（全力で実行した場合）。

ちなみに hostfile を指定し忘れるとこんなエラーになります。8プロセス起動しろと言われても、どのノードがプロセスをいくつ受け持ってくれるかわからないので、怒っている訳ですね。

$ mpirun -n 8 -host localhost,192.168.1.109 xhpl
--------------------------------------------------------------------------
There are not enough slots available in the system to satisfy the 8 slots
that were requested by the application:
  xhpl

Either request fewer slots for your application, or make more slots available
for use.
--------------------------------------------------------------------------

それと OpenMPI のバージョンには注意してください。我が家のデスクトップ PC（Debian Testing, OpenMPI 3.1.1）とファイルサーバ（Debian Stable, OpenMPI 2.0.2）で x86_64 クラスタを構成しようとしたところ、OpenMPI のバージョン違いでこんなエラーになって実行できませんでした。

$ mpirun -n 4 -hostfile hostfile -host localhost,falcon xhpl
[blackbird:29131] tcp_peer_recv_connect_ack: invalid header type: 0 ★★★★こんなエラーで怒られる★★★★
--------------------------------------------------------------------------
ORTE was unable to reliably start one or more daemons.
This usually is caused by:

* not finding the required libraries and/or binaries on
  one or more nodes. Please check your PATH and LD_LIBRARY_PATH
  settings, or configure OMPI with --enable-orterun-prefix-by-default

* lack of authority to execute on one or more specified nodes.
  Please verify your allocation and authorities.

* the inability to write startup files into /tmp (--tmpdir/orte_tmpdir_base).
  Please check with your sys admin to determine the correct location to use.

*  compilation of the orted with dynamic libraries when static are required
  (e.g., on Cray). Please check your configure cmd line and consider using
  one of the contrib/platform definitions for your system type.

* an inability to create a connection back to mpirun due to a
  lack of common network interfaces and/or no route found between
  them. Please check network connectivity (including firewalls
  and network routing requirements).
--------------------------------------------------------------------------

エラーメッセージはたくさん出ますが、解決に辿り着かないので何とも言えない気分です…。

肝心の性能は

結論から言ってしまえば Rock64 と Raspberry Pi 3 のクラスタは意味がなさそうです。なぜなら Rock64 1台のほうが速いからです…。

まずは単独実行と同じ問題サイズ N=2000 での実行結果です。多少上下しますが 0.6〜0.7GFlops くらいです。Rock64 単独（1.4GFlops）の半分以下です。P, Q の値は 2, 4 が一番良さそうでした。他の値（1, 8 や 4, 2）にすると激遅で実行が終わりません。

$ mpirun -n 8 -hostfile hostfile -host localhost,192.168.1.109 xhpl
...
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00R2L4        2000    64     2     4               7.97              6.699e-01
HPL_pdgesv() start time Wed Aug 15 00:41:15 2018

HPL_pdgesv() end time   Wed Aug 15 00:41:22 2018

--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0037423 ...... PASSED
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00R2C2        2000    64     2     4               7.94              6.724e-01
HPL_pdgesv() start time Wed Aug 15 00:41:23 2018

HPL_pdgesv() end time   Wed Aug 15 00:41:31 2018
...

問題サイズが小さすぎたかな？と思い N=4000 にしてみました。0.9〜1.3GFlops とだいぶ性能が上がります。単独実行の場合 N=2000 と N=4000 ではほぼ性能に変化はありません。

$ mpirun -n 8 -hostfile hostfile -host localhost,192.168.1.109 xhpl
...
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00L2L2        4000    64     2     4              32.17              1.327e+00
HPL_pdgesv() start time Wed Aug 15 00:50:32 2018

HPL_pdgesv() end time   Wed Aug 15 00:51:04 2018

--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0018773 ...... PASSED
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00L2L4        4000    64     2     4              40.92              1.043e+00
HPL_pdgesv() start time Wed Aug 15 00:51:04 2018

HPL_pdgesv() end time   Wed Aug 15 00:51:45 2018
...

性能が違うノードを組み合わせているからなのか、放熱が足りなくてオーバーヒートしているのか、性能がかなり不安定です。たまに System 負荷が 50％台に張り付いて、実行が終わらなくなるときもあります。うーん、たった 2台でも難しいものだな。

自分のマシンは何 GFLOPS か？ その 2

その 1、 その 2、 その 3

LINPACK のビルドができたので、さっそく実行してみます。バイナリは bin ディレクトリの下にあります。

実行の仕方は mpirun -n 4 xhpl のようにします。パラメータファイル（HPL.dat）が置いてあるディレクトリで実行してください。

AMD A10-7800 での実行結果

これが最速パラメータかどうか自信がありませんが、とりあえず 10GFlops だそうです。

しかし hdk 氏の AMD A10-7870K は 19GFlops 出ているそうです。両者ともに Bulldozer 系の APU なのに、倍も差がつく理由がさっぱりわかりません。謎です…。

AMD A10-7800 の性能（追記）

何気なく cblas と atlas のスタティックリンクをやめて、ダイナミックリンクに変更したところ、いきなり性能が上がり 1.7倍の 17GFlops になりました。

AMD A10-7800 での実行結果（ダイナミックリンク版）

えー？なぜ！？とりあえず perf top で見てみると libatlas.so の関数が 8割ほどの実行時間を占めています。ここが効率的になったんでしょうか？そんなに変わるものですかね、さっぱり意味がわかりません…。

ARM も見てみる

Rock64 でも実行してみました。SoC は Rockchip RK3328、CPU は Cortex-A53 x 4 です。

Rock64 での実行結果

大体 1.5GFlops でした。A10-7800 と比べるとやはり 1桁違いますね（PC が 6.7倍速い）（ダイナミックリンク版だと 11倍速い）。

コンパイル実験（2018年 8月 12日の日記参照）のときは PC が 18倍ほど速かったので、コンパイル実験よりは差が縮まっている、とも取れます。

電力効率の点から見ると、PC 1台より Rock64 を 10台並べた方が省エネなのでしょうか？微妙かな…？今度、ワットチェッカーで比べてみましょうか。

自分のマシンは何 GFLOPS か？ その 1

その 1、 その 2、 その 3

自分のマシンは何 GFLOPS か知りたくなって、スパコン界隈で有名な LINPACK を実行してみようと思い立ちました。ソースコードは HPL- A Portable Implementation of the High-Performance Linpack Benchmark for Distributed-Memory Computers にあります。私は hpl-2.2.tar.gz を使用しました。

ビルド方法は INSTALL ファイルに書いてある通りですが、結構ハマったので、私の手順もメモしておきます。環境は Debian GNU/Linux Testing の amd64 版です。

LINPACK の Makefile

コードを展開し、setup ディレクトリの下にある Make.xxx をトップディレクトリにコピーして使います。たくさんファイルがありますが、Athlon マシンなので Linux_ATHLON_CBLAS を選びました。FBLAS という名前のファイルもありますが、

• CBLAS: C 版
• FBLAS: Fortran 版

のようです。用語の意味はわかりませんが、Makefile の diff を見れば何となくわかるはず、きっと。

ビルドの準備

コピーしてきた Make.Linux_ATHLON_CBLAS は書き換える必要があります。特に大事なのは TOPdir です。

この変更を忘れるとホームディレクトリ直下の hpl というディレクトリがトップディレクトリだと思って、ビルドを始めます。最終的に「Make.inc が見つからない」と言われて失敗します。

Make.inc を find で探すとわかりますが Make.inc はシンボリックリンクです。ビルドに失敗するときは Make.inc が全然関係ない場所を指していると思います。

もし TOPdir を書き換え忘れてビルドが失敗した場合は make arch=Linux_ATHLON_CBLAS clean_arch としてください。アーキテクチャ名の付いたディレクトリ（Make.inc もそのディレクトリに入っている）が全て消滅するはずです。

# TOPdir をソースコードを配置した位置に合わせて修正します
TOPdir = ...

# コンパイラを gcc から mpicc にします
CC = /usr/bin/mpicc
# リンカも gcc から mpicc にします
LINKER = /usr/bin/mpicc

# OpenMPI のライブラリ位置
MPdir = /usr/lib/x86_64-linux-gnu
MPinc = -I$(MPdir)/openmpi/include

# ビルドしたバイナリが動かなくなるため、MPlib は削除
#MPlib = ...

# LAlib のライブラリ位置
LAdir = /usr/lib/x86_64-linux-gnu
# スタティックリンクだとなぜか遅いので、ダイナミックリンクに変更
LAlib = -lcblas -latlas

# 末尾に -lrt -lbacktrace を追加します。
# HPL_LIBS の先頭に追加するとリンクエラーになります。
HPL_LIBS = ... -lrt -lbacktrace

あと、私の環境の場合、下記パッケージのインストールが必要でした。

• libopenmpi-dev
• libmpich-dev
• libatlas-base-dev

実行はまた今度にします。

ARM PC で開発できるか？

最近の ARM 搭載 SoC はかなり速くなっています。もしかして x86 PC の代わりに使えるのではないでしょうか？開発に使うことを想定して、コンパイル速度を比較してみたいと思います。

比較に使うのは Linux Kernel の開発ツリー（linux-next）です。コンフィグはデフォルトを使い、ビルドターゲットは all を指定します。ビルドしているアーキテクチャが違う（Rock64: arm64, AMD A10: x86）ので、時間の単純比較はできませんが、参考にはなると思います。

AMD A10 7800、32GB DDR3-1600 の PC で linux-next x86 の time make -j4 all を実行しますと、

• real 10m33.584s
• user 33m37.811s
• sys 4m7.908s

不遇の Bulldozer 系コア、もはや 4年落ちとなった CPU で、大して速くはありませんが、十分実用的というか、待っていられるレベルです。

Intel Pentium J4205、16GB DDR3L-1600 の PC で linux-next x86 の time make -j4 all を実行すると、

• real 14m45.968s
• user 51m57.967s
• sys 5m47.331s

Pentium J は Atom 系列で遅いと思いきや、予想より何倍も速かったです…。ナメてました、ごめんなさい。

Rock64、Rockchip RK3328、Cortex A53 x 4、4GB DDR3 で linux-next arm64 の time make -j4 all すると、

• real 179m33.126s
• user 266m0.254s
• sys 22m52.046s

PC と比較するとほぼ 1桁遅いです。さすがにこれは待っていられません。Rock64 は普段使いには十分速いですが、開発に使うのは辛そうですね…。

Raspberry Pi 3、Broadcom BCM2837、Cortex A53 x 4、1GB LPDDR2 で linux-next arm の time make -j4 all すると、

• real 146m46.807s
• user 236m43.970s
• sys 10m41.310s

ビルドしているアーキテクチャが違う（Rock64 は arm64、RasPi 3 は arm）ので、単純比較はできませんけど、Rock64 と大差ないですね。

もっと速い ARM SoC は？

今のところスマホ、TV/STB 系 ARM SoC は A72 x 4、A53 x 4 が最強クラスのようです。サーバー系 ARM SoC に目を向ければ A72 x 16（NXP LX2160A）もしくは A53 x 24 や A53 x 48（Cavium ThunderX）といった桁違いメニーコアがありますが、そんなに要らないんですよね…。

中間の製品はありません。買う人いないんでしょうね。

ARM SoC 搭載ボード

今後のお買い物の参考に、ざざっと調べてみました。

Tegra 系

ボード Jetson TX2、Denver x 2、A57 x 4、8GB LPDDR4、$600 日本だと販売店のぼったくりで 10万円。

HiSilicon Kirin 960

ボード HiKey 960、A72 x 4、A53 x 4、3GB LPDDR4、$239 良いんだけど、メモリがもう一声欲しかった…。

Rockchip RK3399

ボード NanoPC-T4、A72 x 2、A53 x 4、4GB LPDDR3-1866、$109 DDR3 ではあるけど、良さそう。

Samsung S5P6818

ボード NanoPC-T3 Plus、A53 x 8、2GB DDR3、$75 可もなく不可もなく？

Amlogic S912

ボードが見当たらない、A53 x 8、どこか発売してくれないかな。

Amlogic S905

ボード ODROID C2、A53 x 4、2GB DDR3、$39 S912 の一世代前ですね。

AllWinner H6

ボード PINE H64、A53 x 4、2GB LPDDR3-1600、$36 安くて素敵だけど、さすがに見劣りしてしまうなあ。

性能だけ求めるなら Jetson か HiKey 960 で、コスパなら NanoPC-T4 ですかね。Jetson なら流行りの AI とか、GPGPU も実験できますね。お値段はべらぼうですけど…。

地震保険

AIG 損害保険から「大阪北部地震で被害を受けた方はご連絡ください」という手紙が来て、地震保険に加入していたことを知りました。ずっと火災保険だと思ってたよ……。

人生初の地震保険です。

保険会社に被害を申請（電話、Web でも可能）すると、調査員さんが家に来てくれます。調査員の方は、かなり積極的に被害としてカウントしてくれます。むしろ、こちらが「いやー、そこは特に被害無かったですね…」と断るような形になるくらいでした。

家財の場合、壊れなくても、地震で倒れたりズレたら被害としてカウントされるそうです。あと、地震保険で特徴的なのは、被害を受けた「種類」が大事なことです。本が 1冊でも 100冊でも、カウントは「本」の 1種類のみですが、棚とテレビと冷蔵庫が地震でズレたり倒れたりすれば 3種類としてカウントされ、被害が大きいとみなされるようです。

地震保険の査定額

地震保険は火災保険と違い損害額ではなく、保険金額（契約時に決めている額面）の何割という形で支払われます（地震保険 | 個人のお客さま | AIG 損保へのリンク）。

我が家の場合、家財の「一部損」判定でした。この場合、地震保険金額の 5%が支払われることになります。契約していた保険金額は 100万円くらいだった（それも知らなかった…）ので、支払われる額は大体 5万円です。

大阪北部在住で、地震保険に加入している人は、とりあえず被害申請をしてみるといいですね。判定結果が一部損（一番低い）でも、地震でグチャグチャにされた部屋の片づけ手間賃くらいにはなると思います。

査定方法

査定は結構面白いです。馬のフィギュアがテーブルから落ちてたら「被害です」、お皿が落ちたり転げたら割れてなくても「被害です」。逆に言うと、壊れた物の金額は勘案しないので、被害の受け方によっては被害額と保険の査定額が全く合いません。

しかし元々そういう保険なんです。火災保険や自動車保険とは仕組みが違うのですね。

保険会社がんばってる

AIG 損害保険の調査員の方曰く、大阪北部地震と 7月豪雨の被害調査を迅速に行うため、全国の調査員が応援に駆けつけているのだとか。今日来ていただいた方も北海道から応援に来ていると言っていました。

最近は特に暑いし、特に豪雨の地域では道路がやられていて、被災地を駆け回るにもとても大変らしいです。頭が下がる思いです。

エディタ

誰しもお気に入りのエディタがあると思いますが、私は割とメチャクチャです。

C 言語系は読むときは Vim + GNU Global、書くときはサクラエディタを使うことが多いです。

Vim はタグジャンプやヒストリが優秀で、検索もしやすいので、コードを読む際にはとても便利だと思います。ログを差し込んだり、コードを多少書き換える程度であれば Vim で済ませます。

しかし 1から全て書くような場合は、サクラエディタが多いです。何ででしょうね？関数表示が便利なのかな？そんなサクラエディタも C++ を書くときはイマイチで、ラムダがまともに表示されず不便です。

GVim で tab と :Tlist を使うとサクラエディタの関数表示に近くて、個人的には良い感じですが、常用には至っていません。何が悪いのかわからない…。

Java は読むことはあまり無いけど Vim ですかね、書くときは IntelliJ IDEA です。スクリプト系は Vim で読むし、書きます。

こうして並べてみると、かなり支離滅裂です。どうしてこうなった…？？

Vim と Emacs の思い出

Vim も Emacs も初めて使ったとき「は？何だこれ……？？」と思いました。どちらも終了方法がわからず、まともに使えませんでした。今は IDE も Vim も適度に使っています。

でも Emacs は完全に使い方を忘れてしまった。ごめんね Emacs…。