Hacker News Reader

Comment by barrkel | Hacker News Reader

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.

View on HN

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

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.

Reply on news.ycombinator.com