背景:
在使用嵌入式汇编语言优化某些Pascal代码时,我注意到了一条不必要的MOV指令,并将其删除.
令我惊讶的是,删除不必要的指令会导致我的程序变慢.
我发现添加任意无用的MOV指令可以进一步提高性能.
效果不稳定,并且基于执行顺序进行更改:相同的垃圾指令向上或向下移动一行会产生减速.
我知道CPU会进行各种优化和精简,但这看起来更像是黑魔法.
数据:
我的代码版本有条件地在运行时间的循环中编译三个垃圾操作2**20==1048576.(周围的程序只计算SHA-256哈希值).
在我相当老的机器(英特尔(R)Core(TM)2 CPU 6400 @ 2.13 GHz)上的结果:
avg time (ms) with -dJUNKOPS: 1822.84 ms
avg time (ms) without: 1836.44 ms
程序在循环中运行25次,每次运行顺序随机变化.
摘抄:
{$asmmode intel}
procedure example_junkop_in_sha256;
var s1, t2 : uint32;
begin
// Here are parts of the SHA-256 algorithm, in Pascal:
// s0 {r10d} := ror(a, 2) xor ror(a, 13) xor …我熟悉数据对齐和性能，但对对齐代码相当陌生。我最近开始使用 NASM 在 x86-64 汇编中进行编程，并一直使用代码对齐来比较性能。据我所知，NASM 插入nop指令来实现代码对齐。
这是我一直在 Ivy Bridge 系统上尝试的一个功能
void triad(float *x, float *y, float *z, int n, int repeat) {
float k = 3.14159f;
int(int r=0; r<repeat; r++) {
for(int i=0; i<n; i++) {
z[i] = x[i] + k*y[i];
}
}
}
我为此使用的程序集如下。如果我不指定对齐方式，我的性能与峰值相比仅为 90% 左右。然而，当我将循环之前的代码以及两个内部循环对齐为 16 字节时，性能跃升至 96%。很明显，这种情况下的代码对齐会产生影响。
但这是最奇怪的部分。如果我将最里面的循环对齐到 32 字节，则该函数的性能没有任何差异，但是，在该函数的另一个版本中，在单独的对象文件中使用内部函数，我链接它的性能从 90% 跃升至 95%！
我做了一个对象转储（使用objdump -d -M intel）的版本对齐到16字节（我将结果发布到这个问题的末尾）和32字节，它们是相同的！事实证明，在两个目标文件中，最里面的循环无论如何都与 32 字节对齐。但一定有一些区别。
我对每个目标文件进行了十六进制转储，目标文件中有一个字节不同。与 16 字节对齐的目标文件有一个带有 的字节0x10，与 32 字节对齐的目标文件有一个带有 的字节0x20。到底是怎么回事！为什么一个目标文件中的代码对齐会影响另一个目标文件中函数的性能？我如何知道将我的代码调整到的最佳值是多少？
我唯一的猜测是，当加载程序重新定位代码时，32 字节对齐的对象文件会使用内在函数影响其他对象文件。 …