【TF/Guide笔记】 02. Variable
开篇第一句话就耐人寻味，"A tf.Variable represents a tensor whose value can be changed by running ops on it"，不考虑写文档的人理解不到位（巨头公司应该不至于）的话，光是计算图的定义就跟我以前理解的不一样。
以前我们设计的时候是op和variable交替连接构成一张计算图，这样的好处是很容易分清哪些op是互相独立的，可以op级的并行计算。在这样的设计里，必然要认定variable是只读的，这样作为输入的时候可以被多个op同时读取，但其实只读的问题很大，很多时候级联的梯度必然得加到同一个tensor上，如果逐步展开的话就会增加大量无用的内存开销，最终只能特化了InplaceAdd，并且祈祷不会碰上出bug的情况。
但如果计算图里只有op，而大部分op在设计之初就是原地操作的话，虽然理论上这种op只能串联运行了，但是感觉绝大多数情况下还是靠tensor内的并行来加速的，并不影响多数场景下的加速。而且原地操作占多数的话，就会节省很多中间变量的存储和读写，按理说带来的好处是更大的。
而且这样一来就可以理解人家的循环和control flow是怎么做出来的了，光是在op上操作的话，不会带来大量的variable，搞再多也没事。
至于他这样搞会不会带来一些计算顺序上的问题，说实在的以前我就觉得对计算图算拓扑是个蛮蠢的事，因为最明明白白的拓扑序就是用户写下的代码，顶多在此基础上用output去判断一下哪些是无用节点就够了，甚至于用户写的代码其实还变相的告诉了你哪些操作可以原地做而哪些需要开辟新空间，core根本不用考虑的那么复杂。
tf.debugging.set_log_device_placement(True)，虽然名字起了很长，但用起来感觉就是glog的flag，log印级别调成了计算图一级罢了
基本可以看作Variable和Tensor有相同的操作，但Variable不能reshape，Variable支持原地assign
Variable内部包了tensor，它内部的tensor应该是不能共享的，或者说Variable内部的东西只有它自己有所有权，不管是怎么构造来的。这样的确方便管理
Variable的生命周期与py obj的周期相同，想上去应该就是利用了py的语义，没有引用的时候自动释放了内存。不过这里的是否没有引用，还得看op在使用Variable定义的时候是不是拿到了所有权
声明Variable的时候可以加参数trainable，说明它内部应该是默认有data和diff两个tensor，这跟我们以前的设计差不多
可以手动指定Variable所在的device，这个应该也受益于原地操作的设计，但或许会给op的实现带来很多麻烦，不过只要人力足够这些都不是问题
不指定device的时候它会自己找合适的，估计就是连续tensor优先进GPU吧，这玩意应该也写不出很复杂的策略
使用了set_log_device_placement之后会发现，tf里的所有操作最终都对应到了计算图的运行上，甚至连tf.constant都不例外，不过这里使用的是eager execute，估计本身就是非常轻量的，不像我们原来跑个图至少两把锁
