启动这个项目时的一些线下讨论的概要

[jzhang533]

在关注了一段时间torchdynamo 和 torch.fx项目后，我们一直在想是不是有可能在paddle里也实现类似的技术。
基于这样一个简单的POC： https://github.com/jzhang533/mydynamo/blob/main/paddle_fx_poc.py
@jzhang533 和 @gglin001 我们做了一些讨论，所以启动了这个项目。
下面简单记录了讨论的概要：

trace的实现方案以及评估是否需要对paddle codebase做改动。

Proxy 部分有可能从 paddle.fluid.core.eager.ops / paddle._C_ops 部分下手吗? 对这些 api 加一个 proxy;
或者有可能在外部实现一个 对 paddle tensor 的类 torch_function 功能吗?

第一种方式确实有好处，是可以直接trace到C ops，而不只是python API，但要对paddle codebase有不少的改动；第二种方式，实现一个类似__torch_function__的协议，应该也可行，但同样要对paddle codebase有不少改动，可以参考NEP18：https://numpy.org/neps/nep-0018-array-function-protocol.html。

所以现在基本的想法，还是按现在的方式，对paddle的一批python API做monkey patch（或者叫hijack），先能实现稍微完善的trace功能，然后试着把paddle python IR通过IR变换及IR lowering，能够让其在其他的后端上来运行（比如TRT，或者其他的后端上）。 这样能验证这个做法是可行，而且有好处的。

在不修改 paddle codebase 的情况下 做一些 patch 实现(也许是没有意义的, 最终还是需要 paddle 直接支持这些协议 )。但为了能先把项目跑起来，我们可以先用out-of-tree的方案，做完后，再回过头来看，通过改动paddle codebase来实现更好的trace的技术方案。

项目的基础设施

• CI 部分：初期先用github action来搭建，等跑一段时间，再寻找飞桨的资源的支持。
• repo 放在哪里：可以不放在paddlepaddle组织下，所以我们有了这个：https://github.com/PFCCLab。
• 即时讨论的平台：, 比如 slack, 微信对历史记录支持不好。我们可以用github discussion区，应该够用了。
• 参与者的讨论：Run起来后，我们可以弄一些非定期的会议。
• 如果直接使用torch的代码是否有问题： 这个工程将不可避免的借鉴 torch。如果我们用到了，需要很清晰的声明原始的出处。