我有一个非常热的指令循环,需要在32字节边界上正确对齐,以最大化
Intel’s Instruction Fetcher的有效性.
这个问题特定于英特尔不太老的CPU系列(从Sandy Bridge开始).如果未能正确对齐循环开始,则速度损失高达20%,这绝对太明显了.
这个问题非常罕见,需要一组高度优化的指令才能使指令获取器成为瓶颈.但幸运的是,这不是一个独特的案例.这是一个nice article explaining in details如何检测到这样的问题.
问题是,gcc还是clang会关心这个指令循环.它使得编译这个代码变成了一个产生随机结果的噩梦,这取决于热循环如何“好”地偶然排列.这也意味着修改完全不相关的功能仍然会极大地影响热循环的性能.
已经尝试了几个编译器标志,它们都没有给出令人满意的结果.
[编辑]尝试编译标志的更详细说明:
> -falign-functions = 32:没有影响或负面影响
> -falign-jumps = 32:没有影响
> -falign-loops = 32:当热循环被隔离成一小段测试代码时工作正常.但是在正常构建中,编译标志应用于整个源代码,在这种情况下它是有害的:对齐32字节的所有循环对性能不利.只有非常热门的人才能从中受益.
>还尝试在函数声明中使用__attribute __((optimize(“align-loops = 32”))).不会产生任何影响(生成相同的二进制文件,就好像声明不存在一样).后来gcc支持小组确认要被有效忽略.编辑:@Jester在注释中表明该语句适用于gcc 5.不幸的是,我的开发站主要使用gcc 4.8.4,这更像是一个可移植性的问题,因为我不控制构建过程中使用的最终编译器.
只有使用PGO构建才能可靠地产生预期的性能,但PGO不能被接受为解决方案,因为这段代码将使用自己的构建链集成到其他程序中.
所以,我正在考虑内联汇编.
这将特定于x64指令集,因此不需要可移植性.
如果我的理解是正确的,像NASM这样的汇编允许使用如下的语句:ALIGN 32,它会强制下一条指令在32字节边界上对齐.
由于目标源代码在C中,因此必须包含此语句.例如,像asm(“ALIGN 32”);
(这当然不起作用).
我希望这主要是知道正确的写作指令,而不是更深层次的东西,比如“这是不可能的”.