3 ms·

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

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

haberman 12y ago

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

pkolaczk 12y ago
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-2011.pdf 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.