Comment by bhaak | Hacker News Reader

Comment by bhaak | Hacker News Reader

Some of the "performance penalties" look like FUD to me. At least to the extent implied in the article.

For example "use of an unitialized variable". Given that the compiler already has to analyze the program flow to determine if the variable could be use unitialized to output that warning, the optimization step to not initialize those variables that are written to before used doesn't seem so far away. This happens at compile time.

But, there's also the fact that a modern OS gives you heap memory zeroed mostly for free. A call to calloc is highly optimized nowadays. It needs to be for security reasons, as a program must never receive memory with data left from a different process.

Likewise the signed integer overflow check. Modern CPUs are so superscalar internally that an overflow check (which doesn't get flagged most of the time anyway) doesn't add anything to the execution speed.

And finally we are able to use that without resorting to assembler. GCC 5 has added support for built-in functions for arithmetics with overflow checking.

> But, there's also the fact that a modern OS gives you heap memory zeroed mostly for free. A call to calloc is highly optimized nowadays. It needs to be for security reasons, as a program must never receive memory with data left from a different process.

Memory often is coming from previously-freed heap space within the process. There is no security need to zero such memory. Zeroing it wouldn't even help, because the process is free to read the memory before malloc returns it.

And calloc, no matter how optimized it is, will still be more expensive than malloc which doesn't have to zero the memory.

> Modern CPUs are so superscalar internally that an overflow check (which doesn't get flagged most of the time anyway) doesn't add anything to the execution speed.

"Doesn't add anything" is not correct. These checks are not free:

http://danluu.com/integer-overflow/

https://news.ycombinator.com/item?id=8765714#up_8765979

Zeroed memory should not be particularly expensive on modern machines, because we have a lot of parallelism available to zero it off working threads. There might be some constraint on memory bandwidth, but IMO memory latency is a bigger issue, usually preventing maximizing memory throughput, so there should be some spare.

The danluu link doesn't really support your argument. Yes, the checks aren't free, but they aren't very costly either in practice, and much of the cost is down to C compilers not being optimized for generating range-checking code.

I feel you're also possibly missing a longer term feedback loop issue. When software starts relying on things like overflow checks and zeroed memory, hardware manufacturers like Intel start building and optimizing hardware to make them faster.

The "prefer performance over correctness" bias that's existed in the C world has been responsible for a lot of damage. We need to get out of it.

Zeroing memory is certainly not free, and if you're doing some types of real-time applications, can have a significant cost.

http://randomascii.wordpress.com/2014/12/10/hidden-costs-of-...

If the compiler could prove you never read an array element before writing (like it is most of the time in Java, and should be all of the time in C), it could optimize the entire zeroing step away. Java does this very often. And initializing your variables close to the point of declaring them is a good practice in C anyways, which should make it easy for the compiler to analyze.

But if zeroing memory is necessary for the program to be correct, hang the cost. I don't know what sort of "real time applications" would require gambling on the initial state of memory.

If you really can't afford to use dynamic memory, don't. 'C' will cheerfully allow you to hog as much as you want outside the heap.

> But if zeroing memory is necessary for the program to be correct, hang the cost.

Sure. And your application should bear that cost and not necessarily every application written in C. Maybe there is a case for using a safer malloc implementation for your program?

> I don't know what sort of "real time applications" would require gambling on the initial state of memory.

This isn't really gambling. If you know you are going to initialize the memory with sane values immediately (and this is a common practice), it is a waste to do that initial zeroing.

Ah - in that case, I'd agree. I couldn't draw to that conclusion from the text provided - that's just as good as zeroing ( and, as you say ) renders the zeroing moot.

> Zeroed memory should not be particularly expensive on modern machines, because we have a lot of parallelism available to zero it off working threads.

It must be nice living a world where energy is free, you have unlimited cores and unbounded caches, and context switches, thread synchronisation and cache coherence have no cost or latency.

I'm not saying that reducing the number of cases with undefined behaviour isn't worth it in most cases, but claiming that you can just zero application memory at virtually no cost on a multicore is misguided.

> Zeroed memory should not be particularly expensive on modern machines, because we have a lot of parallelism available to zero it off working threads.

If your plan is to use other threads to zero the memory, then your malloc() implementation needs to move every freed region into a thread-safe queue to be zero'd and wait for the other thread to pick it up before the memory is eligible to be allocated again. This adds synchronization costs, creates opportunities for false sharing, and introduces starvation issues.

Also, there are applications that genuinely peg all CPUs already. In these cases, this approach makes even less sense because there is no spare CPU sitting around, so you pay the overhead for no actual parallelism.

> When software starts relying on things like overflow checks and zeroed memory, hardware manufacturers like Intel start building and optimizing hardware to make them faster.

I'm pretty sure Intel already has plenty of incentive to make memset(ptr, 0, n) fast. Also I'm not sure how overflow checks could be made much faster, except maybe to create an entirely separate set of integer instructions that raise hardware exceptions on overflow. Maybe that would be worthwhile, I don't know.

> The "prefer performance over correctness" bias that's existed in the C world has been responsible for a lot of damage. We need to get out of it.

The "correctness checks are free because we want them to be" bias that exists in other languages has been responsible for a lot of languages and runtimes that are "nice" but that no one could actually write a competitive web browser (for example) in.

Maybe no-one really tried hard enough? The correctness checks are not a problem for server-side software, so I guess they are not the primary reason for not having a web-browser written in those nice languages, but something else (like historical reasons).

>> Modern CPUs are so superscalar internally that an overflow check (which doesn't get flagged most of the time anyway) doesn't add anything to the execution speed.

> "Doesn't add anything" is not correct. These checks are not free:

This statement was in regard to what happens inside the CPU. What happens on the level of the individual compilers is still a problem as we only see about now that the compilers are starting to optimize those cases.

In that regard we don't know yet the true costs of those checks but time will tell.

> This statement was in regard to what happens inside the CPU.

In that regard, the statement is still incorrect. The link I posted above analyzes the cost at the CPU level given the optimal machine code. It estimates an upper bound of a 2x overhead per overflow-checked add. ie. not free.

>the optimization step to not initialize those variables that are written to before used doesn't seem so far away

Determining whether or not variables will be used uninitialized is equivalent to solving the halting problem.

In general case only. For most of typical code, it is quite obvious.

If your program makes initialization depend on many conditions which makes it hard to analyze for the compiler, you're probably writing very fragile code that will soon bite you with UB.

> For most of typical code, it is quite obvious.

[citation needed]

> If your program makes initialization depend on many conditions which makes it hard to analyze for the compiler, you're probably writing very fragile code that will soon bite you with UB.

Say you allocate a stack, and access it with the following pattern:

    bool push(stack *st) {
      if (st->top == st->limit) return false;
      st->top++;
      st->top->foo = FOO_INIT;
      st->top->bar = BAR_INIT;
      return true;
    }

    void pop(stack *st) {
      assert(st->top != st->stack);
      st->top--;
    }

    void stack_alloc(stack *st, int n) {
      st->stack = malloc(n * sizeof(*st->stack));
      st->top = st->stack;
      st->limit = st->stack + n - 1;
    }

If you only access the stack through st->top, it is easy to see (for a human) that the stack will never be accessed uninitialized. Good luck getting the compiler to build an inductive proof of that though.

This is just the first example that popped into my mind because I was doing this yesterday.

I said most, not every.

  int x;
  ....
  x = 5;
  printf("%d\n", x);

Anyway, in you code the cost of malloc is a lot higher than the cost of zeroing out. And I guess most of the time it is hard to elide variable initialization would be in places where you have non-local variable use and you do heap allocation.

> Anyway, in you code the cost of malloc is a lot higher than the cost of zeroing out.

You can't possibly know that. The cost of malloc() is (roughly) independent of the size of the memory, and the cost of zeroing it is linear in the size of the memory. So there's an inflection point where zeroing the memory becomes more expensive than the malloc() itself.

Point taken, however in practice this point is quite high to not matter that much. At least in these benchmarks zeroing out is typically responsible for less than 10% of total time overhead, and this including the fact the benchmarked VMs didn't do any zeroing-out elision:

http://www.cs.utexas.edu/users/mckinley/papers/zero-oopsla-2...

I was mostly talking about general variable initialization, not just huge arrays - and for any case "hard" like yours (but actually not impossible to elide; state-machines and inductive proofs are not a rocket surgery) - you've got several trivial cases like I posted above which can be solved by simple local data-flow analysis.

This is the same like with NP-hard problems. Some people get scared by NP-hard, but it only matters if you need an exact solution, and is not a problem in practice if you're ok with a result at 0.95 of the optimum.

It is also sometimes more time-effective to reuse huge arrays to work around obligatory variable initialization done by the runtime for rare cases where it would be a performance problem, than to fight UBs in 10s of other places where performance doesn't matter.

Not if you can initialize them at the time of declaration. IMO, that should be the default policy, and there should be ample comments apologizing for not doing it.

People don't build unterminated communications lines nor use PIO without pullups/pulldowns. Programmers should be the same way.

Perhaps I've led a charmed life, but I've never seen a case where proper initialization was a problem.

Reply on news.ycombinator.com