c++ - 为什么写入 42 路缓冲区比写入零缓冲区快？

Question

无论内存¹ 中的现有内容如何，​​我都希望写入char * 缓冲区需要相同的时间。不是吗？

但是，在缩小基准测试中的不一致性时，我遇到了一个显然不是这样的情况。包含全零的缓冲区在性能方面与填充 42 的缓冲区有很大不同。

从图形上看，这看起来像(下面有详细信息):

这是我用来生成上述³的代码:

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

volatile char *sink;

void process(char *buf, size_t len) {
  clock_t start = clock();
  for (size_t i = 0; i < len; i += 678)
    buf[i] = 'z';
  printf("Processing took %lu μs\n",
      1000000UL * (clock() - start) / CLOCKS_PER_SEC);
  sink = buf;
}

int main(int argc, char** argv) {
  int total = 0;
  int memset42 = argc > 1 && !strcmp(argv[1], "42");
  for (int i=0; i < 5; i++) {
    char *buf = (char *)malloc(BUF_SIZE);
    if (memset42)
      memset(buf, 42, BUF_SIZE);
    else
      memset(buf,  0, BUF_SIZE);
    process(buf, BUF_SIZE);
  }
  return EXIT_SUCCESS;
}

我在我的 Linux 机器上编译它:

 gcc -O2 buffer_weirdness.cpp -o buffer_weirdness

...当我使用零缓冲区运行版本时，我得到:

./buffer_weirdness zero
Processing took   12952 μs
Processing took  403522 μs
Processing took  626859 μs
Processing took  626965 μs
Processing took  627109 μs

请注意，第一次迭代很快，而其余迭代可能需要 50 倍 的时间。

当缓冲区首次填充 42 时，处理总是很快的:

./buffer_weirdness 42
Processing took   12892 μs
Processing took   13500 μs
Processing took   13482 μs
Processing took   12965 μs
Processing took   13121 μs

行为取决于 `BUF_SIZE(上例中为 1GB)- 较大的尺寸更可能显示问题，并且还取决于当前的主机状态。如果我让主机单独呆一会儿，慢速迭代可能需要 60,000 μs，而不是 600,000 - 所以快 10 倍，但仍然比快速处理时间慢 5 倍。最终，时代回到了完全缓慢的行为。

该行为至少部分取决于透明大页面 - 如果我禁用它们²，慢速迭代的性能将提高约 3 倍，而快速迭代则保持不变。

最后要注意的是，进程的总运行时间比简单地为进程例程计时更接近(事实上，零填充、THP 关闭版本大约是比其他大致相同的速度快 2 倍)。

这是怎么回事？

---

¹ 除了一些非常不寻常的优化之外，例如编译器了解缓冲区已包含的值并省略相同值的写入，这在此处不会发生。

² sudo sh -c "echo never >/sys/kernel/mm/transparent_hugepage/enabled"

³ 这是原始基准的精简版。是的，我正在泄漏分配，克服它——它导致了一个更简洁的例子。原始示例没有泄漏。事实上，当您不泄漏分配时，行为会发生变化:可能是因为 malloc 可以重新使用该区域进行下一次分配，而不是向操作系统请求更多内存。

Answer 1

这似乎很难重现，所以它可能是特定于编译器/libc 的。

我最好的猜测:

当您调用 malloc 时，您将内存映射到您的进程空间，这不意味着操作系统已经采取了必要的从其空闲内存池中提取页面，但它只是将条目添加到某些表中。

现在，当您尝试访问那里的内存时，您的 CPU/MMU 将引发错误——操作系统可以捕获它，并检查该地址是否属于“已经在内存空间中，但实际上还没有”的类别分配给进程”。如果是这种情况，则会找到必要的空闲内存并将其映射到进程的内存空间。

现在，现代操作系统通常有一个内置选项，可以在(重新)使用之前“清零”页面。如果这样做，则不需要 memset(,0,) 操作。在 POSIX 系统的情况下，如果您使用 calloc 而不是 malloc，内存将被清零。

换句话说，当您的操作系统支持时，您的编译器可能已经注意到并完全省略了 memset(,0,)。这意味着您在 process() 中写入页面的那一刻是它们被访问的第一刻——这会触发操作系统的“动态页面映射”机制。

memset(,42,) 当然不能被优化掉，所以在那种情况下，页面实际上是预先分配的，你看不到在 中花费的时间>process() 函数。

您应该使用 /usr/bin/time 来实际比较整个执行时间与花费在 process 上的时间——我怀疑这意味着 中节省的时间>process 实际上花费在 main 中，可能在内核上下文中。

更新:使用出色的 Godbolt Compiler Explorer 进行测试: 是的，对于 -O2 和 -O3，现代 gcc 只是省略了零内存设置(或者更确切地说，只是将其融合到 calloc 中，这是带清零的 malloc:

#include <cstdlib>
#include <cstring>
int main(int argc, char ** argv) {
  char *p = (char*)malloc(10000);
  if(argc>2) {
    memset(p,42,10000);
  } else {
    memset(p,0,10000);
  }
  return (int)p[190]; // had to add this for the compiler to **not** completely remove all the function body, since it has no effect at all.
}

成为，对于 gcc6.3 上的 x86_64

main:
        // store frame state
        push    rbx
        mov     esi, 1
        // put argc in ebx
        mov     ebx, edi
        // Setting up call to calloc (== malloc with internal zeroing)
        mov     edi, 10000
        call    calloc 
        // ebx (==argc) compared to 2 ?
        cmp     ebx, 2
        mov     rcx, rax
        // jump on less/equal to .L2
        jle     .L2
        // if(argc > 2):
        // set up call to memset
        mov     edx, 10000
        mov     esi, 42
        mov     rdi, rax
        call    memset
        mov     rcx, rax
.L2:    //else case
        //notice the distinct lack of memset here!
        // move the value at position rcx (==p)+190 into the "return" register
        movsx   eax, BYTE PTR [rcx+190]
        //restore frame
        pop     rbx
        //return
        ret

顺便说一句，如果你删除return p[190]，

  }
  return 0;
}

那么编译器根本没有理由保留函数体——它的返回值在编译时很容易确定，而且没有副作用。整个程序然后编译为

main:
        xor     eax, eax
        ret

请注意，对于每个 A，A xor A 都是 0。