3 ms·
Let’s see what happens after the allocation. With malloc + memset, the OS will likely allocate that memory in huge pages, on PC that would be 2-4MB / page depe
by Const-me 10y ago
Let’s see what happens after the allocation.
With malloc + memset, the OS will likely allocate that memory in huge pages, on PC that would be 2-4MB / page depending on the architecture, https://en.wikipedia.org/wiki/Page_(computer_memory)#Huge_pages https://en.wikipedia.org/wiki/Page_(computer_memory)#Huge_pa...
If I calloc then write, the OS can’t give me huge pages because of that copy on write thing. Instead, the OS will gradually give me the memory in tiny 4kb pages. For large buffers you should expect TLB cache misses, therefore slowing down all operations with that memory.
- amluto 10y agoI don't think your average kerbel can tell the difference between malloc+memset and calloc.
- kr7 10y agoA quick test with strace on my machine shows that callocing and mallocing a 2GB buffer results in the exact same mmap system call for both. Neither use huge pages.
- mikeash 10y agoThere's no reason the OS can't use huge pages for a calloc. In fact, "give me some zeroed memory" tends to be the only interface exposed by the kernel, since security requires zeroing memory before handing it out to userspace anyway.
- Const-me 10y agoThis article _creates_ a reason why the OS might not be able to use huge pages for a calloc. If substantial count of people will read this article, believe what’s written, and [re]design their software under the wrong assumption calloc returns sparse copy-on-write memory buffer at no performance cost — the OSes will no longer be able to use huge pages for a calloc. Because doing that would dramatically increase physical memory usage for such software.