现在很难想像，三年前的时候， TensorFlow 还没有发布。前几天看到大家重投了 TensorFlow 当年的白皮书（此白皮书非彼白皮书），突然想写这么几段感想。
在 TensorFlow 出来前，做 Deep Learning 最流行的还是用 @贾扬清 的 Caffe ，或者用 Alex Krizhevsky 的 cuda-convent ，或者跟我一样，用 CUDA 从下往上开始哼哧哼哧地写。
自己哼哧哼哧写出来的当然跑得最快了，各种小的优化技巧都能用上。但是 BP 一写错，各种调试技巧都得上，写得各种花哨，调得就得更风骚，好几周的时间也就报销了。 Caffe 好用些，但是如果用的不是单线 Layer 的模型，多接几个输入输出，就得各种魔改。
TensorFlow 出来这么多年，千好万好，可以写一本书。今天好的不谈，聊聊当时白皮书里说的，现在看来，都有哪些不靠谱吧（今天不吹 PyTorch / Caffe2）。
分布式执行
TensorFlow 设计的时候就考虑了分布式执行。 Tensor 可以从一个 GPU 发到另一个 GPU，一台机器发到另一台机器。似乎这样可以既支持模型并行运算，又可以支持数据并行运算。然而除去刚开始的时候 NVIDIA 的卡内存不够之外，现在每张卡动辄 32GiB 的内存，让大家都纷纷跑数据并行，并没有什么大得一张卡都装不下的模型参数非要几张卡 / 几台电脑之间倒中间的运算结果。最常用的就是 allreduce 一下把参数发给所有卡。这样看来，对于 Deep Learning ，照搬 Distributed Stream Processing 的设计做了挺多的无用功。
图优化
表示成计算图之后，很多优化都可以在上面做。TensorFlow 现在也加了挺多的图优化算法进去。然而有些优化算法并没有解决根本问题。比如它的内存优化算法，只是 hard-code 了一些便宜的运算节点，如果有这些运算节点存在就可以先删掉。一些根本上解决这个问题的算法（比如 https://arxiv.org/pdf/1708.06799.pdf ）并没来得及实现。
实现重复混乱
TensorFlow 的实现重复混乱有三个方面：
- 第一个方面， TensorFlow 的 Ops 实现繁多，有一些还带了版本号。从实际出发，这是由 TensorFlow 的上层设计决定的。每个计算节点能做哪些运算，并且能有效率，是靠下面的 Ops 实现支持的，如果用几个 Ops 来替代一个大的 Op ，效率并没有办法得到优化（大量的优化是发生在计算节点之下，而不是在计算图上）；
- 第二个方面， TensorFlow 的品牌包含了大量独立且重复的实现，比如 TensorFlow Eager 实现了一套自己的 tape ， Swift for TensorFlow 自己实现了一套自动化求导，TensorFlow XLA 定义了一套（按它自己的说法）更严格的 Op 系统（ComputationBuilder）；
- 第三个方面， TensorFlow 自己的 API 对于它支持的 Python / C++ / Java / Go / JavaScript 语言并不是平等的。很明显 C++ 是底层， Python 是最重要的上层接口。大量的 API 实现是在 Python 层，所以在 Java 或者 Go 的层面，方便的 API 比如 TensorFlow Eager ， Keras 用不上。
咦，你怎么没提 XXX ， YYY ， ZZZ？
上面挑的些刺大多数都是实现层面的东西。大家抱怨的，比如静态图不好调试啦， meta-programming （元编程）太难啦之类的问题，其实在 TensorFlow 最早的白皮书里面自己都有提（君不见， TensorFlow 发布之前各位大科学家调 Inception for TensorFlow 的实现也调了一个月呢）。 TensorFlow 也带了个 TensorBoard 来帮助大家花样调试静态图。从根本上来说， TensorFlow 设计之初想要达到的无痛跨机器，跨平台，花式优化，也只有静态图才能实现。要搞静态图只有两个方法，要么让大家元编程，要么搞个新语言，写个新的 IDE 让大家学（当然啦，也可以魔改 Python ， 比如 PyTorch + ONNX 做的那样）。
如果你挑刺觉得 TensorFlow 慢的话，有一些是解决不了的（假设你的 tensor 其实都是 scalar ，那跑个 TensorFlow 的图肯定不如自己写个解释器跑得快），但是大部分都可以新写个 Op 搞定。
说到底， TensorFlow 毕竟只是 Google 的第二套 Deep Learning Framework 的实现（DistBelief 大家还没见真身就被干掉了），学学免费代码，强身健体，也是挺好的呀。
