トップ «前の日記(2016-12-14) 最新 次の日記(2016-12-28)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

ToDo:


2016-12-23

_ あらゆる計算が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)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2016年
12月
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
1.shinh(2016-12-14 13:34) 2.morrita(2016-12-14 03:48) 3.notogawa(2016-12-02 20:44)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h