已关闭
[Bug-Report|缺陷反馈]: 优化机会优先级问题清单 #2300
benjamin920101创建于 7月23日关闭于 7月27日
7月23日 修改了issue 的描述
7月23日 修改了issue 的描述
7月23日 修改标题为 “[Bug-Report|缺陷反馈]: Extract shared CMake sample boilerplate into common module”,原标题为“[Bug-Report|缺陷反馈]: ”
7月23日 修改标题为 “[Bug-Report|缺陷反馈]: Extract shared CMake sample boilerplate into common module”,原标题为“[Bug-Report|缺陷反馈]: ”
7月23日 修改了issue 的描述
7月23日 修改标题为 “[Bug-Report|缺陷反馈]:Extract shared CMake sample boilerplate into common module”,原标题为“[Bug-Report|缺陷反馈]: Extract shared CMake sample boilerplate into common module”
7月23日 修改标题为 “[Bug-Report|缺陷反馈]:Extract shared CMake sample boilerplate into common module”,原标题为“[Bug-Report|缺陷反馈]: Extract shared CMake sample boilerplate into common module”
7月23日 修改标题为 “[Bug-Report|缺陷反馈]: 优化机会优先级问题清单”,原标题为“[Bug-Report|缺陷反馈]:Extract shared CMake sample boilerplate into common module”
7月23日 修改标题为 “[Bug-Report|缺陷反馈]: 优化机会优先级问题清单”,原标题为“[Bug-Report|缺陷反馈]:Extract shared CMake sample boilerplate into common module”
陈思
7月24日 评论:
7月24日 评论:
您好,感谢反馈。改动面较大,需要进一步评估,转为需求详细设计并实现,欢迎持续关注


songkai111
7月27日 评论:
7月27日 评论:
- 针对该问题,我们已提供add_all_module_sources函数,这样可以将一个算子的CMakeLists.txt数量调整为一个文件+一行代码
- build.sh已经按要求拆分
- 算子修改量较大,收益较小,因此评估不做重构
- 目前缓存优化能力统一使用cmake公共仓配置,单仓不做配置


7月27日 关闭了 issue
7月27日 添加了label:resolved
1. CMakeLists.txt 大规模重复,应模板化
717 个 CMakeLists.txt 中,仅前几组重复度就有 49、45、17、16、14... 个文件完全逐字节相同(md5 一致)。每新增一个算子就要手动复制一份几乎相同的构建脚本,任何构建规则变更都要改几十上百处,极易漏改。
→ Issue 建议:抽取成一个 CMake 函数/宏(如
add_math_op(NAME log)),217+ 个重复文件替换成一行调用,可减少数千行冗余配置。2. build.sh 是 1775 行的单体脚本,35+ 个函数全部塞在一个文件里
承担 build/test/example/package/clean 等所有职责,难以单独测试和维护,改一处容易影响其他流程。
→ Issue 建议:按职责拆分为
scripts/build_lib.sh、build_ut.sh、build_example.sh等,由 build.sh 统一调度。3. 算子级 tiling 文件高度同构但未抽象
抽查 log/floor/ceil/rsqrt/neg/sign/trunc 的
*_tiling_arch35.cpp,行数都在 140~220 行区间,diff 显示 floor 与 ceil 的头文件引入、workspace 计算(ASCEND_WORKSPACE = 16777216)、OP_KEY 常量定义等模板代码几乎一致,只是算子名替换。而 top_k_v2 这类复杂算子的 tiling 文件却高达 2445 行,体量差异悬殊。→ Issue 建议:为"简单 elementwise 类"算子提取公共 tiling 基类/代码生成模板,减少样板代码;同时给 top_k_v2 等超大文件做模块拆分复审。
4. 编译优化选项比较保守
CMakeLists.txt里 BUILD_MODE 只在 -O2/-O3 时才特殊处理,默认走-O2,没有看到 LTO、-march=native/目标架构特化,或ccache/sccache加速增量编译的配置痕迹。对于这种有 4700+ cpp 文件、频繁全量重编的项目,构建时间本身就是可优化项。→ Issue 建议:评估引入 ccache + Ninja 并行构建,评估 Release 下是否可开 LTO。