はじめてのにき

_ NiZ

リアルフォースとかHHK的なやつを作ってる会社らしい。最近の中国はいろんなものを、安く、同じ品質で、カスタマイズ性を高めて、売るなあという感じ

でこれを買ったけどなかなか良さそう

https://www.amazon.co.jp/dp/B075XM7R3W/

レビューにもあるけどリアルフォースとは結構反応は違う。どっちがいいということはよくわからないけど、 NiZ の方が軽い。 NiZ の方があうかもしれない。

カスタマイズ性は、バネを入れれば重さを変えられる、というのと、キーボード側にある(!)ソフトウェアを Windows アプリからいじることによって、キー配置とかを変えられるらしい。ただ Windows 環境がなくてこれは試せてない…

(09:04)

_ 英語

識別子とかまで日本語？と聞かれて。観測範囲では

• 識別子は全部英語
• コメントは入ったチームは英語。まあそもそもコメント少なめ感
• コミットメッセージもチームは英語、別のとこは日本語の人がいたなぁ
• レビューはうちは全部英語、そもそもやってないチームもある
• ドキュメントは日本語が多い感じ
• 重要な手続きとかは日英両方みたいな書き足しを頑張ってるぽい
• TGIF的な会合は英語
• チャットがおおむね日本語たまに英語
• 口頭もほとんど日本語だけど、なんかたまに英語を聞く

くらい

(00:00)

_ PFN

最初の3日の感想

• 想像してたよりは普通に会社だなあという感じ。あまり大きな不満がない
• 仕事はしばらくはすごく楽しそう。まあプロジェクト変えた場合でもそうなるし、これは別の会社にしててもそうだったかなと思う
• 日本語がほとんどなのは、すごく楽…

(18:39)

_ DU

ディスクを整理したい時、長年 DU='du | sort -n' という alias を愛用してたのだけど、止めたくなっても途中経過見られないのが嫌だったのと(まあ止めて走らせなおせばキャッシュに乗ってて十分なことも多いけど)、最近はケタが大きくてぱっと見でよくわからないので、一念発起してスクリプトを書いた

https://github.com/shinh/test/blob/master/DU

• STDERR が tty なら、途中経過を出す
• du の結果を tee に流してるので、 /tmp/du.tmp に途中経過が出る
• /tmp/du.out に最終経過を置いておく
• du と違って 1000 の基数で
• 結果が大きい場合、 Ruby でデータ持ちたくないので持たない
• ソートは万一遅いとイヤなので sort コマンドでやる

というかんじ。まあ便利そう

(16:53)

_ ZenBook 13 UX331UN

いくつか目星つけてたノートPCを見るために秋葉フラフラしてて、ピンと来るやつないなあと思ってたところふっと見つけて、えっこんなのあるの、って買ったやつなんだけど、すごく良い気がする

• i5-8250U: ノートだと i7 は電力的にイマイチな気がする。8世代目はベースとターボブースト時の周波数が全然違う (1.60GHz => 3.40GHz) のでそれも良さそう
• GeForce MX150: 速くはないけど GPU 試すくらいは普通にできるぽい。 X は intel のやつで動かして(たぶん)省電力な感じにしてる
• メモリ8GB / SSD 256GB: もうちょいあると安心だけど、必要十分量
• 13インチ / full HD: 必要十分
• バッテリ: 公称14時間らしいけど、 linux で使ってるとそこまでもつ感じはしない。今度調べるか
• 1.14kg: 普通に軽い。なんか充電器も軽いので良い

20万以上出しても、ここまで僕の要求を都合良く満たすスペックのやつが見当たらないくらいな気がする。安くて良いものが好きな貧乏症としてはとてもいいものだった

(13:09)

_ ホリエモン

https://r25.jp/article/560392031878166383

そうそう、やっぱホリエモンいい人ぽいよね、と思ったけど、よく考えると割と普通のことばっか書いてあった

映画のジャイアンみたいな…

(17:14)

_ SGEMM

適当に色々走らせてみる。

CPU-avx2-256 50.062899 GFLOPS t=150
CPU-avx2-512 36.600433 GFLOPS t=14
CPU-avx2-1024 41.914810 GFLOPS t=10
CPU-blas-256 245.587644 GFLOPS t=732
CPU-blas-512 359.621543 GFLOPS t=134
CPU-blas-1024 507.372811 GFLOPS t=24
GPU-mine-64 64.069479 GFLOPS t=12221
GPU-mine-256 246.106109 GFLOPS t=734
GPU-mine-1024 137.683075 GFLOPS t=10
GPU-cublas-64 68.099346 GFLOPS t=12989
GPU-cublas-256 1666.332399 GFLOPS t=4967
GPU-cublas-1024 3462.507099 GFLOPS t=162

