Update design.md

PaddlePaddle · May 10, 2022 · fd94966 · fd94966 · paddle-bot-old · May 10, 2022
1 parent 2f5ba69
commit fd94966
Showing 1 changed file with 5 additions and 5 deletions.
diff --git a/docs/design/phi/design.md b/docs/design/phi/design.md
@@ -1,5 +1,5 @@
 
-飞桨高可复用算子库 PHI (Paddle HIgh reusability operator library)，或者我们也成为函数式算子库，支持组合式算子功能复用、Primitive算子内核复用、插件式硬件加速库复用。针对飞桨框架原算子库存在的算子接口不清晰、算子复用成本较高、调用性能不够快的问题，我们重构了飞桨框架的算子库，设计了灵活、高效的函数式算子库 Phi，可以通过对函数式算子接口组合调用的方式实现新算子。新算子库提供了 200 余个跟 Python 开发接口保持一致的 C++ 运算类 API，以及近500个可供组合调用的前、反向函数式算子内核 Kernel，可大幅降低框架原生算子和自定义算子的开发成本。新算子库支持Primitive API方式开发算子内核，可支持不同硬件（比如GPU和XPU）的算子内核复用。新算子库支持以插件方式接入硬件（比如NPU）的加速库，实现低成本复用硬件加速库。
+飞桨高可复用算子库 PHI (Paddle HIgh reusability operator library)，或者我们也称为函数式算子库，支持组合式算子功能复用、Primitive算子内核复用、插件式硬件加速库复用。针对飞桨框架原算子库存在的算子接口不清晰、算子复用成本较高、调用性能不够快的问题，我们重构了飞桨框架的算子库，设计了灵活、高效的函数式算子库 Phi，可以通过对函数式算子接口组合调用的方式实现新算子。新算子库提供了 200 余个跟 Python 开发接口保持一致的 C++ 运算类 API，以及近500个可供组合调用的前、反向函数式算子内核 Kernel，可大幅降低框架原生算子和自定义算子的开发成本。新算子库支持Primitive API方式开发算子内核，可支持不同硬件（比如GPU和XPU）的算子内核复用。新算子库支持以插件方式接入硬件（比如NPU）的加速库，实现低成本复用硬件加速库。
 
 > 本文档撰写于phi架构基本成型之时（2022年2月），仅代表该时间点的基本设计形态，可能和最新形态有细微差别；此外，在2.3版本发布的phi算子库仍然处于初期形态，后续仍然需要持续建设并完善，设计上也有可能调整。
 
@@ -50,7 +50,7 @@ Paddle 2.0发布之后，多次收到内外部用户反馈动态图在小模型C
 
 ### 1.1.3 自定义算子的易用性提升需求
 
-2021年初上线的新自定义C++外部算子体系，在接口与函数编写的层面上，用法已经比较直观了，但是因为我们缺少基本运算的C++ API体系，事实上，在实现具体的自定义Op运算逻辑时，一些基础的加减乘除及矩阵运算都仍然需要重新实现一遍，不能复用Paddle已有的、经过优化的基础运算，因此一些复杂运算的外部开发成本仍然是比较高的。而要想复用Paddle内部的基础运算，有赖于的Op体系升级为函数式，并整理对应的C++ API体系才能解决。
+2021年初上线的新自定义C++外部算子体系，在接口与函数编写的层面上，用法已经比较直观了，但是因为我们缺少基本运算的C++ API体系，事实上，在实现具体的自定义Op运算逻辑时，一些基础的加减乘除及矩阵运算都仍然需要重新实现一遍，不能复用Paddle已有的、经过优化的基础运算，因此一些复杂运算的外部开发成本仍然是比较高的。而要想复用Paddle内部的基础运算，依赖于的Op体系升级为函数式，并整理对应的C++ API体系才能解决。
 
 ### 1.1.4 共建训推一体算子库，降低推理算子维护成本
 
@@ -146,7 +146,7 @@ paddle/phi
 	- 该部分可能反向依赖框架的DeviceContextPool等实现，所以单独管理
 	- 在该类API上，训练和预测也可能是不同的
 - `common`：phi内部及phi api目录均要使用的数据结构，这些数据结构既不属于phi core，也不属于api目录
-- `core`：phi内部会有一些自己需要的，公用的模块实现，比如基础DenseTensor、，kernel注册及管理模块
+- `core`：phi内部会有一些自己需要的，公用的模块实现，比如基础DenseTensor、kernel注册及管理模块
 - `backends`：backends中组织后续需要为各个后端的新增的数据结构，比如CPUContext、GPUContext等
 	- core中放置对于算子库来讲通用的基础数据结构，而特定后端的专用数据结构不放在core中，且依赖关系严格保证backends依赖core，但core不能依赖backends
 	- 例1：Context如果有基类，则在core中，而继承的CPUContext在backends/cpu中，GPUContext在baackends/gpu中
@@ -626,9 +626,9 @@ void Scale(const Context& dev_ctx,
     - 基本流程如下图：
         - ![图片](http://bos.bj.bce-internal.sdns.baidu.com/agroup-bos-bj/bj-2aafdb051eaea7120bdf9604eb738029dcd3162a)
     - 这种方式存在的性能问题已经被torch自身认识到，所以torch也在做算子库重构，但是积重难返，他们重构也并未对此问题从根本上解决，只是减少了一些redispatch的层数，我们不能一味模仿竞品自身都认为有问题的设计
-- 为什么第一个参数需要是DeviceContext？为什么不能不传？
+>- 为什么第一个参数需要是DeviceContext？为什么不能不传？
     - phi kernel要求是纯函数形式，即函数内使用的变量均通过参数传入，或者在函数内部创建，不允许在函数内部使用全局单例，为了适配多样的kernel需求，像DeviceContext这种存储上下文信息的参数是必要的
-- 为什么需要两个模板参数？
+>- 为什么需要两个模板参数？
     - 为了方便设备无关kernel的复用，假如我们要实现一个傅里叶变换fft kernel，假设这个kernel能够使用基础kernel组合得出，
 
 #### 2.3.4.3 Kernel实现