Fortran相近点检测子程序非预期性能差异问题咨询

核心问题1：为何routine2的耗时可达routine1的10倍以上 #

两个子程序的计算逻辑完全等价，但gfortran在-O3优化级别下的代码生成逻辑存在本质差异：

• routine1的写法可被编译器完成全链路融合优化：判断逻辑直接将abs(points(i,:) - points(j,:)) < r内联进all()函数的约简流程，编译器在-O3阶段会将整个运算拆解为纯寄存器/向量运算路径——所有维度的差值计算、绝对值取模、阈值判断的中间结果全部直接留在向量寄存器中，完全不需要申请临时栈内存、也不需要执行跨内存的读写操作，运算路径最短。
• routine2的临时数组会触发强制的内存读写流程：只要代码显式写出“先把abs差值存入临时数组diff、再基于diff做all判断”的执行步骤，gfortran在-O3阶段会严格遵循Fortran的内存语义生成代码，不会自动做“临时数组消除”优化。尤其是当diff是维度由运行时参数传入的局部动态数组时，为了严格满足Fortran标准规定的内存别名判定规则，编译器无法随便删除显式的数组内存写入操作——哪怕这个临时数组从未被其他语句引用，也必须按代码顺序先循环把所有维度的差值逐个写入diff的栈内存地址，再从diff中逐个读回值完成阈值判断和约简。
• 这种流程差异带来的性能损耗被进一步放大：ndis=21的维度本来完全可以通过寄存器暂存所有中间结果，被迫走栈内存读写路径后，会产生额外的缓存未命中、栈对齐检查开销，最终出现10倍以上的耗时差。

核心问题2：为何按列优先规则转置存储的routine3性能反而劣于routine1 #

这个结果是对数组存储访问模式、性能优化逻辑的典型认知误区：

• 首先被忽略的转置固定开销：routine3的流程包含了“对原始点集做全量转置生成points_T”的步骤，这部分遍历全量点集、写入转置数组的操作本身就有固定的内存读写成本，在测试用例规模不大的场景下，这部分开销甚至会超过routine1的总运行时间。
• 循环结构和存储顺序的不匹配抵消了缓存优势：Fortran列优先存储的数组，连续内存块对应第一维的连续元素。很多人以为把数组转成“维度优先存储（即points_T(ndis, npts)）”后，取单个点的全维度值（即points_T(:, i)）是连续内存，就会获得缓存优势——但实际相近点检测的双层循环结构是“外层遍历点i、内层遍历所有待对比的点j”，这种结构下：
• 固定i时，逐维度遍历j做判断的访问模式，会在每轮j循环时跨列读取points_T(:, j)的内存地址，j的每一步跳转间隔是ndis个实数的长度，远超过单cache line的存储容量，实际缓存命中率远低于预期。
• 原始未转置的点集数组（即points(npts, ndis)），在固定维度k时，j的遍历是第一维的连续内存访问，这部分流访问的硬件缓存预取效率反而更高。
• 转置存储的性能收益需要匹配对应的循环结构：只有当把循环顺序调整为“外层遍历维度k、内层遍历待对比的点j”，逐维度做提前剪枝（只要某对(i,j)在当前维度已经不满足阈值就直接跳出后续判断）时，列优先存储的连续访问优势才能体现。如果还是保留和routine1完全一致的“逐对比对、遍历全维度做判断”的循环逻辑，转置不仅不会带来性能提升，还会因为转置本身的开销和不连续访问拖慢整体速度。

内容的提问来源于stack exchange，提问作者pablo