CPU-avx2 は Haswell 向けになかむらさんの文章見て適当に書いたコード。当時は BLAS とここまで差が無かったと思うし、なんかヘンなので後で見る。

GPU-mine はもっとどうでもいい、本気で適当に書いたもの。おいおいこんな適当なコードで BLAS に勝つんかと思った

GPU 自体は GTX 1060 3GB というやつで、 Pascal 世代らしい。 1152 コアで最大 1.76GHz 。理論は 4TFLOPS らしい？

次は、最近買ったノートPCにて

CPU-avx2-256 37.796423 GFLOPS t=113
CPU-avx2-512 26.427590 GFLOPS t=10
CPU-avx2-1024 36.619350 GFLOPS t=10
CPU-blas-256 4.165613 GFLOPS t=13
CPU-blas-512 4.127086 GFLOPS t=10
CPU-blas-1024 3.944004 GFLOPS t=2
GPU-mine-64 29.070758 GFLOPS t=5545
GPU-mine-256 57.308421 GFLOPS t=172
GPU-mine-1024 20.952593 GFLOPS t=10
GPU-cublas-64 46.641611 GFLOPS t=8897
GPU-cublas-256 505.182081 GFLOPS t=1506
GPU-cublas-1024 1028.495491 GFLOPS t=48

CPU-blas の成績は明らかにおかしい。 GPU は MX150 というやつで、こいつも Pascal 世代らしい。 384 コアで最大 1.04Ghz 。理論(?) 1.127 TFLOPS、かな？

10 万強で 1kg 強の ノート PC で TFLOPS 出てるんだなあ

(22:58)

_ ffrkメモ

• 10メア: 75%。ユウナがチェイン、ワッカは2回いかる。オーバーデスが来るので急ぐ
• 3メア: 66%。ルーネスが石化避け。アルクゥがチェイン
• キマイラブレイン: ビビは回復せずにトランスさせる。チェイン切れた直後にメンブレ。その後2回目のエッジがヘイスガ解除受けて分身

(09:08)

_ 性犯罪者

https://gqjapan.jp/culture/column/20150730/welcome-to-pariah-ville/page/4

最初はキツいなあ、と思ったけど、バランス取れた感じの、いい記事だなあと思った。

(20:06)

_ Q#

Codeforces & Microsoft の量子プロコンで触った。

http://codeforces.com/contest/1002/

最後の問題解けなかったのは、サイズ N の配列を返さないといけないところに、 N+1 個返してたからぽかった。残念すぎる。

問題セットはwarmupも含めてすごく良い感じだったと思う。解けないほど難しい問題はなくて、基本的かつ教育的な、僕にとっては「そういえばそんな話があった気もするなあ……」くらいの問題が並んでいる感じ。そういう全部解かれる前提の問題設計だったのか、そもそも量子情報で「あまりよく知られていなくて、量子性を利用していて面白く、十分に難しく、古典でのシミュレーションで実行できる」みたいな条件がそろう問題ってあまりないのか、まあどっちかというと後者なんじゃないかなと思うけど、それにしても基礎的な問題が多かった印象

ただ D1 と E1 の方が量子の面白さを伝える感じなのに対して、 D2 と E2 はひっかけ問題チックなので、イマイチかなあ…と思った。 E2 が時間かけたのにも関わらず解けなかった問題なので、言い訳くさいけど。

Q# は、言語としてもシミュレータを含めた環境としても、なかなかよくできているなあと思った。古典情報と量子情報の往復の部分とかは、そのまんま自力で書く感じ。量子→古典の移動は、観測を伴ってしまうので、まぁ明示的に書かせるのが良いのではないかと思う。あまりトランスペアレントにしたくないかなと。

一方で古典→量子の移動、要するに Qubit の初期化の部分は、これはなんか適当な状態を自由に作る手段があっても良いのかなあ……と思った。アルゴリズム考えてる時とか、「仮にこういう状態が作れるとしたら、こういうアルゴリズムは作れるだろうか？」と考えてから、「実際その状態、作れるの？」と考えたいこともあるんじゃないかなあ、と。シミュレータならいきなりそういう状態で初期化してくれれば良いし、実機では適当に精度指定すると存在するオペレーションでやってみてくれて、合成できない(オペレーション数が多すぎる場合も含めて)場合はエラーにする、とかで良い気がする。

