作为一名西南石油大学计算机科学与技术专业的大三学生，我有幸带着_conv_forward算子优化的实践成果，站上了2024开放原子开发者大会暨首届开源技术学术大会的舞台。这次分享不仅是对自己一段技术探索的总结，更是在开源技术交流中汲取经验、碰撞思维的珍贵经历，在此也想把这次优化的思路、实践和心得整理出来，和各位技术同行交流探讨。
我的技术探索始终围绕着并行计算、集群优化和硬件架构挖掘展开，日常深耕超算与并行计算领域，也在各类国产CPU并行应用挑战赛、ASC超算竞赛中积累了不少工程实践经验，从PCG算法调优、海洋模型算子移植到地震波模拟软件的MPI通信优化，这些经历让我对“性能优化”有了更具象的理解——优化从来不是单一维度的调整，而是对代码、硬件、通信的全方位打磨，而这次_conv_forward算子优化，正是一次全新的尝试。
本次_conv_forward算子优化的仓库地址也同步开源：https://gitee.com/YRemmmm/teco-final
一、核心优化方案：从细节入手，榨取算子性能
针对_conv_forward算子的性能瓶颈，我们从参数、存储、逻辑判断、代码冗余四个核心维度制定了优化方案，每一步优化都围绕“减少访存压力、提升计算效率、降低通信等待”的核心目标展开，让算子在硬件架构下的执行效率最大化。
2.1 参数微调：适配硬件的基础调优
参数是算子运行的基础，不合理的参数设置会直接导致硬件资源利用率低下、计算冗余等问题。本次优化中，我们对算子的核心运行参数进行了针对性微调：
- 对块大小相关参数做限制，设置
min_block_f=MIN(F,40)、max_block_f=MIN(F,128)，让块大小适配硬件的计算能力，避免因块过大导致的资源抢占，或块过小带来的计算碎片化； - 调整SPM（片上存储）使用阈值，将
max_used_spm_size在原有基础上增加1024，合理释放片上存储资源，减少因存储不足导致的外部访存，降低访存延迟。
参数微调的核心是“适配”，结合硬件的架构特性和算子的计算逻辑，让每一个参数都能贴合实际运行场景，为后续的优化打下基础。
2.2 暂存常用：减少重复访存，提升数据复用率
访存慢是算子性能的重要瓶颈之一，而_conv_forward算子在执行过程中，存在大量重复读取常用数据的情况，这无疑增加了访存压力。为此，我们设计了常用数据暂存策略，通过开辟临时缓冲区，将高频使用的计算数据、索引信息暂存起来，实现数据的一次读取、多次复用。
在代码实现中，我们定义了多个缓冲区变量和数组，涵盖了数据尺寸、索引位置、矩阵计算长度等各类常用信息：
- 开辟
buffer1、buffer_tmp、buffer_mul等缓冲区，存储数据类型大小与计算维度的乘积，快速获取数据存储所需空间； - 定义
buffer_st_Hi、buffer_st_Wo、buffer_howo_al1等数组，暂存卷积计算中高度、宽度方向的起始/结束索引、矩阵计算长度等核心信息； - 计算并暂存
RSM等存储尺寸参数，提前规划片上存储的使用，避免运行过程中重复计算导致的效率损耗。
同时，在卷积的行列遍历、数据读取过程中，直接调用暂存的缓冲区数据，例如x_mm=buffer_x_mm[r*S+s]+C、howo = buffer_howo_a11[n*S+s]，让数据读取更高效，大幅减少了对外部存储的访问次数。
2.3 优化判断：重构逻辑流程，降低等待开销
_conv_forward算子的执行过程中，包含大量的分支判断、下一个计算单元的索引确定以及同步通信逻辑，不合理的判断流程会导致线程等待、通信阻塞，降低整体并行效率。本次优化中，我们对判断逻辑和通信同步流程进行了双重重构：
- 简化下一个计算单元的索引判断逻辑：通过多层条件判断，依次确定行列、通道、矩阵维度的下一个计算索引，明确
has_next_w的终止条件，让线程能快速找到下一个执行任务，减少无效的逻辑遍历； - 优化通信同步与权重加载逻辑：在MPI广播通信中，提前判断后续是否有计算任务，若存在则异步加载下一个权重数据，通过
broadcast_async实现通信与计算的重叠，同时配合sync_threads、matmul_wait_loading_weight等同步操作，让权重加载与当前计算任务并行执行，大幅减少线程的等待时间； - 动态更新矩阵计算的权重状态：通过
matmul_set_updating_weight动态设置权重更新状态，让矩阵计算在权重准备完成后再执行，避免因权重未就绪导致的计算中断。
优化判断的核心是让“判断”服务于“计算”，减少逻辑分支的冗余，让通信、加载、计算三大环节尽可能并行，最大化利用硬件的并行计算能力。
2.4 删除冗余：精简代码与变量，降低执行损耗
代码中的冗余变量、无效判断和重复定义，会在运行过程中带来不必要的资源占用和执行损耗。本次优化中，我们对_conv_forward算子的代码进行了全面的“精简瘦身”：
- 清理冗余变量：删除了
prev_bE、prev_bF等未被实际使用的历史变量，以及重复定义的局部变量，减少内存占用； - 精简条件判断：对宽度方向的下一个索引判断逻辑进行简化，合并重复的判断条件，例如
is_last_s的判断，直接通过next_local_st_wi>=cur_bw确定，避免多层嵌套判断； - 删除无用参数：移除了
read_all_C等未参与实际计算的参数，让函数的参数传递更简洁，减少数据传递的开销。
代码精简的过程，也是对算子执行逻辑的再梳理，让每一行代码、每一个变量都能发挥实际作用，从细节上降低算子的执行损耗。
二、未实现方案：RMA模拟共享空间，留待后续探索
在本次优化中，我们也提出了一个未落地的优化方向——用RMA（远程内存访问）模拟共享空间。RMA作为MPI的重要特性，能够让进程直接访问其他进程的内存空间，无需通过传统的发送/接收操作进行数据传输，这对于减少_conv_forward算子在多进程并行中的通信开销具有重要意义。
之所以暂未实现，主要是因为RMA的使用需要结合硬件的网络架构、进程的内存布局进行精细化设计，同时需要解决跨进程内存访问的同步、冲突问题，对算子的整体逻辑改动较大。目前我们已经完成了该方案的初步调研和思路设计，后续会结合硬件环境，逐步实现RMA模拟共享空间的优化，进一步降低多进程并行下的通信压力。
三、优化心得：在实践中理解“性能优化”的本质
这次_conv_forward算子优化，让我对并行计算和性能优化的理解又加深了一层。作为一名深耕超算领域的学生，我始终认为，优化不是“炫技”，而是“贴合”——贴合硬件的架构特性，贴合算子的计算逻辑，贴合实际的运行场景。
从最初接触超算竞赛，自学Fortran完成海洋模型、地震波模拟软件的算子移植和通信优化，到这次针对_conv_forward算子的精细化调优，我始终坚持“从工程实践出发，用数据验证优化效果”。无论是参数微调、暂存常用，还是优化判断、删除冗余，每一个优化动作的背后，都是对算子运行瓶颈的精准定位，而每一次优化效果的验证，又能让我对硬件、代码、并行计算的结合有更清晰的认知。
同时，这次站上开放原子开发者大会的舞台，也让我感受到了开源技术的魅力。开源不是单一的代码分享，而是技术思想的碰撞、经验的交流，在和各位开源开发者的交流中，我也收获了不少关于算子优化、架构设计的新思路，这也让我更加坚定了在开源领域持续探索、持续贡献的决心。
四、未来方向：持续深耕架构优化，探索开源新可能
作为一名计算机专业的学生，我的技术探索之路才刚刚开始。未来，我会继续深耕超算与并行计算领域，围绕不同架构（x86、ARM）的硬件设备优化、集群通信网络设计、算子级别的精细化调优三大方向持续探索，挖掘硬件的最大潜力，让代码在不同架构下都能实现高效运行。
同时，我也会持续将自己的实践成果开源，让更多开发者能参与到技术交流和优化中，在开源社区中相互学习、共同进步。这次_conv_forward算子优化只是一个起点，后续我会继续完善该算子的优化方案，落地RMA模拟共享空间的思路，同时也会探索更多核心算子的优化方法，为开源技术的发展贡献自己的一份力量。
最后，感谢开放原子开发者大会提供的分享平台，也感谢各位同行的批评与指正。性能优化是一条没有终点的道路，唯有保持探索的热情、务实的态度，才能在技术之路上不断前行。也期待在未来的开源交流中，和各位一起碰撞出更多技术的火花！
Some information may be outdated