5 ms·

> 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 se

> 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/ http://danluu.com/integer-overflow/ https://news.ycombinator.com/item?id=8765714#up_8765979 https://news.ycombinator.com/item?id=8765714#up_8765979

barrkel 12y ago
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.
- Narishma 12y ago
  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-memory-allocation/ http://randomascii.wordpress.com/2014/12/10/hidden-costs-of-...
  - pkolaczk 12y ago
    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.
  - ArkyBeagle 12y ago
    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.
    - shadowfox 12y ago
      > 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.
      - ArkyBeagle 12y ago
        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.
- lgeek 12y ago
  > 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.
- haberman 12y ago
  > 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.
  - pkolaczk 12y ago
    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).
bhaak 12y ago
>> 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.
- haberman 12y ago
  > 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.

barrkel 12y ago

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.

Narishma 12y ago
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-memory-allocation/ http://randomascii.wordpress.com/2014/12/10/hidden-costs-of-...
- pkolaczk 12y ago
  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.
- ArkyBeagle 12y ago
  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.
  - shadowfox 12y ago
    > 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.
    - ArkyBeagle 12y ago
      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.
lgeek 12y ago
> 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.
haberman 12y ago
> 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.
- pkolaczk 12y ago
  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).

bhaak 12y ago

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

haberman 12y ago
> 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.