PrepareArbitraryState というライブラリ関数もあるのだけど、 W state 作る問題で使ってみたら遅すぎるようだった。

https://docs.microsoft.com/en-us/qsharp/api/canon/microsoft.quantum.canon.preparearbitrarystate?view=qsharp-preview

(00:50)

_ 就活 起業を嫌いになった理由.pdf

https://drive.google.com/file/d/1QlDRAyAN926YoBuBb9auo4WZdhCyh7fC/view

面白い…

(14:16)

_ 旅館大松

名古屋の宿の近くに、死ね金返せ系の落書きがたくさんある旅館があって怖かった

https://www.instagram.com/explore/tags/%E6%97%85%E9%A4%A8%E5%A4%A7%E6%9D%BE/

こういうの実在するんだな……バキの家みたいって思ったら、2chとかでも同じこと言ってて笑った

(14:20)

_ ノートPCの設定

仕事にも使う予定なので、 Debian は微妙かなあと Ubuntu にすることにして、 16.04 はちょっと微妙問題があったので、 Ubuntu 18.04 でいってみることに

何度もする作業をメモ

最初にすべきこと

scp "i@xxx:.*" .
sudo apt-get install ssh screen zsh
chsh
sudo apt-get install git subversion g++ make gauche ruby python3 python3-pip lv
scp -r i@xxx:bin .
scp -r i@xxx:lib .
zsh
git clone git@github.com:shinh/test.git
svn co $SVN wrk
cd ~/wrk/fake_isatty
sh build.sh

sevilwm

apt -i libxrandr-dev
cd ~/wrk/sevilwm
rsync -avr "i@xxx:wrk/sevilwm/dev" .
make
sudo cp sevilwm /usr/local/bin

w3m

apt -i libgc-dev libimlib2-dev libncurses-dev
scp -r i@xxx:.w3m .
cd ~/wrk
git clone git@github.com:shinh/w3m.git
cd w3m
./configure && m
sudo make install

apt-file

apt -i apt-file
sudo apt-file update

適当に色々。 sevilwm に切り替える準備

apt -i ghc ocaml rlwrap emacs wicd gkrellm xscreensaver feh
apt -i mlterm
scp -r i@xxx:.mlterm .
sudo vi /usr/share/xsessions/custom.desktop
[Desktop Entry]
Name=Custom
Exec=/etc/X11/Xsession

CUDA

apt -i mesa-utils
# follow nvidia's instruction for CUDA...
sudo apt-get install -o Dpkg::Options::="--force-overwrite" cuda-9-0
sudo dpkg -i libcudnn*.deb

MLフレームワーク

pip3 install cupy
# gcc-7 でコンパイル通らんので編集
# sudo vi /usr/local/cuda/targets/x86_64-linux/include/crt/host_config.h
pip3 install cupy
pip3 install chainer
pip3 install tensorflow

UIM SKK

apt -i uim-skk ddskk
uim-pref-gtk3

忘れがちな開発ツールまわりの

apt -i autoconf automake libtool texinfo flex bison glibc-doc libc6-dev:i386 libgcc-7-dev:i386 libstdc++-7-dev:i386 lib32gcc-7-dev valgrind

(20:38)

_ define-and-run vs define-by-run

• 前者は TF や Caffe などとされている
• 後者は Pytorch や Chainer や DyNet などとされている

https://twitter.com/taku910/status/1010082944629727234 などを見てもそうだけど、この用語法が良いかどうかは議論の余地があると思う。

define-by-run が研究時に有利なアプローチなのは間違いないという合意は形成されつつあるようにあると思う。プロダクショナイズ時の整合性の保証と、トレーニング速度の心配が define-by-run で気になることかと思う

プロダクショナイズ

define-and-run はデプロイ時に Python のランタイムが必須でなくなり、また、トレーニング時に使ったモデルが正しく使われている保証が取りやすい。ただし

• define-by-run であっても、モデルを適切にエクポートする手段があれば、問題なく Python を分離できる。最も強いエクスポートの標準化は ONNX
• define-and-run であっても、モバイルデバイスや、もっとエッジなところで動かしたい場合、例えば TF の C++ ランタイムですら邪魔なので、いずれにせよエクスポートしないといけない。 tf.Estimator の saved_model から TF lite の流れなど

