ICC环境下修改独立solver代码后matrixSetup运行时异常升高求助

该问题属于典型的Intel编译器旧版本触发的CPU前端指令对齐性能罚则，具体原因与修复方案如下：

核心成因 #

• 修改solver代码虽然没有改动matrixSetup的逻辑，但会改变整个程序二进制的代码段（.text段）布局：当这段热循环的起始地址、以及它访问的connectedPartitions数组起始地址，刚好从对齐CPU 32字节微操作缓存（uop cache）/64字节缓存行的位置，变为跨边界位置时，CPU无法将这段高频循环的指令预加载到uop cache中，每次执行都需要重新解码指令，累计就会出现大幅耗时上涨。
• vTune显示单段循环指令完全一致属于正常现象：对齐问题不会改变指令本身的内容，只会改变指令在内存中的排布地址。
• 添加-fpic后问题消失完全符合该逻辑：位置无关代码的生成规则会改变全局符号的偏移计算逻辑，连带调整了整个代码段的排布，刚好让热循环/访问数据回到了对齐位置，因此性能恢复。Clang默认的指令对齐策略和ICC 19.x不同，因此不会触发该问题。

验证方法 #

你可以通过以下操作确认该判断：

1. 用objdump -d分别导出修改solver前后的二进制程序反汇编结果，查看该热循环的起始地址是否对齐到32字节边界，耗时升高的版本大概率存在跨边界问题
2. 查看vTune的Front-End Bound指标占比，性能异常版本该指标占比会远高于正常版本

彻底修复方案 #

1. 对这段热循环所在的函数添加强制对齐属性：用ICC支持的编译指令__attribute__((aligned(32)))修饰函数，或者在循环前添加#pragma vector aligned强制对齐
2. 升级Intel编译器到2021及以上版本，该版本已经修复了旧版默认对齐策略的偶发缺陷
3. 若-fpic参数不影响你的业务逻辑，也可以直接保留该参数，绝大多数场景下位置无关代码的性能损耗可以忽略不计

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