为什么在启用GCC优化的情况下，此代码使用的速度大大降低了6.5倍?

问题描述

出于某种原因，我想对 glibc 的 strlen 函数进行基准测试，发现在GCC和我不知道为什么.

I wanted to benchmark glibc's strlen function for some reason and found out it apparently performs much slower with optimizations enabled in GCC and I have no idea why.

这是我的代码:

#include <time.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>

int main() {
    char *s = calloc(1 << 20, 1);
    memset(s, 65, 1000000);
    clock_t start = clock();
    for (int i = 0; i < 128; ++i) {
        s[strlen(s)] = 'A';
    }
    clock_t end = clock();
    printf("%lld\n", (long long)(end - start));
    return 0;
}

在我的机器上，它输出:

On my machine it outputs:

$ gcc test.c && ./a.out
13336
$ gcc -O1 test.c && ./a.out
199004
$ gcc -O2 test.c && ./a.out
83415
$ gcc -O3 test.c && ./a.out
83415

以某种方式，启用优化会使其执行更长的时间.

Somehow, enabling optimizations causes it to execute longer.

推荐答案

在Godbolt的编译器资源管理器提供了以下说明:

• 在 -O0 或未经优化的情况下，生成的代码将调用C库函数 strlen ;
• 在 -O1 处，生成的代码使用 rep scasb 指令进行简单的内联扩展；
• 在 -O2 及更高版本中，生成的代码使用更加精细的内联扩展.

• at -O0 or without optimisations, the generated code calls the C library function strlen;
• at -O1 the generated code uses a simple inline expansion using a rep scasb instruction;
• at -O2 and above, the generated code uses a more elaborate inline expansion.

反复对代码进行基准测试可显示从一次运行到另一次运行的实质性变化，但是增加迭代次数则表明:

Benchmarking your code repeatedly shows substantial variations from one run to another, but increasing the number of iterations shows that:

• -O1 代码比C库实现慢得多: 32240 与 3090
• -O2 代码比 -O1 快，但仍然比C库代码慢得多: 8570 vs 3090.

• the -O1 code is much slower than the C library implementation: 32240 vs 3090
• the -O2 code is faster than the -O1 but still substantially slower than the C ibrary code: 8570 vs 3090.

此行为特定于 gcc 和GNU libc.在OS/X上使用 clang 和Apple的Libc进行的相同测试没有显示出显着差异，这并不奇怪，因为Godbolt显示 clang 生成了对C库的调用 strlen 在所有优化级别.

This behavior is specific to gcc and the GNU libc. The same test on OS/X with clang and Apple's Libc does not show significant differences, which is not a surprise as Godbolt shows that clang generates a call to the C library strlen at all optimisation levels.

这可能被视为gcc/glibc中的错误，但更广泛的基准测试可能表明，调用 strlen 的开销比缺少内联代码对小字符串的性能产生的影响更为重要.基准测试中的字符串异常大，因此将基准测试重点放在超长字符串上可能不会产生有意义的结果.

This could be considered a bug in gcc/glibc but more extensive benchmarking might show that the overhead of calling strlen has a more important impact than the lack of performance of the inline code for small strings. The strings in your benchmark are uncommonly large, so focusing the benchmark on ultra-long strings might not give meaningful results.

我改进了此基准测试并测试了各种字符串长度.从运行在Intel(R)Core(TM)i3-2100 CPU @ 3.10GHz上且运行gcc(Debian 4.7.2-5)4.7.2的Linux上的基准看来，由 -O1 总是较慢，对于中等长度的字符串，其速度最多可达 10 ，而 -O2 仅比libc strlen 快一点.code>用于非常短的字符串，而速度则快于较长的字符串.从这些数据来看， strlen 的GNU C库版本对于大多数字符串长度都非常有效，至少在我的特定硬件上是如此.还请记住，缓存会对基准测试产生重大影响.

I improved this benchmark and tested various string lengths. It appears from the benchmarks on linux with gcc (Debian 4.7.2-5) 4.7.2 running on an Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz that the inline code generated by -O1 is always slower, by as much as a factor of 10 for moderately long strings, while -O2 is only slightly faster than the libc strlen for very short strings and half as fast for longer strings. From this data, the GNU C library version of strlen is quite efficient for most string lengths, at least on my specific hardware. Also keeping in mind that cacheing has a major impact on benchmark measurements.

