任务四：增强代码生成机制

[zrr1999]

任务四：增强代码生成机制

现有的代码生成功能较为单一，仍有许多改进空间，我们可以随着其他任务的完成，逐步完善代码生成模块。

具体任务待添加（预留序号175-200）

题目序号	字节码	出现次数	存在版本	认领人	PR

Generated by IssueTools

[yangguohao]

请问一下这个任务中的具体要求是什么呢，我看到之前的任务中有提到关于 GraphLayer 类中的 _generate_forward(self) 的方法，是这个类可能存在某些问题？或是功能不齐全需要改进吗？

[zrr1999]

请问一下这个任务中的具体要求是什么呢，我看到之前的任务中有提到关于 GraphLayer 类中的 _generate_forward(self) 的方法，是这个类可能存在某些问题？或是功能不齐全需要改进吗？

这个赛题最近好像要跟动转静那部分进行一些融合，可能具体内容要等明天PFCC会议问一问，明天 @gglin001 会介绍一下torchdynamo，还有@SigureMo 会介绍一下 PaddleSOT

[yangguohao]

好的

[yangguohao]

我看这个 fx 的活动还是和 SOT 还是两个分开的部分？

[gglin001]

我看这个 fx 的活动还是和 SOT 还是两个分开的部分？

我的理解是的, 是分开的部分, repo 和 paddle 的内部规划没有联系, 是一个纯社区的项目, 和 SOT 的目标也会有一些不同(不需要考虑 paddle 的动转静)

[yangguohao]

我的理解是的, 是分开的部分, repo 和 paddle 的内部规划没有联系, 是一个纯社区的项目, 和 SOT 的目标也会有一些不同(不需要考虑 paddle 的动转静)

好的，感谢回复。

[jzhang533]

我看这个 fx 的活动还是和 SOT 还是两个分开的部分？

是的，是分开的。只是，里面用到的技术很相似。

[yangguohao]

我看这个 fx 的活动还是和 SOT 还是两个分开的部分？

是的，是分开的。只是，里面用到的技术很相似。

您好，我还是想具体请教一下 SOT 和 fx 的不同之处在什么地方。我没有完全理解这两个方向的不同，还有就是这个代码生成机制是与 SOT 中的 PycodeGen 差不多的形式吗。

[SigureMo]

您好，我还是想具体请教一下 SOT 和 fx 的不同之处在什么地方。我没有完全理解这两个方向的不同。

PaddleSOT 与 PaddleFX 都在一定程度上借鉴了 TorchDynamo，TorchDynamo 采用了基于 PEP 523 的 eval frame 阶段来进行字节码转写，其转写方式依赖于模拟执行来收集信息，这一方案是 PaddleSOT 现阶段的方案，也是 PaddleFX 的方案

PaddleFX 的开发早于 PaddleSOT，甚至早期我们的 eval frame 也是借鉴了 PaddleFX（要感谢 @gglin001 大佬，但唯一有借鉴的只有这个）。PaddleFX 可以看作 TorchDynamo + TorchFX，相对于 TorchDynamo 部分，TorchFX 部分明显完成度更高些。但 PaddleFX 是一个纯社区项目，没有足够的人力支持，当然也没有足够的人力来进行方案设计（我觉得这一点非常重要，我们 PaddleSOT 每天有非常多的时间会用于讨论交流，实际写代码的时间占比其实很少），目前只能按照 Torch 的方案来走，目前基本 90% 以上是与 Torch 一致的，PaddleFX 为 PaddlePaddle 的 TorchFX 类似方案实现作出了原型验证。

PaddleSOT 早在 PaddleFX 开发之前就已经开始孵化了（应该在我入职之前很久就已经有想法了，详情未知），这是源于我们的内部需求的，PaddleSOT 的目标是增强动转静成功率，达到 100%，并且能在一些需要 Tensor 值的地方自动地打断子图，以解决部分动转静后的动静行为不统一的问题（详情见 https://github.com/PaddlePaddle/community/tree/master/pfcc/paddle-code-reading/symbolic_opcode_translator ）。PaddleSOT 的目标不是将 TorchDynamo 引入 PaddlePaddle，PaddleSOT 借鉴 TorchDynamo 方案只是手段而已，而且在历史上我们也有过方案一（4.25 PaddlePaddle/PaddleSOT@6a81140 之前的方案），目前的方案是方案二（可以理解为 TorchDynamo 方案），而且未来也可能转向方案三。从借鉴的程度上来看，PaddleSOT 除去早期主体方案调研之外，实际方案设计都是由我们内部讨论得出，虽然承认有部分借鉴，但是所有方案都是我们针对一点一点细节、各种各样 case 所精心设计的，代码上更是从零开始一点一点堆叠的。TorchDynamo 更多的是告诉我们「都需要做些什么」（比如 VariableTracker、Source、Guard、SideEffects 等机制），而「为什么要这么做」以及「怎么做」基本都是我们自己慢慢摸索的。

