はじめてのにき

_ 依存型

Tensorflowでshapeに定数じゃない値で型つけたいみたいな気がするけど、依存型てそれ？て聞いたら、そうだがこれを読め、と言われて流し読みした

http://notogawa.hatenablog.com/entry/2016/11/19/145847

なるほどよくわからん…が銀の弾丸じゃないぽさが漂ってるなあ…と思った。僕が欲しいのは単にtype annotationに近いものな気がするな

それはそれとして、型だけじゃなくて、実行フェーズが二段階ある、てのも話をややこしくしてるなぁとか思う。なんかスコープが複数ある感じになるのがなぁという。スコープとかデバイスの設定にwithを使ったりするわけだけど、あれはmutexとかと似た面倒さがある気がする

def foo_in_scope:
  return ...

def foo:
  with scope():
    op = foo_in_scope()

def foo_and_bar:
  with scope():
    op = foo_in_scope()
    op = bar(op)

みたいなやつとか。foo_in_scopeにwith文持っていって共通部分をくくり出したい気がするけど、できない系

(10:10)

_ fancontrol

どうもファンがムダにうっさいぽいので導入してみた。

/etc/default/grub をいじって

GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax"

その後 sudo pwmconfig 。できたファイルを見ると FCTEMPS が無くて不審だった。なんかどうも temp3 が CPU 温度ぽかったので

INTERVAL=10
DEVPATH=hwmon2=devices/platform/it87.2608
DEVNAME=hwmon2=it8728
FCTEMPS=hwmon2/device/pwm1=hwmon2/device/temp3_input
FCFANS= hwmon2/device/pwm1=hwmon2/device/fan1_input
MINTEMP=hwmon2/device/pwm1=20
MAXTEMP=hwmon2/device/pwm1=60
MINSTART=hwmon2/device/pwm1=150
MINSTOP=hwmon2/device/pwm1=0

て感じで。負荷かけてみた感じ一応機能してるみたい…

(12:01)

_ フラグ

https://twitter.com/omo2009/status/808539204850315264

gflags好きっ子としてはね…というかglobal変数が好きというのがある。GLのアレとかTFのsessionとか、まあ悪くないという感がある。いやそれはあまり関係ないだろうけど

フラグの値をテストの冒頭で挿したりするの、あれはまあいいんじゃないかって感があるケースと、うーん微妙というケースがある気がする

なんかおおざっぱに言うと、フラグが使われるのがモジュール内の奥地で、モジュールのプライベートな関数とかが全部のそのフラグを引きまわすようなケース…これはまあテストの冒頭で挿す方がいいと感じる。なんていうか、テストが汚なくなることによって、プロダクションのコードが綺麗になるならいいじゃないか、的な

一方で、 func(FLAGS_hoge) みたいな感じで渡した引数が func の中だけで使われてないと、これはちょっと引数にして呼び出し側で定義した方がいいかなぁ…などと思うケースも多い気がする

まあでも基本ケースバイケースだと思うんだよなぁ。正直このへんの決定をどっちに倒しても生産性とかに大幅に差は出ないわけで、自分がチーム内で弱い立場なら他の人の決定に従い、強いならちょっと自分の趣味を主張してみる、みたいな、そのくらいでいい気がする。このレベルのことだと、ほげほげというアプローチがグッドプラクティスです、みたいに主張するのも、こう「それによって生まれる軋轢」>「統一によって得られる快適」みたいになる可能性もあるよなと思う

僕はこう一応、このレベルの話に関しては「あ、うん、僕はAの方が好きなんですけどね、まあBの主張もわかるんで…このプロジェクトはBで統一しましょう」みたいな対応をできてる……つもり……だといいな……ホントかな

(00:57)

_ まあテストというのは

本質的に書く流儀みたいなのがわれやすい感あるよね。

似たようなちょっと難しいテストケースを複数書く時とか、どうも同じコードをコピペしがちになって、それはよくないと共通部分をくくり出したりすると、それはそれで「テストはのっぺりとした入出力の羅列であるのが望ましい」みたいな感覚と矛盾したりして…

僕はこれについてはどっちかというとくくり出したいタイプかなぁと思う。基本同じロジックが2回以上目に入るのがあまり好きでないのだけど…テストだから小賢しい抽象化しないのが良い、みたいなのが理解できるケースも多いんだよな

まあ知らん系

(01:02)

_ あらゆる計算がDAGに見える

という病にかかっているように思う。まあ病といっても悪影響は特にないが

開始地点は…8年前とかで、 GNU gold なんかの記事を読んだあたりじゃないかと思う。まず、会社に入って、なるほど並列計算というのは色々難しいな、 asynchronous なサーバはこういう感じになるのか、などということを肌で感じた。で、 GNU gold がタスクをタスクキューに突っ込んでいって、終わったら依存が全部解決してるタスクが実行可能になって…みたいなモデルだと読んで、なるほどこれはバカパラレルでない計算についても最高速が出せる、完璧に正しいアプローチだなーとか思ったように思う

数年は完璧だと思ってたと思う。 Molatomium なんかが素晴らしそうだーと思ってた

http://jglobal.jst.go.jp/public/20090422/201102297100224901

実際、このモデルは計算の粒度が大きい、ビルドシステムみたいなところでは完全完璧に動く。ビルドシステムに色々な理由で関わって、この周りについてアレコレ考えたことは、病状の進行に間違いなく影響があったと思う。

でも、どこかの段階かで、銀の弾丸でないことに気付いていったと思う。実際、計算の粒度が細かいところで、このモデルで成功してる、つまり最高速に近い速度が出せてる計算環境は無いんではないかと思う。

