先日(2018年7月17日の日記参照)エアコンを16℃設定1時間で浄化運転し、見事に嫌な臭いが消え去りました。しかし最近エアコンが雑巾臭くなってしまいました。
今年の夏はかなりヘビーに使っているとはいえ、浄化した効果が1か月しか持たないとなると、浄化が必要な頻度はかなり高そうです。
次の休みにでも、また浄化してみるかなあ。電気代がどうこうより、16℃運転の負荷で室外機が壊れそうで、心配ですけどね。
エアコンが臭くなった状態で、設定温度を26℃に下げるとエアコンの嫌な臭いは一時的に消えます。
しかし28℃設定に上げると、かなり嫌な臭いがします。27℃設定だと日によって違います。おそらくその日の気温依存だと思われます。
また、我が家のエアコンは、運転停止すると自動的に送風運転が始まります。送風運転はほぼ確実に嫌な臭いがします。
どうもエアコンの熱交換が働いているとき(気温が高いとき、設定温度が低いとき)はあまり臭いがせず、働いていないとき(運転停止後の送風、設定温度が高いとき)はかなり嫌な臭いがするみたいです。
目次: ROCK64/ROCKPro64
先日(2018年7月23日の日記参照)ROCK64のU-Bootがdistro boot(U-Bootのdistro bootの説明)を使っていることはわかりましたが、もう少し具体的に調べておきます。
U-Bootは起動するとカウントダウンを始めます(Hit any key to stop autoboot... と表示される通り、何かキーを押すと止まります)。カウントが0になると、bootcmd環境変数に設定されたスクリプトを実行します。まずはそこから追います。
U-Boot 2017.09-g5aef9f7 (Oct 12 2017 - 09:11:39 +0000), Build: jenkins-linux-build-rock-64-136 Model: Pine64 Rock64 DRAM: 4 GiB MMC: rksdmmc@ff500000: 1, rksdmmc@ff520000: 0 *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Pine64 Rock64 normal boot Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 => => print bootcmd bootcmd=run distro_bootcmd => print distro_bootcmd distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done => print boot_targets boot_targets=mmc0 mmc1 usb0 pxe dhcp => print bootcmd_mmc0 bootcmd_mmc0=setenv devnum 0; run mmc_boot => print bootcmd_mmc1 bootcmd_mmc1=setenv devnum 1; run mmc_boot
今回追いかける対象はSDカードからのブート(ROCK64の場合はmmc1として認識)ですので、mmc0, mmc1に注目します。bootcmd -> distro_bootcmd -> bootcmd_mmc1 -> mmc_bootと辿れます。ここまでは単純です。
環境変数: devnum=1 ---------- => print mmc_boot mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi ---------- 改行入れた版 if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi ---------- ifの条件式だけ実行した場合 => mmc dev 0 Card did not respond to voltage select! ★★★失敗する mmc_init: -95, time 9 => mmc dev 1 switch to partitions #0, OK ★★★成功する mmc1 is current device
このスクリプトはmmcデバイスを使えるかどうかチェックしています。devnum=1のときはmmc dev 1ですね。単独で実行するとわかりますが、このコマンドは成功し、デバイスが使用可能だとわかります。
デバイスが使用可能だとわかれば、scan_dev_for_boot_partを呼びます。
環境変数: devnum=1 devtype=mmc ---------- => print scan_dev_for_boot_part scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done ---------- 改行入れた版 part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done ---------- 最初の行 => part list mmc 1 -bootable aaa ★★★aaaは結果を格納する環境変数名(何を指定してもOK) => prin aaa aaa=6 ★★★boot可能パーティション番号が設定される 全部のパーティションを表示 => part list mmc 1 Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000040 0x00001f7f "loader1" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 guid: 9bdf460d-26ba-4f39-b43f-e8289847b709 2 0x00001f80 0x00001fff "reserved1" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 guid: 50b5d36d-c009-4538-925e-a4ca3db6f3b9 3 0x00002000 0x00003fff "reserved2" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 guid: cbcf51cb-465b-47ee-a4ca-1c1ef59a8564 4 0x00004000 0x00005fff "loader2" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 guid: fd2b2a59-fb82-4e11-827b-2297cdb0b74f 5 0x00006000 0x00007fff "atf" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 guid: 10194a7e-66c7-4340-a932-060295f19fba 6 0x00008000 0x0003ffff "boot" attrs: 0x0000000000000004 ★★★6にboot可能フラグが存在 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: dbb99d65-e937-46a9-b740-256da98658a0 7 0x00040000 0x01cf7fde "root" attrs: 0x0000000000000000 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 guid: 55c58d2b-29ce-4c0d-bfec-414479e8ca46 ---------- 2行目 => part list mmc 1 -bootable aaa => print aaa aaa=6 => env exists aaa || setenv aaa 1; ★★★左のコマンド結果が真のため、右のコマンドは実行されない => print aaa aaa=6 ★★★値は変わらない => setenv aaa ★★★環境変数を削除する => print aaa ## Error: "aaa" not defined => env exists aaa || setenv aaa 1; ★★★左のコマンド結果が偽のため、右のコマンドが実行される => print aaa aaa=1 ★★★値が1に設定される ---------- ifの条件式 => fstype mmc 1:6 bootfstype => prin bootfstype bootfstype=fat
1行目はboot可能フラグを持ったパーティションがあるかどうかを見ています。あればdevplist環境変数に「パーティションの番号」が設定されます。
2行目はboot可能フラグを持ったパーティションがなかったときのフェールセーフ処理で、先頭パーティション(1番)から起動を試みます。
ループ内のif文はパーティションのファイルシステム形式を取得して、bootfstypeという環境変数に設定します。ファイルシステムがわからない場合は処理をやめます。
あと、ループの条件文のところでdistro_bootpartにdevplistに格納されているパーティション番号(今回の場合は6)が設定されます。これも後で使われます。
環境変数: devnum=1 devtype=mmc distro_bootpart=6 bootfstype=fat ---------- => print scan_dev_for_boot scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi; ---------- 改行入れた版 echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; ★★★成功すれば、以降は実行されない(他のscan_dev_xxxも同様) run scan_dev_for_scripts; done; run scan_dev_for_efi; ---------- boot_prefixesの内容 => print boot_prefixes boot_prefixes=/ /boot/
メッセージを出して、scan_dev_for_xxxのいずれかを実行します。これらのスクリプトは成功すると、OSつまりLinuxなどに制御が移りますので、成功したらU-Bootに戻りません。試す順は下記のようです。
今回はdistro bootを使っていますので、scan_dev_for_extlinuxスクリプトを見ます。
環境変数: devnum=1 devtype=mmc distro_bootpart=6 bootfstype=fat prefix=/ もしくは /boot/ ---------- => prin scan_dev_for_extlinux scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi => prin boot_extlinux boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf ---------- 改行入れた版 -- scan_dev_for_extlinux if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi -- boot_extlinux sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf ---------- ifの条件文 => if test -e mmc 1:6 /extlinux/extlinux.conf; then echo OK; else echo NG; fi OK => if test -e mmc 1:6 /boot/extlinux/extlinux.conf; then echo OK; else echo NG; fi NG ---------- 新出の環境変数 => print scriptaddr scriptaddr=0x00500000 ---------- sysbootのヘルプ => sysboot sysboot - command to get and boot from syslinux files Usage: sysboot [-p] <interface> <dev[:part]> <ext2|fat|any> [addr] [filename] - load and parse syslinux menu file 'filename' from ext2, fat or any filesystem on 'dev' on 'interface' to address 'addr'
ブートするパーティションにextlinux.confという名前の設定ファイルがあるかどうかを探し、あればboot_extlinuxスクリプトを呼びます。boot_extlinuxはsysbootコマンドを呼びます。
今まで設定してきた環境変数を総動員してあてはめると…、最終的には下記のコマンドが実行されることがわかります。
sysboot mmc 1:6 any 0x00500000 /extlinux/extlinux.conf
もちろん、このコマンドを単独で実行しても起動するはずです。
# cat extlinux/extlinux.conf
label kernel-4.4
kernel /Image
initrd /initrd.img
fdt /dtb
append earlycon=uart8250,mmio32,0xff130000 rw root=LABEL=linux-root rootwait rootfstype=ext4 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#}
言い忘れてました。extlinux.confはこのような記述です。カーネルイメージ(Image)、initramfsイメージ(initrd.img), デバイスツリーブロブ(*.dtb)のファイル名、カーネルに渡すコマンドラインを指定できます。
GRUBの設定ファイルに似ているけど、もっとシンプルですね。
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は単独動作と同じで良いです。性能は後で考えるとして、とりあえず動作するはずです。
クラスタのノード一覧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台でも難しいものだな。
LINPACKのビルドができたので、さっそく実行してみます。バイナリはbinディレクトリの下にあります。
実行の仕方はmpirun -n 4 xhplのようにします。パラメータファイル(HPL.dat)が置いてあるディレクトリで実行してください。
これが最速パラメータかどうか自信がありませんが、とりあえず10GFlopsだそうです。
しかしhdk氏のAMD A10-7870Kは19GFlops出ているそうです。両者ともにBulldozer系のAPUなのに、倍も差がつく理由がさっぱりわかりません。謎です…。
何気なくcblasとatlasのスタティックリンクをやめて、ダイナミックリンクに変更したところ、いきなり性能が上がり1.7倍の17GFlopsになりました。
AMD A10-7800での実行結果(ダイナミックリンク版)
えー?なぜ!?とりあえずperf topで見てみるとlibatlas.soの関数が8割ほどの実行時間を占めています。ここが効率的になったんでしょうか?そんなに変わるものですかね、さっぱり意味がわかりません…。
ROCK64でも実行してみました。SoCはRockchip RK3328、CPUはCortex-A53 x 4 です。
大体1.5GFlopsでした。A10-7800と比べるとやはり1桁違いますね(PCが6.7倍速い)(ダイナミックリンク版だと11倍速い)。
コンパイル実験(2018年8月12日の日記参照)のときはPCが18倍ほど速かったので、コンパイル実験よりは差が縮まっている、とも取れます。
電力効率の点から見ると、PC 1台よりROCK64を10台並べた方が省エネなのでしょうか?微妙かな…?今度、ワットチェッカーで比べてみましょうか。
自分のマシンは何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版です。
コードを展開し、setupディレクトリの下にあるMake.xxxをトップディレクトリにコピーして使います。たくさんファイルがありますが、AthlonマシンなのでLinux_ATHLON_CBLASを選びました。FBLASという名前のファイルもありますが、
のようです。用語の意味はわかりませんが、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
あと、私の環境の場合、下記パッケージのインストールが必要でした。
実行はまた今度にします。
最近の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を実行しますと、
不遇のBulldozer系コア、もはや4年落ちとなったCPUで、大して速くはありませんが、十分実用的というか、待っていられるレベルです。
Intel Pentium J4205、16GB DDR3L-1600のPCでlinux-next x86のtime make -j4 allを実行すると、
Pentium JはAtom系列で遅いと思いきや、予想より何倍も速かったです…。ナメてました、ごめんなさい。
ROCK64、Rockchip RK3328、Cortex A53 x 4、4GB DDR3でlinux-next arm64のtime make -j4 allすると、
PCと比較するとほぼ1桁遅いです。さすがにこれは待っていられません。ROCK64は普段使いには十分速いですが、開発に使うのは辛そうですね…。
Raspberry Pi 3、Broadcom BCM2837、Cortex A53 x 4、1GB LPDDR2でlinux-next armのtime make -j4 allすると、
ビルドしているアーキテクチャが違う(ROCK64はarm64、RasPi 3はarm)ので、単純比較はできませんけど、ROCK64と大差ないですね。
今のところスマホ、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)といった桁違いメニーコアがありますが、そんなに要らないんですよね…。
中間の製品はありません。買う人いないんでしょうね。
今後のお買い物の参考に、ざざっと調べてみました。
性能だけ求めるなら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も初めて使ったとき「は?何だこれ……??」と思いました。どちらも終了方法がわからず、まともに使えませんでした。今はIDEもVimも適度に使っています。
でもEmacsは完全に使い方を忘れてしまった。ごめんねEmacs…。
< | 2018 | > | ||||
<< | < | 08 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 | - |
合計:
本日: