在 MacOS X 机器上运行以下 C 代码(2GB 文件上的一堆 mmap 和 munmap)似乎比在 Linux 机器上慢得多。

#define BUFSZ 2000000000
static u_char buf[BUFSZ];
....

// Time 10000 mmaps and munmaps from random offsets for various
// sizes of mapped chunk.
for (msize = 4096; msize <= 1048576; msize *= 16) {
  fd = open("io_benchmark.dat", O_RDONLY);
  if (fd  < 0 ) die("can't open io_benchmark.dat for reading");
  for (i = 0; i < 10000; i++) {
    // Make sure the block to be mapped doesn't start in the
    // last meg.
    offset = (size_t) random() % (BUFSZ - 1048576);
    mblock = femmap(fd, (off_t)offset, (size_t) msize, PROT_READ,
                    "test block");
    total = 0;
    for (j = 0; j < msize; j++) {
      total += mblock[j];
    }
    femunmap(mblock, (size_t) msize, "test block");
  }
  printf("Elapsed time to mmap and munmap 10000 blocks of %d kB: %.4f sec\n",
         msize/1024, (time = time_since_last_call()));

  rslt = close(fd);
  if (fd  < 0 ) die("can't close io_benchmark.dat after reading");
}

具体来说,比较两台机器
CPU     Xeon E3113 dual core @ 3.00GHz           Core 2 Duo @ 2.4GHz dual core
RAM     8GB                                      4GB
Kernel  2.6.18-92.el5PAE SMP i686                MacOS 10.6.4 Snow Leopard
Disk    WD 250GB SATA 16MB cache 7200 RPM EXT3   Hitachi 250GB SATA 5400 RPM, journaled HFS+

给出以下结果
                            Linux    MacOS X
Time for 10000 4kB mmaps    0.0165   682.87
Time for 10000 64kB mmap    0.0170   657.79
Time for 10000 1MB mmaps    0.0217   633.38

即使考虑到减少的内存量,鉴于文件只有物理内存的一半,这似乎是不寻常的。任何人都可以指出可能会提高性能的代码更改或配置更改吗?

我们尝试使用读取而不是 mmap,它确实有很大的不同,但这样做需要对现有代码库进行大量更改(并且 mmap 比在 linux 上读取要快得多)。

最佳答案

我认为你只是没有衡量正确的东西。我检查了您测试的内部部分,我的 gcc 版本能够完全优化循环。

这会发生变化,例如,当我将 mblock 指针声明为指向 volatile 数据的指针时。然后编译器有义务对循环中的语句执行所有副作用,特别是从内存中对其进行充电。

因此,您可以从测试中得出的唯一结论是:

  • 你在 MacOS X 上的编译器不是很
    智能
  • 总是检查汇编程序
    基准产生

  • 因此,如果您可以重做真实的测试,我将有兴趣了解这两个系统在该功能方面的真正差异。

    关于c - 提高 MacOS X 上的 mmap/munmap 性能,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/4116774/

    10-12 02:58
    查看更多