I'd missed this post on reddit:

http://www.reddit.com/r/programming/comments/30wj8g/managing_cs_complexity_or_learning_to_enjoy_c/cpx41ix

On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright wrote:
> D is just another of those “Let's put everything on the heap”-languages that do then of course need GC.

what's up with people constantly equating garbage collection to being the same as java?

On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright wrote:
> I'd missed this post on reddit:
>
> http://www.reddit.com/r/programming/comments/30wj8g/managing_cs_complexity_or_learning_to_enjoy_c/cpx41ix

Thanks for the mention. I must have forgotten some. I should put in in a d-idioms anyway.

I didn't appreciate how important default initialization was before having to fix a non-deterministic, release-only, time-dependent bug in a video encoder some months ago. Just because of 2 uninitialized variables (C++ doesn't require member initialization in constructor). If one of them was _exactly equal to 1_ by virtue of randomness, then it would perform from 0 to 2 billions of motion estimation steps, which is very slow but not a total halt. A watchdog mechanism would detect this and reboot, hence labelling the bug "a deadlock". It would disappear in debug mode since variables would be initialized then.

That gives a totally other meaning to "zero cost abstractions" since in three weeks of investigation I could have speed-up the program by ~5%, much more than the supposed slowdown of variable initialization.

On 4/22/2015 12:51 PM, ponce wrote:
> I didn't appreciate how important default initialization was before having to
> fix a non-deterministic, release-only, time-dependent bug in a video encoder
> some months ago. Just because of 2 uninitialized variables (C++ doesn't require
> member initialization in constructor). If one of them was _exactly equal to 1_
> by virtue of randomness, then it would perform from 0 to 2 billions of motion
> estimation steps, which is very slow but not a total halt. A watchdog mechanism
> would detect this and reboot, hence labelling the bug "a deadlock". It would
> disappear in debug mode since variables would be initialized then.

The default initialization comes from bitter personal experience, much like yours!


> That gives a totally other meaning to "zero cost abstractions" since in three
> weeks of investigation I could have speed-up the program by ~5%, much more than
> the supposed slowdown of variable initialization.

Most of the implicit initializations become "dead stores" and are removed anyway by the optimizer.

On Wednesday, 22 April 2015 at 20:29:49 UTC, Walter Bright wrote:
> On 4/22/2015 12:51 PM, ponce wrote:
>> I didn't appreciate how important default initialization was before having to
>> fix a non-deterministic, release-only, time-dependent bug in a video encoder
>> some months ago. Just because of 2 uninitialized variables (C++ doesn't require
>> member initialization in constructor). If one of them was _exactly equal to 1_
>> by virtue of randomness, then it would perform from 0 to 2 billions of motion
>> estimation steps, which is very slow but not a total halt. A watchdog mechanism
>> would detect this and reboot, hence labelling the bug "a deadlock". It would
>> disappear in debug mode since variables would be initialized then.
>
> The default initialization comes from bitter personal experience, much like yours!
>
>
>> That gives a totally other meaning to "zero cost abstractions" since in three
>> weeks of investigation I could have speed-up the program by ~5%, much more than
>> the supposed slowdown of variable initialization.
>
> Most of the implicit initializations become "dead stores" and are removed anyway by the optimizer.

Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and elide them and
3) Doing the initialisation has a significant performance impact?

The boring example is "extra code causes instruction cache misses".

On Wed, 22 Apr 2015 19:32:46 +0000, weaselcat wrote:

> On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright wrote:
>> D is just another of those “Let's put everything on the heap”-languages that do then of course need GC.
> 
> what's up with people constantly equating garbage collection to being the same as java?

they are ignorant, that's it.

weaselcat:

> On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright wrote:
>> D is just another of those “Let's put everything on the heap”-languages that do then of course need GC.
>
> what's up with people constantly equating garbage collection to being the same as java?

In D you don't put everything on the heap. D is less stack-friendly than Ada (and probably Rust too), but in D you allocate lot of small stuff on the stack.

Bye,
bearophile

On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
> Is it even possible to contrive a case where
> 1) The default initialisation stores are technically dead and
> 2) Modern compilers can't tell they are dead and elide them and
> 3) Doing the initialisation has a significant performance impact?
>
> The boring example is "extra code causes instruction cache misses".

Allocation of large arrays.

On Wednesday, 22 April 2015 at 21:59:48 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
>> Is it even possible to contrive a case where
>> 1) The default initialisation stores are technically dead and
>> 2) Modern compilers can't tell they are dead and elide them and
>> 3) Doing the initialisation has a significant performance impact?
>>
>> The boring example is "extra code causes instruction cache misses".
>
> Allocation of large arrays.

That doesn't really answer the question without some more context. Can you give a specific example where all 3 points are satisfied?

On 4/22/2015 2:58 PM, bearophile wrote:
> D is less stack-friendly than Ada
> (and probably Rust too),

??