【TF/Guide笔记】 10. GPU
用户可以限制GPU上的内存使用，但这个限制并不是所谓的“优化”，毕竟，如果有明显能节省的内存，框架干嘛非等你打开开关再去优化它呢。
tf提供了两种限制内存的方法，第一个是打开增长模式（set_memory_growth），我理解的是，一张计算图上前后涉及很多的Variable，你可以指定当一个Variable用完之后就析构掉。这个优化在默认情况下不做，是因为计算图是batch级运行的，需要重复跑很多次，如果Variable被析构了，下次跑到这儿还得申请回来，带来额外开销，所以需要用户去做权衡。
另一种方式是严格的限制内存，可以虚拟一张GPU然后在上面运行，给虚拟的GPU分配一个上限，那从外面来看你怎样都不会超过这个值，只不过当你真的必须要用更多的时候，程序就只能挂了。
不得不说虚拟device是个不错的东西，不仅能控制内存，还可以在开发环境模拟分布式。
个人推测，当一个Variable的存放位置和计算图的执行device不一致的时候，计算图会自动连接一个fetch op，从另一个GPU也好，从CPU也好，甚至是另一台机器上的device，对fetch op来说都是一样的，这样底层实现的接口就会很统一，只需要根据两头的device和配置的协议选择对应op就行了。不过这样的话，fetch的一方还好说，存Variable的那边得有一个线程专门执行fetch指令吧，那这个任务是在什么时候启动的就不一定了，而且难道说worker上有完整的一套类似ps的逻辑？
在最后肯定还会有个类似push的op，将改动后的Variable放回ps，结合coordinator分发任务的模式来看，用户很容易可以自己把一个计算图拆分成很多段任务，然后不断的扔给worker去跑，把上游step的结果传给下游，它应该自己会找到对应的Variable，也就是存在ps上的中间结果。这主要是为了应对模型非常复杂，Variable多到本地跑一个step都存不下的情况。
关于TPU，我去搜了一下这东西的工作原理，有一篇发布在谷歌云上的介绍写的还是蛮详细的，给我的直观感受是，这个东西也没有想象中的那么技术垄断。
它内部针对机器学习所做的优化在论文里都有详细的说明，比如用8位整数代替浮点运算，比如增加指令集，哪怕是不大好懂的脉动阵列，感觉这些只要有硬件足够扎实的人来当设计师，咱们抄个作业应该还是蛮容易的，迭代个两三次，哪怕只有TPU八成的水平也足够了，至少不是绝对的被垄断了。目前华为似乎就有这种专门为AI研发的芯片，看来也不必太过悲观。
关于TPU这一节的文档，在使用接口上跟GPU没什么区别，但它反复强调了加速问题。
由于TPU跑起来实在是太快，以至于你的代码可能没法高效的使用它的硬件性能，例如他说你单次的文件读取至少要达到100M，最好一张计算图直接运行他100个batch，别一个一个的往上提交任务。
文章里还介绍了一点，由于TPU在设计上就是单线程的，所以它的运行逻辑是非常可控的，coordinator可以非常准确的计算出跑完当前任务所需的时间，也就能够更精准的往TPU里喂任务，保证TPU始终处在高效运行的状态，减少整体任务的时间。但我相信这种优化是在用户端做的，比如一个熟练使用tf的人用各种trick来高效得到一个AlphaGo，而不是说你随手写个代码框架就能给优化成非常吊的样子。