理屈の上では完璧最強なDAGをワーカーどもが順番に取っていくモデル、なんで実際成功しないかというとデータのローカリティと同期のコストだと思う。つまり、理論上計算が完全に無駄なくスケジューリングされてるように見えて、粒度の細かさに反比例したロスが同期で起き、さらにデータのコアやマシン間のデータ移動でのロスも起きる。

僕が関わるようなシステム(つまりおおむね規模が大きく、計算よりはIOやメモリに律速されている)では、データのローカリティの方が特に大きかったように思う。例えばkatiで同時に計算できるから、こことここはパイプラインで…みたいなことをやったら、2倍弱くらいになって欲しいのに実際は1割かそこらしか速くならない、みたいなことがちょくちょく起きた。これなんかは非常に粒度が大きい並列化で、プログラムを書いた本人が、一番適切だと考えてる、つまり一番同期の回数が減るであろうと考えてる地点でブチっと切ってるにも関わらず、あまりうまくいかなかった。コードの見た目の裏で行なわれてる、キャッシュミスの影響がでかいということかなと思う。

こういう話をしてると、「今時のコンパイラは人間より賢いから〜」氏が湧いてきたりする。これはまあ…局所的なところでは正しいこともあるし、特に計算が律速してる世界では正しいことも多いと思うんだけど…データをどこに置くか的な話題はまだまだコンパイラにはできないように思う(もちろん研究はたくさんあるようだが)。というか、C言語をはじめとする現代のプログラム言語の抽象単位が、データへのアクセスを等速と考えすぎてて、なんかうまいこといく気が全くしない

でも、「今時のコンパイラは人間より賢いから〜」氏がそんなに論外なことを言ってるかというと、むしろ氏は結構正しくて、実際問題人間がとても効率的に動くデータ配置を考えてるうちに、機械が目的を達成してる、なんてことはまあ普通に起きるわけで。ここで最適化というのは、単に最速でリリースできるような結果が欲しいという話で、5年後に0.01秒でサーブできるシステムができるよりは、1年後に1秒でサーブできるシステムができる方がいい、っていう、ガチ最適化屋としてはつまらないであろうトレードオフがあり。まあつまり老人が言ってるイメージ、というかステレオタイプがある「結局機械の最適化は人間がやる最適化には勝てない」は、無限時間が経過した後では正しいのだけど、現実には無限の時間給料払ってられないので、まあトレードオフになる

さてそんなところにtensorflowです。これは完全にDAGをどうこうという計算モデルで…しかし人間が tf.device でどこで計算をするかを決めることができる。うーんなるほどという感じ。こいう計算モデルで計算時間的に最速のものが出来るとはとうてい思えないけど、まだまだどういうふうにやればいいか固まってないジャンルだけに、とにかく開発者が新しいモデルを実験する時間を最小化して、しかし年月単位とかでは待ちたくないので、ほどほどにスケールするようにする、てのはなかなか良い落としどころな気もする…

まあ、で、それはそうとDAGに戻ると、LLVMのバックエンドを見ると、これはこう、SSAしたコードてのは、最初っからDAGなわけです。TFのDAGも実質一個ループを入れてやれば十分にTuring完全なやつだろうし…うーんDAGてのは強力な物体だなあなどと思うわけです

CPUてこう、最終的には順番に並んだ命令を実行してるわけだけど、現代的のCPUは命令列からDAGというか依存関係を復元してたりするわけで、そもそも最初から命令セットは単なる配列じゃなくて、DAGであるべき…てことはないんですかねえ。現代的なコンパイラがDAGを作って命令列に落として、CPUが命令列からデータ依存を考えてる…てのはムダな気がするというか

PEZYの人たちとかが死ぬほど考えてそうな話題だとおもう

(02:12)

_ れじすたあろけーしょん

世の中色々デバッグが大変なものというものがございますが

レジスタアロケーションやスタックへのメモリ割りつけはクッソ大変なものの一つだよなってことを

思い出しました

(13:08)

_ 大変な理由

まず一般的に、そもそもデータを出力するプログラムのデバッグは大変。なぜなら、苦労しておかしいところをつきとめるまでは作業の序盤で、何故おかしな値を出したか、を調べなければならないからで、通常出力されたデータには出力した理由とかが不十分にしかあらわれていないことが多いから

レジスタアロケーションとかが何故余計大変かっていうと、アセンブリだからってのがあり。アセンブリっていうやつ、読む訓練を積んでいると読むの速くなっていくわけだけど、あれ何故速くなってるかというと、「こういうパターンの時はこういう操作をしている」というパターンマッチをひたすら行なう処理を良くしていってるから。

で、そのパターンマッチは出力されたコードは正しいことを前提にしてるから、すごく細かい、ここでBPからのオフセットが1つずれてる…みたいな処理は、本当見落とす。かといって脳内のパターンマッチルーチンを切った状態でアセンブリ読むのは慣れてないのだよなあ

(13:14)

_ チャート式

http://yukilingo.hatenablog.com/entry/2016/12/25/235754

高校がまさにこういう物量教育で辟易してたなぁと思う。うちの高校の言う通りやってりゃ受かるとか自慢げに言ってたけど、んなもん言う通りやってたらそれやるだけで1,2浪するがなっていう

全部やってこいみたいな宿題出てたから、半年くらい遅れつつ答えを全部写経(どうせチェックされないので適度に飛ばしつつ)してたけど、あの時間無駄もいいところなんで、つまり受験の邪魔されてたんじゃないだろうか

(21:38)