3 ms·

I’d love to know the actual performance impact of zeroing out memory. I bet the performance cost of zeroing out memory ahead of time is negligible in almost all

I’d love to know the actual performance impact of zeroing out memory. I bet the performance cost of zeroing out memory ahead of time is negligible in almost all programs.

cozzyd 1y ago
Here is a really dumb example: $ cat bigbuf.c #include <stdlib.h> #include <stdio.h> #include <string.h> #define DEFINITELY_BIG_ENOUGH 2U*1024*1024*1024 int main(int nargs, char ** args) { char * definitely_big_enough = malloc(DEFINITELY_BIG_ENOUGH); if (nargs > 1) { memset(definitely_big_enough,0, DEFINITELY_BIG_ENOUGH); } sprintf(definitely_big_enough,"%s",args[0]); return 0; } $ /usr/bin/time ./bigbuf 0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 1356maxresident)k 0inputs+0outputs (0major+80minor)pagefaults 0swaps $ /usr/bin/time ./bigbuf 1 0.05user 1.25system 0:01.31elapsed 99%CPU (0avgtext+0avgdata 2098468maxresident)k 0inputs+0outputs (0major+524369minor)pagefaults 0swaps YMMV on different operating systems. Of course this is a program only an idiot would write, but things like caches are often significantly bigger than the median case, especially on Linux where you know there is overcommit.
- Arnavion 1y ago
  A non-idiot would use calloc(DEFINITELY_BIG_ENOUGH), and that will likely erase the difference because the impl will be able to rely on mmap(ANONYMOUS) creating zero pages for such a large allocation. A more realistic test would be to have a large number of small allocations that get calloc'd and then free'd repeatedly, because a) free'ing a small allocation will not free the underlying page and thus reallocation will not be able to rely on it already being zero, and b) zeroing small allocations doesn't amortize the cost of zeroing as well as zeroing large allocations does.
  - delamon 1y ago
    c) SIMD won't be as helpful when you are zeroing small buffers of non-round sizes
    - Arnavion 1y ago
      That's what (b) is about.

I’d love to know the actual performance impact of zeroing out memory. I bet the performance cost of zeroing out memory ahead of time is negligible in almost all programs.

cozzyd 1y ago

Here is a really dumb example: $ cat bigbuf.c #include <stdlib.h> #include <stdio.h> #include <string.h> #define DEFINITELY_BIG_ENOUGH 2U*1024*1024*1024 int main(int nargs, char ** args) { char * definitely_big_enough = malloc(DEFINITELY_BIG_ENOUGH); if (nargs > 1) { memset(definitely_big_enough,0, DEFINITELY_BIG_ENOUGH); } sprintf(definitely_big_enough,"%s",args[0]); return 0; } $ /usr/bin/time ./bigbuf 0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 1356maxresident)k 0inputs+0outputs (0major+80minor)pagefaults 0swaps $ /usr/bin/time ./bigbuf 1 0.05user 1.25system 0:01.31elapsed 99%CPU (0avgtext+0avgdata 2098468maxresident)k 0inputs+0outputs (0major+524369minor)pagefaults 0swaps YMMV on different operating systems. Of course this is a program only an idiot would write, but things like caches are often significantly bigger than the median case, especially on Linux where you know there is overcommit.

Arnavion 1y ago
A non-idiot would use calloc(DEFINITELY_BIG_ENOUGH), and that will likely erase the difference because the impl will be able to rely on mmap(ANONYMOUS) creating zero pages for such a large allocation. A more realistic test would be to have a large number of small allocations that get calloc'd and then free'd repeatedly, because a) free'ing a small allocation will not free the underlying page and thus reallocation will not be able to rely on it already being zero, and b) zeroing small allocations doesn't amortize the cost of zeroing as well as zeroing large allocations does.
- delamon 1y ago
  c) SIMD won't be as helpful when you are zeroing small buffers of non-round sizes
  - Arnavion 1y ago
    That's what (b) is about.