标签：
没有为什么，作为一个Hacker，看不惯BVLC Caffe中的诸多设计弊病。
然后就推翻重写了，在架构上做了诸多调整。
Caffe的cmake方案相当的low，各种库乱飞也是弊病。
Dragon继承了Caffe-Windows的3rdparty方案做法，保持了Linux/Windows的同步Installation，
做到了真正的跨平台。
福利就是，十分钟装不好你可以打死我。
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的。
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设备分布式帮您美梦成真。
来张吐槽图：
本项目将作为作者的本科毕业设计，接下来的版本重心将是符号接口。
Schmidhuber大牛在ICML2015时说过：
真正运行AI代理的代码是非常简短的，甚至高中生都能玩转它。换句话说，不用有任何担心会有行业垄断AI及其研究。
任意的框架都会有其弊病，此时显然应该暴力推翻重写。OpenSource的意义正是如此。
标签：
原文地址：http://www.cnblogs.com/neopenx/p/5634098.html