トレーニング速度

原始的な define-by-run はホスト言語に処理が戻ってくるので、速度が出しにくい。ただ、最適化の余地があって

• 遅延評価する。 DyNet がこれプラス auto-batching もしてくれるらしい。というか TF の non-XLA なアクセラレータ向けコードパスはそんな感じだと思う
• モデルを一回走らせた結果を最適化して、何度も実行する。 Pytorch の jit.tracing がそれ
• 実例無いと思うけど、投機的に次の計算やるって方法もありえるんじゃないかと思っている

model-as-data vs model-as-code

そもそも、速度が出ないのなら、 Python をコンパイルしちゃえばいいという発想もありえる。これは単に Python を C なりアセンブリに変換するという話ではなくて、 Python 内で記述されたハイレベルなオペレーション群をくっつけていって、アクセラレータ内で完結した実行をしてもらう、という話

「Python をコンパイルする」て語感と実体がだいぶ違うアプローチで、感覚としては CUDA に近いものだと説明している。 CUDA だと、 __global__ てついてる関数はデバイスで実行して、ホスト側に main があってそのデバイスの関数を呼んだりする。同じような感じで、 Python の一部の matmul+activation みたいなところを Python じゃないコードでまとめて実行すれば良い

実際やってるのが Pytorch の @script や、そもそも言語まで変えてしまったのが Swift for TensorFlow 。アクセラレータに投げる部分の抽出と、計算グラフの微分をしたいので、 AST なりなんなり、言語処理系にまあまあ手を入れる必要があると思う。

このへんのアプローチは、気持ちとしては define-by-run のまんまだけど、なんか明らかに事前コンパイルしてる以上、 define-and-run の方が適切な呼び名な気がしてしまうので…… Swift for TensorFlow などは model-as-code と言ってるのだと思う

個人的には model-as-code が正しい方向性に思える

機械学習向け言語

話がそれていく。 Swift for TensorFlow みたいな方向性が正しいとして、欲しい/必要と思う機能として

• 計算グラフの分離
• 自動微分
• 静的型チェック(最低でもランク、できれば次元も含めて)
• Jupytor 的なもの
• Python の呼び出し

あたりを考えてると、 mypy と tangent で(どちらもよく知らないが)、一応 Python をコンパイルして使う、てのは要件を満たしそうな気もする

「TPU のようなもの」

もっとそれていくけど、なんか雑談してると、 XX が作ってる深層学習向けプロセッサー、みたいなことを言うと、「TPUみたいなやつ？」と聞いてくる人がいたりする。深層学習向けに独自に作る価値がある計算装置として

• 学習時に使うやつ。 TPUv2 のようなもの。たぶん、メモリが多く必要、レイテンシよりスループット重視、除算などの命令が必要、 GPU がライバル、などの特徴があると思う
• 推論時にクラウド内で使うやつ。 TPUv1 のようなもの。量子化とかして良いかもしれない。レイテンシ重視。 GPU がライバルになる場合もあるかもしれないけど、むしろ CPU で十分じゃない？的な話が多そう
• 推論時にモバイルデバイスだのもっと小さいもので使うやつ。 distilation pruning quantization あたりでメモリサイズを限界まで落としたいと思う。これは千差万別だと思うけど、行列のかけ算だけをアクセラレートします、みたいな DSP みたいなやつと、特定用途専用の FPGA/ASIC の回路にしちゃう、って話の2つがおおまかに言うとありそうかなあ

XLA あるいは NNVM

トレーニング中は数日とかかけて、何回も同じ計算をするわけで、その計算は、例えば10分とかじっくり時間をかけて最適化しても割にあう。本質的に Python のオーバヘッドからは既にほぼ無縁な TF のグラフだけど、ターゲット向けにゆっくりコンパイルしてさらに速くする方がより良いでしょ、というのが XLA 。 ONNX を入力としてわいわいやってるのが NNVM

いろいろ話はあるけど、トレーニング向けは益がそんなに大きくないのかなあ、という気はしている。けどある程度の命令数を GPU でないアクセラレータでやるのであれば、なんかしらこういうレイヤのものは必要になるだろうしな

(20:55)

_ パナマ

https://www3.nhk.or.jp/news/web_tokushu/2018_0627.html

面白い連載だったけど尻すぼみぽい終わりかたをしていた

(15:39)