江苏龙网

  1. 首页 > 资讯 > 科技 > >

[]深度学习框架的灵魂( 三 )


[]深度学习框架的灵魂
文章图片

文章图片

Tensorflow刚出来的一年多的时间 ， 表现都是比较糟糕的（崩溃、慢、不支持多机） ， 但全球开发者已经投降了：好了 ， 就是它了 ， 别人再做框架是没戏了 ， 即使现在比较糟 ， 但以Google的实力 ， 一定可以改好 。这就是品牌背书的优势 。
看Tensorflow代码的感觉是 ， 看局部（每个C++文件 ， 每个类）都无可挑剔 ， 但拼到一起构成一个系统就各种不协调 。Tensorflow团队尽管有精神领袖JeffDean ， 但JeffDean对框架的深入思考应该是极少的 ， 其实还是一群精英工程师各自为战 。我怀疑 ， 世界上没有任何一个人掌握Tensorflow代码的全貌 。
Tensorflow广为诟病的还有API的混乱及摇摆不定 ， 最近被“民意”裹挟 ， Keras竟然成了钦定API,这显然不是出于某个一致的设计 。给人一种边研发边构思 ， 正如一些美剧 ， 一边播放一边编剧 ， 甚至根据观众反馈来改变下一季的剧情 。如果回到最早Tensorflow那篇论文 ， 会发现其实那篇论文有价值的内容不多 ， 写论文时整个团队对问题的思考还停留在表面 ， 看上去是“占坑”之作（当然 ， Op/kernel,graph,variable ， send/recv ， 图优化 ， placement这些都是留下来了） 。
Tensorflow对一些新思路的支持不够及时 ， 实现了复杂的分布式支持 ， 但用户只想用Horovod ， 研究员设计了mesh-tensorflow,gpipe ， 也一直游离在主干代码之外 ， 迟迟没有官方的RDMA支持 。
总之 ， Tensorflow是系统工程师主导的项目 ， 体现了精湛的工程能力 ， 对大型项目的娴熟掌控 ， 但对深度学习系统本身的深入思考以及用户真实需求的挖掘这两样最重要的东西被忽视了 。患了“大而无当”的毛病 ， 系统太过庞大 ， 算法科学家自身无力推进去新的思路 ， 可能需要很多人协调 ， 删除一些不好的设计也可能遇到阻力 。
PyTorch：
PyTorch的前身Torch都有十几年的历史了 ， 在Python接口前 ， 有一段时间基于Lua编程 。与Tensorflow由系统工程师主导不同 ， PyTorch由算法科学家主导 ， 甚至可以认为大型C++项目不在他们的舒适区 ， 很多底层接口还是C语言实现 ， 直到最近 ， 才开始做现代C++的重构 。
也许是因为这些因素 ， PyTorch很忠实的履行了“如无必要 ， 勿增实体”的奥卡姆剃刀原则 ， 项目伊始基本上不考虑分布式需求（Tensorflow搞了复杂的分布式又如何 ， 用户还不是去用Horovod） ， 也不做静态图编译优化 ， 只考虑单设备优化 ， 大大简化了问题 。
Tensorflow的API超级复杂 ， 用户相当于要学习一门新的语言 ， PyTorch将深度学习与Python语言深度整合 ， 充分利用Python语言构造 ， 极端情况下 ， 用户只需要numpy ， 好的 ， PyTorch为numpy提供GPU支持 ， 再实现autograd支持 ， 这就完美支持了算法科学家的需求 。
当PyTorch崛起后 ， Tensorflow团队应该会有一丝后悔：原来大部分用户需要的如此至少 ， 当初苦心孤诣引入的各种技术全无用武之地 。以PyTorch为例 ， 很容易给人一种感觉：wow ， 深度学习框架如此简单 。当然为了运行效率 ， PyTorch需要在内存管理上做复杂的支持 ， 另外Python指令流和底层kernel计算流之间的异步执行 ， 本质上是CUDAkernel计算时间足够长 ， 就可以掩盖掉缓慢的Pythondispatcher的开销,某些情况下效率和Tensorflow不分伯仲 。
当然为了追求效率 ， 开启JIT优化仍是有效的 。算法科学家对大型工程的能力欠缺 ， 但对深度学习算法科学家的需求体会的最深 ， 对需求把握的最准确 ， 核心灵魂就是务实 ， 贴心 。天下没有免费的午餐 ， 有些困难的问题是迟早要面对的 。
PaddlePaddle：


推荐阅读


上一篇：『』设计干货：到底什么是交互设计？

下一篇：『』苹果廉价iPhone或将到来，最全配置信息汇总，香吗？