从使用到的技术上来看，PaddleFX 很大程度地实现了 TorchFX 部分和一部分的 TorchDynamo，PaddleSOT 实现了轻量的 TorchFX（SIR）和基本全部的 TorchDynamo（除去未实现的 SideEffects，主体机制基本已经全部实现，SideEffects 已经有方案，下周便会开始开发）。

从与 Paddle 的关系上来看，PaddleFX 大量借鉴了 Torch 的代码，显然是不可能合入 Paddle，而 PaddleSOT 是一定会合入 Paddle 主 repo 的，目前只是为了快速迭代而在独立 repo 中开发而已，预计最晚 8 月底就会合入吧（时间我不敢确定，但个人希望晚一点合入，为我们快速开发迭代带来了极大的便利）

还有就是这个代码生成机制是与 SOT 中的 PycodeGen 差不多的形式吗。

完全不同，前面也提到 PaddleFX 的 TorchDynamo 实现还差很多部分，你说的 PyCodegen 是 #57 刚刚实现的，本任务所说的是指 TorchFX 中 FXGraph 的 forward 代码生成，与 PyCodegen 完全不同，PaddleSOT 中没有完全对应的部分，因为 PaddleSOT 现阶段不会实现 TorchFX 那样的 IR（不代表以后不会，但现阶段是没有时间与精力去设计这个的）

另外不得不说 PaddleFX 为 PaddlePaddle 与 TorchDynamo + TorchFX 的方案集成有着重要的参考意义，早期在我入职之前和开发 PaddleSOT 之前那段时间也是在 PaddleFX 才学习到了 TorchFX 的方案，学习到了很多有趣的东西～

也许 @yangguohao 是想确认下参与 PaddleSOT 与「开源创新大赛·赛题一」之间的相关性？麻烦军哥 @jzhang533 确认下参与 PaddleSOT 的开源任务是否算是参与赛题一，如果算参与的话，是否有一个具体的完成标准，开发者可能比较关心这个

[yangguohao]

您好，我还是想具体请教一下 SOT 和 fx 的不同之处在什么地方。我没有完全理解这两个方向的不同。

PaddleSOT 与 PaddleFX 都在一定程度上借鉴了 TorchDynamo，TorchDynamo 采用了基于 PEP 523 的 eval frame 阶段来进行字节码转写，其转写方式依赖于模拟执行来收集信息，这一方案是 PaddleSOT 现阶段的方案，也是 PaddleFX 的方案

PaddleFX 的开发早于 PaddleSOT，甚至早期我们的 eval frame 也是借鉴了 PaddleFX（要感谢 @gglin001 大佬，但唯一有借鉴的只有这个）。PaddleFX 可以看作 TorchDynamo + TorchFX，相对于 TorchDynamo 部分，TorchFX 部分明显完成度更高些。但 PaddleFX 是一个纯社区项目，没有足够的人力支持，当然也没有足够的人力来进行方案设计（我觉得这一点非常重要，我们 PaddleSOT 每天有非常多的时间会用于讨论交流，实际写代码的时间占比其实很少），目前只能按照 Torch 的方案来走，目前基本 90% 以上是与 Torch 一致的，PaddleFX 为 PaddlePaddle 的 TorchFX 类似方案实现作出了原型验证。

