Add road map for code cleaning #1959
Conversation
| | | ||
| | +-----------------------------------------------+ | ||
| | | | | ||
| | | Put Value Dispatch/Gradient Merge Logic into | |
There was a problem hiding this comment.
What is "Value Dispatch"? and what is "Gradient Merge"?
| @@ -0,0 +1,92 @@ | |||
| # 为什么清理Paddle V2 API | |||
|
|
|||
| 目前Paddle的V2 API是一个实验性质的临时实现。我们使用这个V2 API实际上达成了Paddle API未来的样子。而当前这个API的实现非常粗糙，具有如下问题: | |||
There was a problem hiding this comment.
这句话有逻辑问题：
- API是interface，不是“实现”，所以v2 API“不是”一个“临时实现”。
- 实际上“达成了”未来的样子。到底是不是未来的样子？客观上和实际上有什么区别吗？
我理解这段话的意思是：
最近我们设计和实现了 v2 API。但是实现比较粗糙。
|
|
||
| 目前Paddle的V2 API是一个实验性质的临时实现。我们使用这个V2 API实际上达成了Paddle API未来的样子。而当前这个API的实现非常粗糙，具有如下问题: | ||
|
|
||
| * 当前实现使用Python反射调用了Paddle的原生网络配置API |
There was a problem hiding this comment.
什么是“原生API”？如果v1算原声，v2凭什么不算原声？
我理解这里想说的是：
v2 API 的实现调用了 v1 API。
而这个并非根本问题。根本问题是：
而我们准备放弃 v1 API及其实现。所以我们应该重新实现 v2 API，使其不需要调用 v1 API。
| * 这种代码很难继续维护，也很难添加自定义注释等等 | ||
| * Paddle使用了SWIG暴露Paddle的C++ API | ||
| * 使用SWIG有若干问题，请参考之前的讨论，[Why use C-API instead of SWIG](../multi_language_interface/00.why_plain_c.md). | ||
| * 简要来说，使用SWIG暴露Paddle API将Paddle强绑定在Python语言上，并且生成的Python代码不能方便的增加注释，且必须使用C++ 风格命名Python API。 |
There was a problem hiding this comment.
“强绑定”是个什么意思？怎么算强，怎么算不强？这样模棱两可的语言就不应该是一个严肃的技术人员说的。
我理解这里想表达的意思是：
使用 SWIG 有一些问题。请参见。。。 我们决定写一套C API，而不用SWIG。
| * Paddle使用了SWIG暴露Paddle的C++ API | ||
| * 使用SWIG有若干问题，请参考之前的讨论，[Why use C-API instead of SWIG](../multi_language_interface/00.why_plain_c.md). | ||
| * 简要来说，使用SWIG暴露Paddle API将Paddle强绑定在Python语言上，并且生成的Python代码不能方便的增加注释，且必须使用C++ 风格命名Python API。 | ||
| * V2 API『创造』了一个`Parameters`不存在于Paddle Core中的概念。这个概念需要转移到Paddle C++中。 |
There was a problem hiding this comment.
V2 API 没有创造什么，它也没有脑子，不能创造什么。是我们创造的。
我理解这里想说的是：
我们在设计 v2 API 的时候，引入了一个Paddle 的 C++ 代码中没有实现的概念 Parameters。当时为了实现快捷，我们将其实现为一个 Python class。但是为了提高代码的执行效率和可维护性，我们应该将其实现为一个 C++ class。
| * 简要来说，使用SWIG暴露Paddle API将Paddle强绑定在Python语言上，并且生成的Python代码不能方便的增加注释，且必须使用C++ 风格命名Python API。 | ||
| * V2 API『创造』了一个`Parameters`不存在于Paddle Core中的概念。这个概念需要转移到Paddle C++中。 | ||
| * Paddle不支持完全的『恢复训练』。`Parameters.save`只会保存所有参数值，不会保存动态学习率等优化信息。 | ||
| * Paddle写一个新的Layer特别复杂。 |
There was a problem hiding this comment.
Paddle不会写。是人写。
这里应该是：
为PaddlePaddle写一个新的layer很不容易：
| * V2 API『创造』了一个`Parameters`不存在于Paddle Core中的概念。这个概念需要转移到Paddle C++中。 | ||
| * Paddle不支持完全的『恢复训练』。`Parameters.save`只会保存所有参数值，不会保存动态学习率等优化信息。 | ||
| * Paddle写一个新的Layer特别复杂。 | ||
| * Paddle使用非常简单的Protobuf，每写一个Layer都要修改Protobuf定义。缺乏扩展性。 |
There was a problem hiding this comment.
Paddle不会使用，只能说Paddle的源码依赖protobuf。
英语单词只有在句首才首字母大写，所以不是Protobuf，而是protobuf。
我理解这里想说的是：
每增加一个新的layer，要为其定义一个对应的 protobuf message。我们希望能从layer的C++代码自动推导出这个message定义。
| * 由于Paddle更改了API的设计，但是也保留了向后兼容性。于是形成了多套API同时并存，且互相调用的关系。维护成本很高。 | ||
| * 无法完成多语言并存的需求。如果第三方开发者想支持Go语言，那配置解析的工作还需要重写一遍。 | ||
|
|
||
| 这些问题都是当前设计讨论的范畴，也是我们目前比较紧急的工作。 |
There was a problem hiding this comment.
这是设计文档。当然说的都是“设计范畴”的事儿。
作为一个设计文档，不是讨论紧急不紧急的地方。
这句话没有什么信息量。可以删了。
|
感谢您给PaddlePaddle贡献代码。由于Paddle V1/V2版本已不再维护，相关代码也已从develop分支上删除，因此关闭您的PR，欢迎您向Paddle最新版-Fluid贡献代码。 |
也许看这里更方便