Skip to content

Commit 18bbf8a

Browse files
authored
[3.0]Fix higher_order_ad_cn link problem And SOT image is too big (#6728)
* [3.0]Fix higher_order_ad_cn link problem * fix sot imgage * fix images
1 parent 1cd89a6 commit 18bbf8a

File tree

4 files changed

+15
-15
lines changed

4 files changed

+15
-15
lines changed

docs/guides/paddle_v3_features/cinn_cn.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -94,7 +94,7 @@ python run_net.py
9494

9595
## 四、设计架构
9696
<center><img src="
97-
https://github.com/PaddlePaddle/docs/blob/develop/docs/guides/paddle_v3_features/images/cinn/cinn_design.png?raw=true" width="900" ></center>
97+
https://github.com/PaddlePaddle/docs/blob/develop/docs/guides/paddle_v3_features/images/cinn/cinn_design.png?raw=true" width="60%" ></center>
9898
<center> 图 1 CINN 整体架构 </center><br>
9999

100100
飞桨框架编译器(CINN, Compiler Infrastructure for Neural Networks)整体架构如上图所示,大体可以分为三个模块,分别是编译器前端、编译器后端和执行器部分。
@@ -111,7 +111,7 @@ https://github.com/PaddlePaddle/docs/blob/develop/docs/guides/paddle_v3_features
111111
#### c. 算子融合
112112
算子融合是编译器前端非常重要的一个功能,主要是将多个算子打包到一个子图中(对应为一个 FusionOp),交给编译器后端生成一个高效的硬件相关计算 Kernel。
113113
算子融合的本质是通过 IO 优化加速访存密集算子,如果我们将两个连续 Kernel 合并为一个 Kernel 调用,我们会减少中间变量的读写开销,因此在访存密集型的 2 个 Op 上,融合可以获取更高的性能。举个例子,如下图:
114-
<center><img src="https://github.com/PaddlePaddle/docs/blob/develop/docs/guides/paddle_v3_features/images/cinn/op_fusion.png?raw=true" width="200" ></center>
114+
<center><img src="https://github.com/PaddlePaddle/docs/blob/develop/docs/guides/paddle_v3_features/images/cinn/op_fusion.png?raw=true" width="15%" ></center>
115115
<center> 图 2 算子融合示例 </center><br>
116116

117117
我们有两个算子 Relu 和 Scale,因为两个算子都是 IO 密集型算子(计算复杂度不高)。正常情况下我们需要读取 A 和 B 一次,写 B 和 C 一次。但是对于融合之后的 Kernel(右图)而言,我们只需要读取 A 和写 C 一次,这样我们通过算子融合可以取得更少的访存次数,在 IO 密集算子而言,可以极大提高性能。

docs/guides/paddle_v3_features/higher_order_ad_cn.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -205,5 +205,5 @@ print(H_y_x2_x2.shape)
205205
基于飞桨框架 3.0 为科学计算提供了高阶自动微分、编译优化、分布式训练能力支撑,提供了面向通用数理问题求解的赛桨 PaddleScience 以及专注于生物计算的螺旋桨 PaddleHelix 工具组件。为了更好地支撑 AI for Science 生态,飞桨对国内外主流开源科学计算工具进行了适配,并被国际主流的科学计算深度学习库 DeepXDE 唯一推荐。在与 NVIDIA 合作适配其 AI Physics 工具 Modulus 的过程中,飞桨利用其高阶自动微分与编译优化技术,成功完成了全量模型适配,实现了方程求解类模型性能的大幅优化,相比 Modulus 现有后端求解速度平均提升 71%。
206206

207207
<figure align="center">
208-
<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/develop/docs/guides/paddle_v3_features/images/higher_order_ad/ai4s.png" style="zoom:80%"/>
208+
<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/develop/docs/guides/paddle_v3_features/images/higher_order_ad/ai4s.png" style="zoom:40%"/>
209209
</figure>

docs/guides/paddle_v3_features/overview_cn.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -248,7 +248,7 @@ class RMSNorm(paddle.nn.Layer):
248248
249249
基于前期的工作积累,飞桨已开始积极探索科学智能(AI for Science)领域的相关工作。为了满足 AI for Science 任务的多样化需求,飞桨在框架层面实现了基于组合算子的高阶自动微分功能,并专门提供了针对科学计算的开发接口。此外,我们还实现了高阶优化器,如 LBFGS 等,以进一步提升科学计算的性能。在模型层面,我们成功研发了赛桨(PaddleScience)、螺旋桨(PaddleHelix)等系列开发套件,为科学计算提供了更为便捷、高效的解决方案。飞桨对国内外主流开源科学计算工具进行了广泛适配,如 DeepXDE、Modulus 等,并成为国际主流的科学计算深度学习库 DeepXDE 的默认推荐后端。在与 NVIDIA 合作适配 Modulus 的过程中,我们充分利用飞桨框架的高阶自动微分与编译优化技术,实现了方程求解类模型性能的大幅优化。相比 Modulus 现有的后端求解速度,我们的平均提升幅度达到了 71%。我们实现了物理信息网络(PINN)、傅里叶算子学习(FNO)等数据驱动、机理驱动以及数据机理融合的方法。这些方法在航空航天、汽车船舶、气象海洋、生命科学等多个领域都具有广泛的应用潜力,为科学研究和工程实践提供了有力的支持。
250250
251-
更多关于高阶自动微分和 AI for Science 的信息,请参考文档:[《高阶自动微分功能》](./high_order_ad_cn.md)。
251+
更多关于高阶自动微分和 AI for Science 的信息,请参考文档:[《高阶自动微分功能》](./higher_order_ad_cn.md)。
252252
253253
## 七、高扩展中间表示 PIR
254254

docs/guides/paddle_v3_features/sot_cn.md

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ unsupport_func(x) # raise error
3939
在新的 SOT 方案中引入了自适应打断机制来获得 100% 理论动转静成功率。在旧的动转静 AST 方案中,是以源码转写的方式对整图进行转写,当遇到无法静态化的 Op 时,AST 整图转写失败。新的 SOT 方案中,首先将源码转写的方式升级为了字节码转写,当遇到无法静态化的 Op 时,我们将整图切分为子图,并使用**字节码进行粘连**,以达到转写成功的目的。在自适应打断机制加持下,用户动态图编写可以更加随意,并在子图层面享受动转静和编译器加速。
4040

4141
<p align="center">
42-
<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/develop/docs/guides/paddle_v3_features/images/sot/sot_vs_ast.png" width="80%"/>
42+
<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/develop/docs/guides/paddle_v3_features/images/sot/sot_vs_ast.png" width="40%"/>
4343
</p>
4444

4545

@@ -48,23 +48,23 @@ unsupport_func(x) # raise error
4848
在新的 SOT 流程下,动转静是在字节码层面进行分析的,SOT 会先利用注册的 Python EvalFrame Hooker 获取到用户函数运行时的字节码和 PyFrame 上下文信息(包含了局部变量,参数等),然后使用内部实现的**字节码模拟执行器**来进行模拟执行,最后得到一个可以替换原来字节码的新 PyCodeObject 对象。模拟执行器会识别出用户函数中需要静态化的字节码和无法静态化的字节码,对于无法静态化的字节码使用打断功能会回退到动态图执行,对于可以静态化的字节码会生成一个静态图来进行替换。当第二次执行时,SOT 会先判断是否命中了上次转写的缓存,如果命中了缓存就可以直接获取上次转写的 PyCodeObject 重用。下图是整个 SOT 的执行流程。
4949

5050
<p align="center">
51-
<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/develop/docs/guides/paddle_v3_features/images/sot/sot_procedure.png" width="80%"/>
51+
<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/develop/docs/guides/paddle_v3_features/images/sot/sot_procedure.png" width="40%"/>
5252
</p>
5353

5454
## 三、框架架构
5555

5656
<p align="center">
57-
<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/develop/docs/guides/paddle_v3_features/images/sot/sot_framework.png" width="80%"/>
57+
<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/develop/docs/guides/paddle_v3_features/images/sot/sot_framework.png" width="50%"/>
5858
</p>
5959

6060

6161
上图展示了 SOT 的所有组件,针对一些名词和模块,这里进行一个简单的介绍:
6262

63-
### **一、EvalFrame Hooker 模块**
63+
### 3.1 EvalFrame Hooker 模块
6464

6565
Python 在 2016 年的 PEP523 提案支持了自定义回调函数,将默认的执行器替换为用户自定义的解释函数。这个机制结合子图 fallback 方案的需求,我们在 Paddle 的 Pybind 层暴露了 `paddle.core.set_eval_frame` 接口。
6666

67-
### **二、字节码模拟器(OpcodeExecutor)模块**
67+
### 3.2 字节码模拟器(OpcodeExecutor)模块
6868

6969
这个部分是 SOT 方案的核心,主要的功能是我们需要模拟获取到的 PyCodeObject,并进行动态和静态代码分离,因此字节码模拟器是将 Python 函数映射为新的 Python 函数的模块。对于不同的静态化程度的函数,**字节码模拟器**会将一个函数对应于下面几种可能的情况:
7070

@@ -79,7 +79,7 @@ Python 在 2016 年的 PEP523 提案支持了自定义回调函数,将默认
7979
- 支持子函数递归模拟。
8080
- 完备的字节码支持,完备的版本支持。我们支持 python3.8 - python3.12 的几乎 90%常见字节码模拟。
8181

82-
### **三、自适应子图打断模块**
82+
### 3.3 自适应子图打断模块
8383

8484
**对于控制流 If、For 依赖 Tensor 的场景,需要打断构图并静态化部分函数,子图打断能力是 SOT 能够达到近 100%成功率的核心组件。**
8585

@@ -90,19 +90,19 @@ Python 在 2016 年的 PEP523 提案支持了自定义回调函数,将默认
9090

9191
基于不同的场景我们设计了不同的异常传播途径和不同的处理逻辑。
9292

93-
### **四、Tracker、Guard、缓存模块**
93+
### 3.4 Tracker、Guard、缓存模块
9494

9595
子图 Fallback 的整体实现可以认为是将用户函数原始字节码转换为新的字节码,**为了避免每次传入相同输入都会重新触发开销昂贵的字节码转换操作,我们需要增加缓存机制来复用之前转写过的代码,实现 JIT 的效果。**
9696

9797
但并不是任何字节码成功转换一次后第二次都是可以直接复用的,因为我们字节码的转换是基于 Frame 的初始状态进行模拟执行得到的,也就是说**转换后的字节码强依赖于 Frame 的初始状态**。当初始状态发生改变,最后转换后的字节码很有可能发生改变,因此我们需要一种机制来根据 Frame 初始状态来判断缓存过的字节码是否有效。这种转换复用的机制我们称为 Guard 函数,而 Guard 函数生成依赖字节码模拟过程中记录的每个模拟变量的 Tracker。
9898

99-
### **五、副作用处理模块**
99+
### 3.5 副作用处理模块
100100

101101
**SideEffect 是指代码执行过程中除了函数返回值之外,还对调用方产生了额外的影响,比如修改全局变量、修改可变的共享变量等。**
102102

103103
在模拟执行过程中,我们的代码是在虚拟环境下执行的,在该过程中不应该也不会对真实环境进行修改。而如果用户代码产生了 SideEffect,我们需要在生成的代码里反映出相应的 SideEffect,即在字节码生成步骤中增加 SideEffect 的处理部分。副作用模块就是专门记录并处理副作用正确性的功能模块。
104104

105-
### **六、StatementIR 模块**
105+
### 3.6 StatementIR 模块
106106

107107
**StatementIR 是 Paddle 动转静模块与子图 FallBack 的一个『中间桥梁』,它达到了动转静复用的目的。**
108108

@@ -121,7 +121,7 @@ SOT 方案相比于 AST 方案有如下的优势:
121121

122122
## 五、开始使用
123123

124-
### 使用 SOT 模式(默认模式)
124+
### 5.1 使用 SOT 模式(默认模式)
125125

126126
目前 SOT 模式是动转静的默认转写模式。用户只需要使用默认的 paddle.jit.to_static 就可以,下面是一个 SOT 动转静的使用样例:
127127

@@ -165,7 +165,7 @@ Tensor(shape=[], dtype=float64, place=Place(gpu:0), stop_gradient=True,
165165
54.16428375)
166166
```
167167

168-
### 使用 AST 模式
168+
### 5.2 使用 AST 模式
169169

170170
如果确定自己的代码完全可以静态化,用户可以手动打开 AST 模式,通常 AST 模式成功率会更低,但是调度开销会更小,同时支持部署推理。
171171

0 commit comments

Comments
 (0)