PaddleSOT 早在 PaddleFX 开发之前就已经开始孵化了（应该在我入职之前很久就已经有想法了，详情未知），这是源于我们的内部需求的，PaddleSOT 的目标是增强动转静成功率，达到 100%，并且能在一些需要 Tensor 值的地方自动地打断子图，以解决部分动转静后的动静行为不统一的问题（详情见 https://github.com/PaddlePaddle/community/tree/master/pfcc/paddle-code-reading/symbolic_opcode_translator ）。PaddleSOT 的目标不是将 TorchDynamo 引入 PaddlePaddle，PaddleSOT 借鉴 TorchDynamo 方案只是手段而已，而且在历史上我们也有过方案一（4.25 PaddlePaddle/PaddleSOT@6a81140 之前的方案），目前的方案是方案二（可以理解为 TorchDynamo 方案），而且未来也可能转向方案三。从借鉴的程度上来看，PaddleSOT 除去早期主体方案调研之外，实际方案设计都是由我们内部讨论得出，虽然承认有部分借鉴，但是所有方案都是我们针对一点一点细节、各种各样 case 所精心设计的，代码上更是从零开始一点一点堆叠的。

从使用到的技术上来看，PaddleFX 很大程度地实现了 TorchFX 部分和一部分的 TorchDynamo，PaddleSOT 实现了轻量的 TorchFX（SIR）和基本全部的 TorchDynamo（除去未实现的 SideEffects，主体机制基本已经全部实现，SideEffects 已经有方案，下周便会开始开发）。

从与 Paddle 的关系上来看，PaddleFX 大量借鉴了 Torch 的代码，显然是不可能合入 Paddle，而 PaddleSOT 是一定会合入 Paddle 主 repo 的，目前只是为了快速迭代而在独立 repo 中开发而已，预计最晚 8 月底就会合入吧（时间我不敢确定，但个人希望晚一点合入，为我们快速开发迭代带来了极大的便利）

还有就是这个代码生成机制是与 SOT 中的 PycodeGen 差不多的形式吗。

完全不同，前面也提到 PaddleFX 的 TorchDynamo 实现还差很多部分，你说的 PyCodegen 是 #57 刚刚实现的，本任务所说的是指 TorchFX 中 FXGraph 的 forward 代码生成，与 PyCodegen 完全不同，PaddleSOT 中没有完全对应的部分，因为 PaddleSOT 现阶段不会实现 TorchFX 那样的 IR（不代表以后不会，但现阶段是没有时间与精力去设计这个的）

另外不得不说 PaddleFX 为 PaddlePaddle 与 TorchDynamo + TorchFX 的方案集成有着重要的参考意义，早期在我入职之前和开发 PaddleSOT 之前那段时间也是在 PaddleFX 才学习到了 TorchFX 的方案，学习到了很多有趣的东西～

也许 @yangguohao 是想确认下参与 PaddleSOT 与「开源创新大赛·赛题一」之间的相关性？麻烦军哥 @jzhang533 确认下参与 PaddleSOT 的开源任务是否算是参与赛题一，如果算参与的话，是否有一个具体的完成标准，开发者可能比较关心这个

谢谢回复。我的理解是: 所以 SOT 和 FX 同样都是借鉴了 TorchDynamo（主要是 Eval frame 的字节码转写），只是 SOT 将这一部分与之前 Paddle 已经完成的动转静结合起来了。除了这一点之外， Fx 所参考的 TorchFx 与之前的方案完全不同。

还有一些问题想交流一下: 1. TorchFx 也把 Dynomo 与之前的旧的 TorchFx tracer 结合了起来？2. 在捕获了子图之后生成 IR （也就是 Fx Graph，这一部分 PaddleFx 也在着手实现）？3. 我看到 Torch 在这之后还有一个 AOTAutograd 生成了一个 Fx Graph in ATen/Prim 的 IR，这一部分现在则没有考虑实现吗？

最后，题目的要求就是将列出的字节码重新转写生成 FX Graph Forward 中的 Python 代码吗？

[SigureMo]

除了这一点之外， Fx 所参考的 TorchFx 与之前的方案完全不同。

「之前的方案」是指什么？

TorchFx 也把 Dynomo 与之前的旧的 TorchFx tracer 结合了起来？

TorchFX 本身就有捕获组网的能力，即 symbolic trace，但无法处理控制流，TorchDynamo 是从字节码层面模拟执行，并将组网信息记录在 FX Graph 中，也即 Python 端 IR，也就是去掉了 trace 能力的 FX Graph，仅仅使用其数据结构，而没有使用运行时被动 trace，其 tracer 由「编译时」InstructionTranslator 承担，通过一条一条字节码来构建 FX Graph，主动将一条条 IR 塞到 FX Graph 中

而 TorchDynamo 解决控制流的方式就是：

