为什么写入填充 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 倍，而快速迭代则保持不变。 p>

最后一点是，进程的 total 运行时间比简单地计时 process 例程要近得多（事实上，零填充，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 只是省略了零内存设置（或者更确切地说，只是将其融合到 @987654336 @，即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。