Zeroing Memory is Hard: VC++ 2015 arrays | Hacker News Reader

Zeroing Memory is Hard: VC++ 2015 arrays

randomascii.wordpress.com

124 pointsdeverton55 comments

Apparently gcc and clang are not fooled by { 0 }, so that's good:

https://twitter.com/areuugee/status/754888773498867712

I'd wager they have an optimization pass that coalesces adjacent constant stores.

Among others. This is likely caught as zero initialisation already in the front-end, before even GIMPLE/LLVM JIT is generated.

At this point we must ask which Update of VS 2015 as MS just replaced the Optimizer with an SSA based one. https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-...

I'm the main developer of the new optimizer. It's a bit too much to say it replaces the old one, it's more of an addition. I was aware of this issue with initializing local arrays, it was on the TODO list - hopefully for the next VS.

I look forward to a fix, especially if the (I think) larger issue of large aggregates not being initialized efficiently is addressed. It feels like it is another instance of the same issue.

I hope the Python script is helpful for finding some of the odd variants that currently exist.

Why isn't the ssa optimizer mentioned in the Update 3 release notes? Is it enabled by default in Update 3?

Are you allowed to respond directly to the author in this case?

There's not much preventing any engineer at Microsoft from talking to developers. No lawyers need to be involved :-)

A good point, but already answered in the article:

> I recently noticed that it’s still an issue in VC++ 2015 Update 3

There's also the Clang/C2 toolchain, an option in the installer.

Clang/C2 doesn't use LLVM, it will use Microsoft's C2 backend.

That may be the case, but whatever the Clang frontend sends to C2 does produce better code than the Microsoft frontend. It probably already folds the stores at the frontend level, instead of leaving it to the backend to figure out.

Also note that you can't zero-initialize an array of objects that don't have a default constructor, and that if you just add an empty default constructor to shut the compiler up, the memory occupied by your array will not be initialized to zero or anything else.

Seems obvious and elementary enough, but it got me good the other day.

If you need to manually define a default constructor, and you want the behavior of default-initializing all members, declare the constructor as:

    T() = default;

If you want to feel some real pain ... take the following code (simplified for posting in this thread):

    template<typename T> struct Function {
      Function() = default;
      void* callback = nullptr;
    };

    struct CPU {
      Function<void ()> functions[65536];  //= {0} makes no difference
    };

    int main() {
      CPU cpu;
      return 0;
    }

There's a bug in GCC, at least versions 5.1 - 5.4, where the above code will take 30s-90s to compile (depends on your CPU speed), and eat 500MB+ of RAM in doing it. But the bug isn't in 4.9, and possibly newer GCC releases.

What causes it? "Function() = default;" of course. Change it to "Function() {}" and the code compiles in 100ms.

So because I can't tell people, "don't use GCC 5.x", or "don't ever use any of my class objects in a large array", I basically can't use "= default;" syntax on my constructors in any of my library code now :(

Explicitly defaulting the constructor behaves the same as an empty constructor: all members are default-initialized. The problem is usually that 'default-initializing' doesn't zero out primitive (POD) types, but leaves them uninitialized.

With msvc the /sdl flag can zero initialize class members to zero[1] (among other things). This runs before the constructor. Aside from the warnings that get turned into errors (you can disable the warning to bypass this behavior) it also does limited pointer sanitization and turns on strict_gs_check.

[1] https://msdn.microsoft.com/en-us/library/jj161081.aspx

The problem is usually that 'default-initializing' doesn't zero out primitive (POD) types, but leaves them uninitialized.

Exactly, that's what hosed me. Some double-precision floats ended up with garbage values and I couldn't see how it was happening.

Explicitly using the T(), T{}, T = {} syntax will value-initialize the object, which will zero-initialize trivially constructible types.

Ah, interesting. Apparently this is true even if some constructors are explicitly '= default' (for the T x{} and T x={} list/aggregate initialization cases only).

But I believe that rule doesn't apply for any objects where adding an '= default' constructor would be useful, because it requires that there be no user-defined constructors or private/protected members. Otherwise that syntax ultimately calls the default constructor, which won't do any zeroing.

See http://en.cppreference.com/w/cpp/language/aggregate_initiali...

Yes, forgot to mention this crucial detail.

If you ask the compiler to optimise for size you should really be getting a REP STOS for anything that needs more than the ~3 instructions which that takes.

(It's not the fastest way for small sizes --- it actually is for larger sizes, just like REP MOVS --- but the user asked for smaller, not faster code.)

Bruce, thanks for the kick! Six years is a long time to wait for a bug resolution.

It turns out that our compiler has a minimum size limit in a memset optimization. I’m sure the size limit was there for a Very Good Reason (TM) at one point in time, but we are investigating whether we can remove it. Step one is understanding why it was there in the first place.

= { 0 } is an "initialize almost anything" idiom in C; it's worth recognizing specially in a compiler.

Far worse is trying to grow a std::vector with a std::vector.resize() and subsequently trying to opt out of array intialization.

Most STL containers with the default allocator will always initialise memory (some, like std::array, don't iirc). That's a feature. If you don't want it, then you'll have to use your own allocator or container. Both bring changes throughout the codebase, unfortunately.

> Both bring changes throughout the codebase, unfortunately.

That's where auto often helps. Lets you change types as long as you don't break the interface.

Then you might need std::vector::reserve() instead.

But reserve() doesn't work if you are going to fread() into the buffer or otherwise fully initialize it. std::vector<char> basically requires you to double-initialize the buffer if you pass it to a function that just needs a raw pointer to fill, which can be an issue in some high-performance contexts.

I hit this in a game server where a few percent of CPU time (that was enough to count as low-hanging-fruit) was being spent on memset inside of resize().

Yes I am in proecisely this situation. It made me realize how political the c++ std library authorship is.

What was the solution? Using a custom allocator?

I am not OP, but you could get around it by having a default constructor that is empty. This might've not been possible if you need a different default constructor that initializes values.

In my case the fix was to not allocate so much space. The vector was always being resized to 64 KiB. After considering lots of other options I decided that the most pragmatic fix was just a smaller constant to the vector constructor. I don't remember why the other options weren't practical.

Yes you could use a custom allocator except that changes the type of the std::vector - making a large ripple in our code base.

I have not solved it yet. The best solution - don't use std::vector for anything critical.

A simple new int[] will work. It doesn't initialize the array (unlike the new int[]() version).

You can use it with std::unique_ptr<> to simplify memory management.

This is true but at least with the current standard you will want to define a custom deleter with your unique_ptr to implement "delete [] data" vs the default behavior of "delete data".

Using a custom allocator is the standard-blessed solution for this problem, although it can be inconvenient.

Reply on news.ycombinator.com