我是一个有用的助手，可以翻译文本。
我将一些汇编代码与一些 C 代码连接起来，以测试函数调用的成本。以下是汇编和 C 源代码（分别使用 fasm 和 gcc）：
汇编代码：
C源代码：
我得到的结果令人惊讶。首先，速度取决于链接顺序。如果我链接为
但是如果以相反的顺序链接，即
它们不同是非常令人惊讶的，但这不是我要问的问题。（相关问题在此）
我要问的问题是，在第二次运行中，带有函数调用的循环比没有函数调用的循环更快，为什么调用函数的成本显然是负面的。
编辑：只是提一下评论中尝试过的一些事情：
我不得不手动（且不可移植地）强制64字节对齐，因为FASM在可执行部分上不支持超过4字节的对齐，至少在我的机器上是如此。将程序偏移
我不确定如何解释它，但这是我目前发现的。
另外一个我注意到的事情是，如果从两个函数中删除
这表示那是其中最昂贵的部分。堆栈对齐两次都是相同的，因此这不是差异的原因。我最好的猜测是硬件在推送后期望调用或类似操作进行优化，但我不知道是否存在这样的情况。
我将一些汇编代码与一些 C 代码连接起来，以测试函数调用的成本。以下是汇编和 C 源代码（分别使用 fasm 和 gcc）：
汇编代码：
format ELF
public no_call as "_no_call"
public normal_call as "_normal_call"
section '.text' executable
iter equ 100000000
no_call:
mov ecx, iter
@@:
push ecx
pop ecx
dec ecx
cmp ecx, 0
jne @b
ret
normal_function:
ret
normal_call:
mov ecx, iter
@@:
push ecx
call normal_function
pop ecx
dec ecx
cmp ecx, 0
jne @b
ret
C源代码：
#include <stdio.h>
#include <time.h>
extern int no_call();
extern int normal_call();
int main()
{
clock_t ct1, ct2;
ct1 = clock();
no_call();
ct2 = clock();
printf("\n\n%d\n", ct2 - ct1);
ct1 = clock();
normal_call();
ct2 = clock();
printf("%d\n", ct2 - ct1);
return 0;
}
我得到的结果令人惊讶。首先，速度取决于链接顺序。如果我链接为
gcc intern.o extern.o，则典型输出为：162
181
但是如果以相反的顺序链接，即
gcc extern.o intern.o，我得到的输出更像是：162
130
它们不同是非常令人惊讶的，但这不是我要问的问题。（相关问题在此）
我要问的问题是，在第二次运行中，带有函数调用的循环比没有函数调用的循环更快，为什么调用函数的成本显然是负面的。
编辑：只是提一下评论中尝试过的一些事情：
- 在编译后的字节码中，函数调用没有被优化掉。
- 将函数和循环的对齐方式调整到从4到64字节边界上并没有加速no_call，尽管某些对齐方式确实减慢了normal_call
- 让CPU/操作系统有机会预热，通过多次而不仅仅是一次调用函数，对测量时间的长度没有明显影响，改变调用的顺序或单独运行也没有影响
- 运行更长时间不会影响比率，例如运行1000倍的时间，我的运行时间分别为
162.168和131.578秒
format ELF
public no_call as "_no_call"
public normal_call as "_normal_call"
section '.text' executable
iter equ 100000000
offset equ 23 ; this is the number I am changing
times offset nop
times 16 nop
no_call:
mov ecx, iter
no_call.loop_start:
push ecx
pop ecx
dec ecx
cmp ecx, 0
jne no_call.loop_start
ret
times 55 nop
normal_function:
ret
times 58 nop
normal_call:
mov ecx, iter
normal_call.loop_start:
push ecx
call normal_function
pop ecx
dec ecx
cmp ecx, 0
jne normal_call.loop_start
ret
我不得不手动（且不可移植地）强制64字节对齐，因为FASM在可执行部分上不支持超过4字节的对齐，至少在我的机器上是如此。将程序偏移
offset字节后，我发现以下内容。if (20 <= offset mod 128 <= 31) then we get an output of (approximately):
162
131
else
162 (+/- 10)
162 (+/- 10)
我不确定如何解释它，但这是我目前发现的。
另外一个我注意到的事情是，如果从两个函数中删除
push ecx 和 pop ecx，输出结果会变成：30
125
这表示那是其中最昂贵的部分。堆栈对齐两次都是相同的，因此这不是差异的原因。我最好的猜测是硬件在推送后期望调用或类似操作进行优化，但我不知道是否存在这样的情况。
clock是可以的。试着查看编译后的 C 代码生成的汇编内容。而且从链接顺序很重要这个事实来判断，似乎正在进行一些链接时优化。 - Eugene Sh.jne @b的目标）很重要。不幸的是，您没有明确命名它们。no_call和normal_call只使用一次，因此在那里有任何未对齐的惩罚并不重要（远远超出了clock计时的[不]精度）。由于normal_function被广泛调用，因此将其对齐可能也有所帮助。通常 4 或 8 边界就足够了，但可以自由尝试高达 64（我认为现代缓存行长度为 32B？但 64 肯定足够应付任何情况）。 - Ped7gno_call+normal_call，以使 CPU 频率升高并使缓存状态对两种变体（预缓存）相似。 - Ped7giter equ 1000000000更改为运行10倍长。两个函数的运行时间约为1.55秒。我尝试在循环之前使用align 16，但没有显著的差异。整个程序适合代码缓存，这可能是为什么对齐没有帮助的原因。 - rcgldr