这是更新的代码:

#include <stdlib.h>
#include <string.h>
#include <time.h>

void benchmark(int repeat, int minlen, int maxlen) {
    char *s = malloc(maxlen + 1);
    memset(s, 'A', minlen);
    long long bytes = 0, calls = 0;
    clock_t clk = clock();
    for (int n = 0; n < repeat; n++) {
        for (int i = minlen; i < maxlen; ++i) {
            bytes += i + 1;
            calls += 1;
            s[i] = '\0';
            s[strlen(s)] = 'A';
        }
    }
    clk = clock() - clk;
    free(s);
    double avglen = (minlen + maxlen - 1) / 2.0;
    double ns = (double)clk * 1e9 / CLOCKS_PER_SEC;
    printf("average length %7.0f -> avg time: %7.3f ns/byte, %7.3f ns/call\n",
           avglen, ns / bytes, ns / calls);
}

int main() {
    benchmark(10000000, 0, 1);
    benchmark(1000000, 0, 10);
    benchmark(1000000, 5, 15);
    benchmark(100000, 0, 100);
    benchmark(100000, 50, 150);
    benchmark(10000, 0, 1000);
    benchmark(10000, 500, 1500);
    benchmark(1000, 0, 10000);
    benchmark(1000, 5000, 15000);
    benchmark(100, 1000000 - 50, 1000000 + 50);
    return 0;
}

以下是输出:

chqrlie> gcc -std=c99 -O0 benchstrlen.c && ./a.out
average length       0 -> avg time:  14.000 ns/byte,  14.000 ns/call
average length       4 -> avg time:   2.364 ns/byte,  13.000 ns/call
average length      10 -> avg time:   1.238 ns/byte,  13.000 ns/call
average length      50 -> avg time:   0.317 ns/byte,  16.000 ns/call
average length     100 -> avg time:   0.169 ns/byte,  17.000 ns/call
average length     500 -> avg time:   0.074 ns/byte,  37.000 ns/call
average length    1000 -> avg time:   0.068 ns/byte,  68.000 ns/call
average length    5000 -> avg time:   0.064 ns/byte, 318.000 ns/call
average length   10000 -> avg time:   0.062 ns/byte, 622.000 ns/call
average length 1000000 -> avg time:   0.062 ns/byte, 62000.000 ns/call
chqrlie> gcc -std=c99 -O1 benchstrlen.c && ./a.out
average length       0 -> avg time:  20.000 ns/byte,  20.000 ns/call
average length       4 -> avg time:   3.818 ns/byte,  21.000 ns/call
average length      10 -> avg time:   2.190 ns/byte,  23.000 ns/call
average length      50 -> avg time:   0.990 ns/byte,  50.000 ns/call
average length     100 -> avg time:   0.816 ns/byte,  82.000 ns/call
average length     500 -> avg time:   0.679 ns/byte, 340.000 ns/call
average length    1000 -> avg time:   0.664 ns/byte, 664.000 ns/call
average length    5000 -> avg time:   0.651 ns/byte, 3254.000 ns/call
average length   10000 -> avg time:   0.649 ns/byte, 6491.000 ns/call
average length 1000000 -> avg time:   0.648 ns/byte, 648000.000 ns/call
chqrlie> gcc -std=c99 -O2 benchstrlen.c && ./a.out
average length       0 -> avg time:  10.000 ns/byte,  10.000 ns/call
average length       4 -> avg time:   2.000 ns/byte,  11.000 ns/call
average length      10 -> avg time:   1.048 ns/byte,  11.000 ns/call
average length      50 -> avg time:   0.337 ns/byte,  17.000 ns/call
average length     100 -> avg time:   0.299 ns/byte,  30.000 ns/call
average length     500 -> avg time:   0.202 ns/byte, 101.000 ns/call
average length    1000 -> avg time:   0.188 ns/byte, 188.000 ns/call
average length    5000 -> avg time:   0.174 ns/byte, 868.000 ns/call
average length   10000 -> avg time:   0.172 ns/byte, 1716.000 ns/call
average length 1000000 -> avg time:   0.172 ns/byte, 172000.000 ns/call

这篇关于为什么在启用GCC优化的情况下，此代码使用的速度大大降低了6.5倍?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！