Cleaned up C++

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 22 13:36:10 PDT 2015


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


More information about the Digitalmars-d mailing list