• DDCF（Data Dependency Control Flow）就打断子图就好了
• 非 DDCF 直接继续模拟执行，自然有 Guard 来保证正确性

在捕获了子图之后生成 IR （也就是 Fx Graph，这一部分 PaddleFx 也在着手实现）？

没有捕获子图才生成 IR 一说，IR 是在模拟执行过程中一步一步收集的（Python 端 IR 等同于 FX Graph，也就是子图），如果你说 lower 到其他 IR 那确实是在整个子图都捕获之后

我看到 Torch 在这之后还有一个 AOTAutograd 生成了一个 Fx Graph in ATen/Prim 的 IR，这一部分现在则没有考虑实现吗？

是问 Paddle（PaddleSOT）还是 PaddleFX？不过至少这不在 PaddleSOT 现在的规划之内，关于 ATen/Prim 的 IR 的相关的事情我没有做过调研，没办法回答

最后，题目的要求就是将列出的字节码重新转写生成 FX Graph Forward 中的 Python 代码吗？

不是吧，当初出这个题目的时候还没考虑字节码那部分呢，这下面的字节码表格是自动生成工具出问题了吧？字节码与 FX Graph 没有一一对应关系，没有字节码直接转换到 FX Graph 一说，更没有字节转换到 Forward 的 Python 代码一说， @zrr1999 确认一下？

[zrr1999]

除了这一点之外， Fx 所参考的 TorchFx 与之前的方案完全不同。

「之前的方案」是指什么？

TorchFx 也把 Dynomo 与之前的旧的 TorchFx tracer 结合了起来？

TorchFX 本身就有捕获组网的能力，即 symbolic trace，但无法处理控制流，TorchDynamo 是从字节码层面模拟执行，并将组网信息记录在 FX Graph 中，也即 Python 端 IR，也就是去掉了 trace 能力的 FX Graph，仅仅使用其数据结构，而没有使用运行时被动 trace，其 tracer 由「编译时」InstructionTranslator 承担，通过一条一条字节码来构建 FX Graph，主动将一条条 IR 塞到 FX Graph 中

而 TorchDynamo 解决控制流的方式就是：

• DDCF（Data Dependency Control Flow）就打断子图就好了
• 非 DDCF 直接继续模拟执行，自然有 Guard 来保证正确性

在捕获了子图之后生成 IR （也就是 Fx Graph，这一部分 PaddleFx 也在着手实现）？

没有捕获子图才生成 IR 一说，IR 是在模拟执行过程中一步一步收集的（Python 端 IR 等同于 FX Graph，也就是子图），如果你说 lower 到其他 IR 那确实是在整个子图都捕获之后

我看到 Torch 在这之后还有一个 AOTAutograd 生成了一个 Fx Graph in ATen/Prim 的 IR，这一部分现在则没有考虑实现吗？

是问 Paddle（PaddleSOT）还是 PaddleFX？不过至少这不在 PaddleSOT 现在的规划之内，关于 ATen/Prim 的 IR 的相关的事情我没有做过调研，没办法回答

最后，题目的要求就是将列出的字节码重新转写生成 FX Graph Forward 中的 Python 代码吗？

不是吧，当初出这个题目的时候还没考虑字节码那部分呢，这下面的字节码表格是自动生成工具出问题了吧？字节码与 FX Graph 没有一一对应关系，没有字节码直接转换到 FX Graph 一说，更没有字节转换到 Forward 的 Python 代码一说， @zrr1999 确认一下？

@yangguohao 是的，这里的字节码表格应该是任务一的，这里具体的表格还没有添加，我一会修复一下

[yangguohao]

除了这一点之外， Fx 所参考的 TorchFx 与之前的方案完全不同。

「之前的方案」是指什么？

TorchFx 也把 Dynomo 与之前的旧的 TorchFx tracer 结合了起来？

TorchFX 本身就有捕获组网的能力，即 symbolic trace，但无法处理控制流，TorchDynamo 是从字节码层面模拟执行，并将组网信息记录在 FX Graph 中，也即 Python 端 IR，也就是去掉了 trace 能力的 FX Graph，仅仅使用其数据结构，而没有使用运行时被动 trace，其 tracer 由「编译时」InstructionTranslator 承担，通过一条一条字节码来构建 FX Graph，主动将一条条 IR 塞到 FX Graph 中

而 TorchDynamo 解决控制流的方式就是：

