Dragon 0.1rc 发布

Posted 2020-08-02

Repo：https://github.com/neopenx/Dragon

为什么要使用Dragon？

没有为什么，作为一个Hacker，看不惯BVLC Caffe中的诸多设计弊病。

然后就推翻重写了，在架构上做了诸多调整。

Dragon的优势

1、安装快

Caffe的cmake方案相当的low，各种库乱飞也是弊病。

Dragon继承了Caffe-Windows的3rdparty方案做法，保持了Linux/Windows的同步Installation，

做到了真正的跨平台。

福利就是，十分钟装不好你可以打死我。

2、移除不必要的库

Jia总结了Caffe1的设计问题，其中一个致命的地方就是使用了太多3rdparty。

诸如Glog、GFlags这两个库，手写不超过300行，毫无意义。

另，Glog导出至Python后与PY的输出流冲突，需要实时flush，这个bug估计是永远不会修正了。

——————————————————————————————————————————

LMDB、LevelDB也是扯蛋，序列化数据库快是快，但是Data的I/O上明显是资源过剩了。

如果你监测下Caffe的二级IO方案，就会发现线程大部分时间在休眠。

另外，序列化DB的最大诟病在于无法做shuffle，目前已知shuffle可以在训练后期疯狂逃逸鞍点。

DeepLearning最不缺的就是计算资源，所以这俩库也是毫无意义。

——————————————————————————————————————————

至于HDF5，在DeepLearning里出现MATLAB就是一个笑话，移除它是必然的。

Caffe Model Zoo的生态圈里也是永远不存在HDF5的。

3、移除Caffe源生并行方案

Caffe现在的Parallell方案就是一个笑话，多GPU居然在使用层次树结构做Parameter Update。

这样会让次GPU延迟许久才能刷到主GPU，更好的方案应该是Parameter Server。

目前Dragon的Parameter Server方案还在测试ing。

因为Caffe的源生并行方案移除，目前BVLC Caffe那愚蠢的IO方案可以删掉一大半代码。

——————————————————————————————————————————

另外，非常感谢印第安纳大学的MPI-Caffe设备分布式方案，这点足以吊打MXNet、TensorFlow一流了。

在未来，设备分布式相当重要，随着集成式神经网络越来越庞大，比如Faster-RCNN那庞大的分支。

将单个庞大神经网络优化分布到多GPU上是个不错的主意。

许多人目前还在为手里的2x GTX980跑不了VGG16而头疼不已，这时候，MPI设备分布式帮您美梦成真。

来张吐槽图：

 

Dragon的未来

1、符号接口的引入

本项目将作为作者的本科毕业设计，接下来的版本重心将是符号接口。

2、深度学习框架永远不会垄断

Schmidhuber大牛在ICML2015时说过：

真正运行AI代理的代码是非常简短的，甚至高中生都能玩转它。换句话说，不用有任何担心会有行业垄断AI及其研究。

任意的框架都会有其弊病，此时显然应该暴力推翻重写。OpenSource的意义正是如此。