ToDo:
という病にかかっているように思う。まあ病といっても悪影響は特にないが
開始地点は…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)
https://twitter.com/omo2009/status/808539204850315264
gflags好きっ子としてはね…というかglobal変数が好きというのがある。GLのアレとかTFのsessionとか、まあ悪くないという感がある。いやそれはあまり関係ないだろうけど
フラグの値をテストの冒頭で挿したりするの、あれはまあいいんじゃないかって感があるケースと、うーん微妙というケースがある気がする
なんかおおざっぱに言うと、フラグが使われるのがモジュール内の奥地で、モジュールのプライベートな関数とかが全部のそのフラグを引きまわすようなケース…これはまあテストの冒頭で挿す方がいいと感じる。なんていうか、テストが汚なくなることによって、プロダクションのコードが綺麗になるならいいじゃないか、的な
一方で、 func(FLAGS_hoge) みたいな感じで渡した引数が func の中だけで使われてないと、これはちょっと引数にして呼び出し側で定義した方がいいかなぁ…などと思うケースも多い気がする
まあでも基本ケースバイケースだと思うんだよなぁ。正直このへんの決定をどっちに倒しても生産性とかに大幅に差は出ないわけで、自分がチーム内で弱い立場なら他の人の決定に従い、強いならちょっと自分の趣味を主張してみる、みたいな、そのくらいでいい気がする。このレベルのことだと、ほげほげというアプローチがグッドプラクティスです、みたいに主張するのも、こう「それによって生まれる軋轢」>「統一によって得られる快適」みたいになる可能性もあるよなと思う
僕はこう一応、このレベルの話に関しては「あ、うん、僕はAの方が好きなんですけどね、まあBの主張もわかるんで…このプロジェクトはBで統一しましょう」みたいな対応をできてる……つもり……だといいな……ホントかな
(00:57)
本質的に書く流儀みたいなのがわれやすい感あるよね。
似たようなちょっと難しいテストケースを複数書く時とか、どうも同じコードをコピペしがちになって、それはよくないと共通部分をくくり出したりすると、それはそれで「テストはのっぺりとした入出力の羅列であるのが望ましい」みたいな感覚と矛盾したりして…
僕はこれについてはどっちかというとくくり出したいタイプかなぁと思う。基本同じロジックが2回以上目に入るのがあまり好きでないのだけど…テストだから小賢しい抽象化しないのが良い、みたいなのが理解できるケースも多いんだよな
まあ知らん系
(01:02)
どうもファンがムダにうっさいぽいので導入してみた。
/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)
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)
最近話してて、ディープラーニングがどうこうって、自然科学ぽさがあるなと思った。計算機科学って人工物なので基本的に原理からきちんとわかってるところが多いわけだけど、ディープラーニングはあまりそうではない。なんだかよくわからないブラックボックスがあって、ミクロな原理はよくわかってないけど、マクロな観測から役に立つものを作ったり。
例えば薬とかって、「原子分子レベルの機序はよくわかってないけど、経験上この物質はこの病気に良くて、直感的な説明はほげほげ」くらいの感覚で実用物を作ってる面があると思う。ディープラーニングも、「quantizeして大丈夫ていう科学的な根拠はないけど、経験上結果に悪影響ないことが多くて、直感的な説明としては、元々ノイズに強いニューラルさんにとっては計算精度の低下もノイズの一つとして扱ってると考えられる」など、まあ似てる
こういう状態で取れる方向性としてはおおまかに二種類あるかなあ…と思う
前者はまさに自然科学という感じで、仮にブラックボックスをきちんと理解できれば、他の計算機科学に近づくかなぁ、と思う。
後者は色々やる、てのを今は人手でやることが多いと思うんだけど、その色々やること自体を機械にやらせることになるのかなぁと思う。そうなるとますますブラックボックスが大きくなることになって、ディストピア感もあるが、それはそれで面白い展開かもなぁと思う
20XX年、ディープラーニングがどう動いてるかをディープラーニングで動くAIに考えてもらったところ、1年ほどの計算の後AIはAIの動作原理を理解したという。しかし人間にはAIの説明するAIの動作原理は理解できなかった……
などという
(22:12)
http://blog.practical-scheme.net/shiro/20161124-machine-translation-as-draft
大変建設的な議論で良いなあ
機械翻訳を下訳に使うての、欧米の言語だと割と普通にやってることらしいですね。EUとかが無限にクオリティの高いコーパスを作ってくれて、それのおかげで機械翻訳のクオリティが良くなり、さらにそれが翻訳作業を加速させてコーパスがたくさんできて……みたいな
(22:16)
http://www.huffingtonpost.jp/michael-moore/5-reasons-why-trump-will-win_b_11254142.html
via https://twitter.com/kinu/status/796257849886183424
マイケルムーアの選挙前の文章、全部面白かったけどきぬこさんがはってた上と
http://www.huffingtonpost.jp/michael-moore/5-ways-to-make-sure-trump-loses_b_11900362.html
はコイツ本当にすごいやつだなあと思った。前者の読みはこれだけ危機感出しても甘かったくらいだったのが現実なわけだが
(02:01)
最近機械学習ぽいこと、というか機械翻訳という、流行りの深層学習を使ってるぽいチームに移ったりしてた。理由は流行りぽいからという、まあ
というような話を結構前にした時に、人生の転機と書いてたのは、結婚か転職かと思われた、というようなことを言われて、そんなの書いたっけ、と思った。まあ結構前に
http://shinh.skr.jp/m/?date=20160609#p01
で思い出して調べたら、ホントだ書いてた。まあ今みたいに酔っぱらって適当なことを書いてたのだと思われる…特に全然違う話題が2行目にあるあたり酔っぱらってる感がある。が調べるとタイミング的にはまあこのへんに異動したぽい
しかし人生の転機でないかと言われるとまあ転機ではなくはないと思う。がまあ結婚か転職でないなら違うというのが通常の考え方かなあと思う。せめて海外転勤くらいしてくれないとという感がある
ええとそんなことよりディープラーニング。よくわからないなあというのが正直なところ。何がわかってないか、何がわかってないとわかってるのか、何がさっぱりわかってないのか、考えてみると
ちょっとこのへんで話題が変わってるというか、個人的な話が増える
などなど……まだまだあったと思うけど
(23:23)
なんだか
みたいなのの、後者2つが多い論調だった気がするんだけど、少しずつ上2つが増えていって、なんかもはやクロと思ってる人いないんじゃないかレベルまで巻き返してて、面白いなあ……とか。
それはそれとして
http://i2chmeijin.blog.fc2.com/blog-entry-4726.html
はひどすぎるっていうか、この人の中ではこれで辻褄あう感じなんだろうか……ていう。まあ元々面白キャラなので、原発美味しんぼで突然「雁屋哲トンデモ！」とか言いだすのと同じで、まあ元々こいう人ですよ……て話なんだろうけど
しかしなんというか「東大生は勉強はできるが常識がない」の東大生を棋士に読み変える的な感想を持つ
(21:14)
http://blog.goo.ne.jp/kishi-akira/d/20161101
すごいなと
出るだけで1000万単位もらえる場に出られなくなくキッカケを作ったわけで、それについて遺憾とも言わない時点でまあ、クロだと思ってるてこと、なのかな
(22:37)
コード行数が評価軸に追加された。
これは電力と違ってあやしげなコーナーケースつきみたいなことしなくていい明確な指標でかつ、普通にゴルフしてて面白いと思うので、一気に面白くなったように感じる
(00:59)
| 前 | 2024年 4月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | ||||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ morrita [概ね同意で、話の流れとしては https://talks.godoc.org/github.com/tcnksm/..]
_ shinh [はい、フラグのとこだけそのスライド読んでから書いたので、もりたさん同様、「良くない例なの？むしろグローバルがいいだろ..]