PR types

others

PR changes

others

Description

1. 背景：

   • Paddle现在面临增量编译耗时非常长，改一些不相关的cmake代码或者简单的代码，甚至在cmake加一行空格，phi目录下的所有文件都会重新编译，约30min(不同机器可能有差异)，主要原因是cmake代码不规范，此PR用来优化phi在增量编译中存在的问题。

2. phi增量编译存在的问题：

   • phi作为独立编译模块，理论上phi目录下的所有符号都应该编译到libphi.so中，但是phi/kernels/ops/compat/*.cc文件并没有编译在phi中，而是在paddle/fluid/operators/generator/中编译，故将这些文件放在这fluid目录下更加合理，也是导致phi重新编译的原因之一

   • phi/kernels/fusion/下面有多个通过一些.py文件生成大量.cu文件的操作(约150个)，cmake写法都是通过execute_process生成，每次cmake构建阶段都会重新生成，时间戳发生变化，导致phi下这些kernel文件都会重新编译(约20min)，也是增量编译耗时过长的原因，应设置tmp文件配合copy_if_different或者用add_custom_command，add_custom_target命令封装在make阶段编译进行优化。

   • 不仅仅是phi/kernels目录，往往改了很简单的文件，phi基本上都会从0开始编译，主要原因是phi/CMakeLists.txt/下调用了phi.cmake中的generate_unify_header函数，此函数中使用了一些string(replace xxx)操作导致cmake阶段检测到phi下边的文件几乎都有变化，故需要使用更加规范的cmake代码进行重构

   • 还有一些其它地方也是类似于生成代码的逻辑都会在增量编译存在这个问题，需要添加合适的跳过机制

3. 收益：

   • 本地测试(a100机器，cpu核心数159)，增量编译可以受益约15min，p40收益约30min，不同机器可能有差异

   • CI上也普遍存在这个问题，优化后CI配合ccache也有较大收益

   • 优化之后，只有改phi或者common(phi依赖基础组件common)中的文件，phi才会重新编译(且只编译phi目录下改动的某个.cc文件)，若改了phi依赖的库文件，只会重新Linking CXX shared library libphi.so，不会重新编译phi，符合预期

4. To do

   • fluid等其它目录也存在这样的问题，此PR之后优化fluid目录

   • 添加cmake代码相关监控

Pcard-67010