我对使用malloc分配的内存和使用mmap映射文件(由磁盘上的文件支持)进行写入1.28亿个整数的性能测试...我本以为结果会有些相似,因为我理解当向映射文件写入数据时,数据最初被写入内存并且pdflush在后台写入磁盘(可以配置频率)。使用malloc,写入1.28亿个整数需要0.55秒;而用mmap需要1.9秒。
所以我的问题是:为什么会有差异。我的初步想法是pdflush占用了总线或者当pdflush访问内存时,它会阻塞写入...但是,第二次运行mmap版本的结果为0.52秒(由于缓存),这让我相信每个mmap后面的页面只有在写入时才分配 (尽管通过调用mmap来保留它)...据我所知,malloc产生的内存直到第一次写入才实际分配...难道最初的差异是因为在malloc的初始写入后,整个块都被分配了,而使用mmap时,每次写入新页面时,操作系统必须先分配它吗?
更新:
操作系统: CentOS Linux release 7.0.1406 (Core) 内核:3.10.0-123.el7.x86_64 gcc:4.8.2
所以我的问题是:为什么会有差异。我的初步想法是pdflush占用了总线或者当pdflush访问内存时,它会阻塞写入...但是,第二次运行mmap版本的结果为0.52秒(由于缓存),这让我相信每个mmap后面的页面只有在写入时才分配 (尽管通过调用mmap来保留它)...据我所知,malloc产生的内存直到第一次写入才实际分配...难道最初的差异是因为在malloc的初始写入后,整个块都被分配了,而使用mmap时,每次写入新页面时,操作系统必须先分配它吗?
更新:
操作系统: CentOS Linux release 7.0.1406 (Core) 内核:3.10.0-123.el7.x86_64 gcc:4.8.2
int* pint = malloc(128000000 * sizeof(int));
int* pint_copy = pint;
clock_t start = clock();
int i;
for(i = 0; i < 128000000; ++i)
{
*pint++ = i;
}
clock_t end = clock();
double cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC;
printf("%f\n", cpu_time_used);
free(pint_copy);
vs
int fd = open("db", O_RDWR | O_CREAT, 0666);
const size_t region_size = ((512000000 / sysconf(_SC_PAGE_SIZE)) + 1) * sysconf(_SC_PAGE_SIZE);
int return_code = ftruncate(fd, region_size);
if (return_code < 0)
printf("mapped memory file could not be truncated: %u\n", return_code);
int* pint = mmap(NULL, region_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
int* pint_copy = pint;
close(fd);
clock_t start = clock();
int i;
for(i = 0; i < 128000000; ++i)
{
*pint++ = i;
}
clock_t end = clock();
double cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC;
printf("%f\n", cpu_time_used);
fgetc(stdin);
munmap(pint_copy, region_size);
添加:
int z = 512;
while(z < 128000000)
{
pint[z] = 0;
z += 1024;
}
AFTER:
clock_t start = clock();
在两次试验中均产生了0.37秒的时间,这使我相信“触碰”每个页面会导致操作系统分配物理内存(无论是用于mmap还是malloc)...这也部分是因为“触碰”页面将一些内存移动到缓存中...有人知道在长时间大量写内存时,pdflush是否会阻塞或减慢内存写入速度吗?
mmap()
使用情况(即是否映射了/dev/zero
或真实文件或其他内容,如果是真实文件,它是否事先存在或需要分配),等等... - twalberg