Hacker News Reader

Comment by cozzyd | Hacker News Reader

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.

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.

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.

c) SIMD won't be as helpful when you are zeroing small buffers of non-round sizes

That's what (b) is about.

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!

It is not. If it were, it wouldn't even have raw pointers, for example.

and yet an article about a 'safe' language has code examples full of 'unsafe'... wut.

`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.

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.

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.

Reply on news.ycombinator.com