5 ms·

what if your buffer is 64 GiB? (ok, in practice it will be zero'd on demand by the OS but still)

by cozzyd 1y ago

josephg 1y ago
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.
briansm 1y ago
Surely the point of Rust is 'safety at the price of performance' and if extra performance is required, don't use Rust. Don't bodge the language to accommodate!
- int_19h 1y ago
  It is not. If it were, it wouldn't even have raw pointers, for example.
  - briansm 1y ago
    and yet an article about a 'safe' language has code examples full of 'unsafe'... wut.
    - panstromek 1y ago
      `unsafe` is just a barrier between what compiler proves and what programmer proves. People should really read more on safety semantics in Rust before making comments like this, it's quite annoying to bump into surface level misunderstandings everytime Rust is mentioned somewhere.
    - hmry 1y ago
      In normal safe code, the compiler ensures your code has no UB. In an unsafe block, the programmer ensures the code has no UB. Safe abstractions are created out of unsafe operations by making sure it's impossible to violate the operations' preconditions. Either by checking at runtime and returning an error or aborting the program if they're violated, or by using the type system and borrow checker to verify them at compile time (writing the code such that any program that could violate the preconditions must have a type error.) If Rust didn't have unsafe, the only way to access the underlying unsafe operations would be dropping down to C/C++/Assembly, or hardcoding them in the compiler. This is what other languages do, and it's ergonomically worse because the barrier to adding a whole new language and build system to your project is quite high.
- panstromek 1y ago
  The point of rust is explicitly not 'safety at the price of performance', quite the opposite. The whole point was to create language where safety doesn't cost performance like it does in most other languages.

what if your buffer is 64 GiB? (ok, in practice it will be zero'd on demand by the OS but still)

by cozzyd 1y ago

what if your buffer is 64 GiB? (ok, in practice it will be zero'd on demand by the OS but still)

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.

briansm 1y ago

Surely the point of Rust is 'safety at the price of performance' and if extra performance is required, don't use Rust. Don't bodge the language to accommodate!

int_19h 1y ago
It is not. If it were, it wouldn't even have raw pointers, for example.
- briansm 1y ago
  and yet an article about a 'safe' language has code examples full of 'unsafe'... wut.
  - panstromek 1y ago
    `unsafe` is just a barrier between what compiler proves and what programmer proves. People should really read more on safety semantics in Rust before making comments like this, it's quite annoying to bump into surface level misunderstandings everytime Rust is mentioned somewhere.
  - hmry 1y ago
    In normal safe code, the compiler ensures your code has no UB. In an unsafe block, the programmer ensures the code has no UB. Safe abstractions are created out of unsafe operations by making sure it's impossible to violate the operations' preconditions. Either by checking at runtime and returning an error or aborting the program if they're violated, or by using the type system and borrow checker to verify them at compile time (writing the code such that any program that could violate the preconditions must have a type error.) If Rust didn't have unsafe, the only way to access the underlying unsafe operations would be dropping down to C/C++/Assembly, or hardcoding them in the compiler. This is what other languages do, and it's ergonomically worse because the barrier to adding a whole new language and build system to your project is quite high.
panstromek 1y ago
The point of rust is explicitly not 'safety at the price of performance', quite the opposite. The whole point was to create language where safety doesn't cost performance like it does in most other languages.