• DDCF（Data Dependency Control Flow）就打断子图就好了
• 非 DDCF 直接继续模拟执行，自然有 Guard 来保证正确性

在捕获了子图之后生成 IR （也就是 Fx Graph，这一部分 PaddleFx 也在着手实现）？

没有捕获子图才生成 IR 一说，IR 是在模拟执行过程中一步一步收集的（Python 端 IR 等同于 FX Graph，也就是子图），如果你说 lower 到其他 IR 那确实是在整个子图都捕获之后

我看到 Torch 在这之后还有一个 AOTAutograd 生成了一个 Fx Graph in ATen/Prim 的 IR，这一部分现在则没有考虑实现吗？

是问 Paddle（PaddleSOT）还是 PaddleFX？不过至少这不在 PaddleSOT 现在的规划之内，关于 ATen/Prim 的 IR 的相关的事情我没有做过调研，没办法回答

最后，题目的要求就是将列出的字节码重新转写生成 FX Graph Forward 中的 Python 代码吗？

不是吧，当初出这个题目的时候还没考虑字节码那部分呢，这下面的字节码表格是自动生成工具出问题了吧？字节码与 FX Graph 没有一一对应关系，没有字节码直接转换到 FX Graph 一说，更没有字节转换到 Forward 的 Python 代码一说， @zrr1999 确认一下？

除了这一点之外， Fx 所参考的 TorchFx 与之前的方案完全不同。

「之前的方案」是指什么？

TorchFx 也把 Dynomo 与之前的旧的 TorchFx tracer 结合了起来？

TorchFX 本身就有捕获组网的能力，即 symbolic trace，但无法处理控制流，TorchDynamo 是从字节码层面模拟执行，并将组网信息记录在 FX Graph 中，也即 Python 端 IR，也就是去掉了 trace 能力的 FX Graph，仅仅使用其数据结构，而没有使用运行时被动 trace，其 tracer 由「编译时」InstructionTranslator 承担，通过一条一条字节码来构建 FX Graph，主动将一条条 IR 塞到 FX Graph 中

而 TorchDynamo 解决控制流的方式就是：

• DDCF（Data Dependency Control Flow）就打断子图就好了
• 非 DDCF 直接继续模拟执行，自然有 Guard 来保证正确性

在捕获了子图之后生成 IR （也就是 Fx Graph，这一部分 PaddleFx 也在着手实现）？

没有捕获子图才生成 IR 一说，IR 是在模拟执行过程中一步一步收集的（Python 端 IR 等同于 FX Graph，也就是子图），如果你说 lower 到其他 IR 那确实是在整个子图都捕获之后

我看到 Torch 在这之后还有一个 AOTAutograd 生成了一个 Fx Graph in ATen/Prim 的 IR，这一部分现在则没有考虑实现吗？

是问 Paddle（PaddleSOT）还是 PaddleFX？不过至少这不在 PaddleSOT 现在的规划之内，关于 ATen/Prim 的 IR 的相关的事情我没有做过调研，没办法回答

最后，题目的要求就是将列出的字节码重新转写生成 FX Graph Forward 中的 Python 代码吗？

不是吧，当初出这个题目的时候还没考虑字节码那部分呢，这下面的字节码表格是自动生成工具出问题了吧？字节码与 FX Graph 没有一一对应关系，没有字节码直接转换到 FX Graph 一说，更没有字节转换到 Forward 的 Python 代码一说， @zrr1999 确认一下？

好的，谢谢解答。

[jzhang533]

麻烦军哥 @jzhang533 确认下参与 PaddleSOT 的开源任务是否算是参与赛题一，如果算参与的话，是否有一个具体的完成标准，开发者可能比较关心这个

中国软件开源创新大赛中赛题一的题目，是在组委会备案过的，详情请见：https://www.educoder.net/competitions/track2_2023_paddle 。所以，是要能够完成赛题一里列出的赛题要求的，这样才能走到比赛的评审环节。

评审环节，是需要答辩和评委评分的，尽管赛题当中并没有提及PaddleSOT项目，如果能够参与PaddleSOT的项目，并在答辩中向评委说明，我觉得算是加分项的。

paddlefx项目是我和gglin001做的一些尝试，我们确实没有足够的时间和精力投入到这上面。所以也是希望，大家可以在paddlefx里来玩儿，来练习和尝试，并最终能够通过PaddleSOT项目，把相关的技术引入到Paddle当中。