功能名称: (填写任务的名称, 在 Paddle 中实现 Common Subexpression Elimination(公共子表达式删除)的图优化 pass)
开始日期:(填写提交时候的日期,YYYY-MM-DD)
RFC PR:PaddlePaddle#33333
GitHub Issue:PaddlePaddle#35993
总结¶
一段关于该功能的解释。
动机¶
我们为什么要这样做?它支持哪些用例?预期的结果是什么?
使用指南级别的说明¶
解释这个 rfc,就好像它已经包含在 PaddlePaddle 中,而且你正在教一个 PaddlePaddle 用户。
这通常意味着。
引入新的命名概念。
解释该功能能够实现什么(提示:用例子来思考)。
如果适用,提供错误信息样本、废弃警告或迁移指导。
对于新功能的 RFC,这部分应该提供一个以实例为导向的介绍,并具体解释其影响。
参考文献级别的说明¶
这是 RFC 的技术部分。对这个设计进行足够详细的解释,即
它与其他功能的交互是清楚的。
合理地清楚该功能将如何实现。
通过实例剖析 corner cases。
该部分应该回到上一节给出的例子,并更充分地解释详细的建议如何使这些例子发挥作用。
缺点¶
为什么我们不应该这样做?
理论依据和替代方案¶
为什么这个设计在可能的设计思路中是最好的? 还有哪些设计被考虑过,不选择这些设计的理由是什么? 不这样做的影响是什么?
现有技术¶
讨论现有技术,包括好的和坏的,与本 rfc 有关的。可以包括以下几个例子。
这个功能在其他深度学习框架中是否存在,讨论他们的社区所做的实验?
对于社区建议。这个功能是否由其他社区完成,他们的经验是什么?
对于其他团队来说。我们可以从其他社区所做的事情中吸取什么教训?
论文。是否有任何已发表的论文或帖子来讨论这个问题?如果你有一些相关的论文可以参考,这可以作为一个更详细的理论背景。
如果没有先例,那也没关系–无论你的未来的可能性想法是全新的还是从其他语言改编的,对我们来说都是有趣的。
请注意,虽然其他深度学习框架的先例是某种动力,但它本身并不能成为 RFC 的动力。也请考虑到 PaddlePaddle 有意与其他深度学习框架有所区别。
未解决的问题¶
在合并前,你希望通过 RFC 程序解决设计中的哪些部分?
在功能稳定前,你希望通过实现这个功能来解决哪些部分的设计问题?
你认为哪些相关问题超出了本 RFC 的范围,可以在未来独立于本 RFC 的解决方案来解决?
未来的可能性¶
想一想你的 RFC 的自然延伸和演变,以及它将如何全面影响项目。试着把这部分作为一个工具,在你的 RFC 中更全面地考虑与框架所有可能的互动。还要考虑这一切如何与项目和相关的子团队的路线图相适应。
这也是一个 “倾倒想法 “的好地方,如果这些想法超出了你所写的 RFC 的范围,但又与之相关。
如果你已经尝试过,但想不出任何未来的可能性,你可以简单地说,你什么都想不出来。
请注意,在未来可能性部分写下一些东西并不是接受当前或未来 RFC 的理由;这种说明应该放在本篇或后续 RFC 的动机或理由部分。该部分只是提供额外的信息。