小编Big*_*ree的帖子

我使用mmap编写了1.28亿个内存到分配了malloc的内存和映射的内存文件(由磁盘上的文件支持)的性能测试......我原本期望结果有点相似,因为我的理解是在写入时一个映射的内存文件,数据最初写入内存,pdflush在后台写入磁盘(可以配置的频率).使用malloc,写入128M整数需要0.55秒; mmap花了1.9秒.

所以我的问题是:为什么差异.我的首字母缩写是pdflush挤满了总线,或者当pdflush正在访问内存时,它阻止了写入...但是,第二次运行mmap版本会产生.52秒的结果(由于缓存)导致我相信mmap背后的每个页面都没有被分配,直到它被写入(尽管通过调用mmap保留它)...我也理解,malloc生成的内存直到第一次写入才真正分配. .could最初的区别是因为在malloc初始写入内存后,整个块被分配并使用mmap,每次写入新页面时,os必须首先分配它？

更新:

os:CentOS Linux版本7.0.1406(核心)内核: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 = …

为什么store_idx_x86()的汇编输出和store_idx()一样，load_idx_x86()和load_idx()一样？

我的理解是 __atomic_load_n() 会刷新核心的失效队列，而 __atomic_store_n() 会刷新核心的存储缓冲区。

注意——我遵守了：gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16)

更新：我知道 x86 永远不会用其他存储重新排序存储并用其他负载加载——所以 gcc 足够聪明，只在需要时才实现 sfence 和 lfence，或者应该使用 __atomic_ 导致栅栏（假设内存模型比__ATOMIC_RELAXED）？

代码

#include <stdint.h>


inline void store_idx_x86(uint64_t* dest, uint64_t idx)
{   
    *dest = idx;    
}

inline void store_idx(uint64_t* dest, uint64_t idx)
{
    __atomic_store_n(dest, idx, __ATOMIC_RELEASE);
}

inline uint64_t load_idx_x86(uint64_t* source)
{
    return *source;

}

inline uint64_t load_idx(uint64_t* source)
{
    return __atomic_load_n(source, __ATOMIC_ACQUIRE);
}

集会：

.file   "util.c"
    .text
    .globl  store_idx_x86
    .type   store_idx_x86, @function
store_idx_x86:
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset …