在MacOS X机器上运行以下C代码(2GB文件上的一堆mmaps和munmaps)似乎比在 Linux机器上慢得多. #define BUFSZ 2000000000static u_char buf[BUFSZ];....// Time 10000 mmaps and munmaps from random offsets for various // sizes
#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
即使考虑到减少的内存量,考虑到文件只是物理内存的一半,这似乎是不寻常的.任何人都可以指向更改代码或配置更改,这可能会提高性能吗?
我们尝试使用read而不是mmaps,它确实产生了很大的不同,但这样做需要对现有代码库进行大量更改(并且mmap比linux上的读取快得多).
我想你只是没有衡量正确的事情.我检查了测试的内部部分,我的gcc版本能够完全优化循环.这种情况发生了变化,例如当我声明mblock指针是指向易失性数据的指针时.然后编译器必须对循环中的语句执行所有副作用,特别是从内存中对其进行充电.
因此,您可以从测试中得出的唯一结论是:
>你在MacOS X上的编译器不是很好
聪明
>总是检查汇编程序a
基准产生
因此,如果您可以重新测试您的测试,我会感兴趣的是看到两个系统在该功能方面的真正差异.