4 ms·

I hope it's not mandatory. I'd much prefer static analysis to tell me of use-before-acquire errors: I have a number of hot-inner-loops where initialization nuke

I hope it's not mandatory. I'd much prefer static analysis to tell me of use-before-acquire errors: I have a number of hot-inner-loops where initialization nukes performance.

edflsafoiewq 5y ago
Can you give an example of how initialization nukes performance?
- thechao 5y ago
  In the context I'm thinking of, I have fairly sizable arrays -- up to 512 bytes; usually, only the first few bytes are used (for state tracking); an `int` tells me the high-water mark so the data is only read after being written. The amount of work int the loop is (in almost all cases) only 5 or 6 instructions before termination. Initializing 512 bytes is best case 8 ops, which is >100% overhead. The code is recursive, but bounded to a depth of 8, wity internal linkage (only two `int`s and a pointer are passed) in the tail call position, so the calling convention is just three registers. Even a compiler like q9x, or clang with no opts, produces excellent code. But, even a sniff of initialization tanks perf to the tune of 3x.
  - jcelerier 5y ago
    > Initializing 512 bytes RAII in C++ does not mean that all bytes are initialized, only the ones you want. In struct Foo { int header = 0; float foo; int data[64]; int footer; // just to show that having an explicit constructor / dtor does not change anything Foo(): footer{456} { } ~Foo() { } }; only "header" and "footer" will be initialized: https://gcc.godbolt.org/z/4W1WzfPEv https://gcc.godbolt.org/z/4W1WzfPEv It's not a matter of optimization, absolutely no compiler will zero-initialize unless you explicitely ask for it (or you are in a situation where the language mandates initialization, like global static in C and C++)
    - dataangel 5y ago
      > It's not a matter of optimization, absolutely no compiler will zero-initialize unless you explicitely ask for it Oh man I'm about to ruin your day. Behold the horror: https://stackoverflow.com/questions/29765961/default-value-and-zero-initialization-mess https://stackoverflow.com/questions/29765961/default-value-a...
      - Gibbon1 5y ago
        Well don't know about the parent but you ruined my day. Thing I keep coming back to is the proportion of effort you have to spend learning and keeping up with your tools vs the problem domain your working on. Feels like a big problem with C++ is how much energy the language itself uses up. A friend of mine is, unlike me, really really smart. He likes golang and hates C++. And not like he hasn't spent years professionally writing C++ code. I think the advantage of golang is he can write it reflexively. So all of his attention is on the problem not the language. Me I feel like the problem with C is not so much the language. It's that I'm always worried about stepping off a ledge. Things like defer would help. Because failing to clean up resources is a big problem with C.
        foxfluff 5y ago
        But is failing to clean up transient resources that are only allocated for the duration of one function (or block) really a big problem with C? These tend to be the easiest ones to handle (but admittedly a bit annoying & verbose without defer) and spot if missing. (Also: static analyzers are relatively good at pointing out resources leaked in a single function.) I think most of my functions that allocate a resource only release it on error; otherwise the allocated resource lives on and gets freed later by another function. Defer doesn't help at all here. It just helps with the trivial ones..
        dataangel 5y ago
        The silver lining is that really 99% of the time it just doesn't matter. I just explicitly initialize everything to zero/nullptr (unless I have a specific reason to want a different explicit value), and I only worry about looking up the particular rules if I need them in a situation where I know initialization can be a significant cost like a gigantic array. It is annoying to look up every time that happens but it's not that often.

I hope it's not mandatory. I'd much prefer static analysis to tell me of use-before-acquire errors: I have a number of hot-inner-loops where initialization nukes performance.

edflsafoiewq 5y ago

Can you give an example of how initialization nukes performance?

thechao 5y ago
In the context I'm thinking of, I have fairly sizable arrays -- up to 512 bytes; usually, only the first few bytes are used (for state tracking); an `int` tells me the high-water mark so the data is only read after being written. The amount of work int the loop is (in almost all cases) only 5 or 6 instructions before termination. Initializing 512 bytes is best case 8 ops, which is >100% overhead. The code is recursive, but bounded to a depth of 8, wity internal linkage (only two `int`s and a pointer are passed) in the tail call position, so the calling convention is just three registers. Even a compiler like q9x, or clang with no opts, produces excellent code. But, even a sniff of initialization tanks perf to the tune of 3x.
- jcelerier 5y ago
  > Initializing 512 bytes RAII in C++ does not mean that all bytes are initialized, only the ones you want. In struct Foo { int header = 0; float foo; int data[64]; int footer; // just to show that having an explicit constructor / dtor does not change anything Foo(): footer{456} { } ~Foo() { } }; only "header" and "footer" will be initialized: https://gcc.godbolt.org/z/4W1WzfPEv https://gcc.godbolt.org/z/4W1WzfPEv It's not a matter of optimization, absolutely no compiler will zero-initialize unless you explicitely ask for it (or you are in a situation where the language mandates initialization, like global static in C and C++)
  - dataangel 5y ago
    > It's not a matter of optimization, absolutely no compiler will zero-initialize unless you explicitely ask for it Oh man I'm about to ruin your day. Behold the horror: https://stackoverflow.com/questions/29765961/default-value-and-zero-initialization-mess https://stackoverflow.com/questions/29765961/default-value-a...
    - Gibbon1 5y ago
      Well don't know about the parent but you ruined my day. Thing I keep coming back to is the proportion of effort you have to spend learning and keeping up with your tools vs the problem domain your working on. Feels like a big problem with C++ is how much energy the language itself uses up. A friend of mine is, unlike me, really really smart. He likes golang and hates C++. And not like he hasn't spent years professionally writing C++ code. I think the advantage of golang is he can write it reflexively. So all of his attention is on the problem not the language. Me I feel like the problem with C is not so much the language. It's that I'm always worried about stepping off a ledge. Things like defer would help. Because failing to clean up resources is a big problem with C.
      - foxfluff 5y ago
        But is failing to clean up transient resources that are only allocated for the duration of one function (or block) really a big problem with C? These tend to be the easiest ones to handle (but admittedly a bit annoying & verbose without defer) and spot if missing. (Also: static analyzers are relatively good at pointing out resources leaked in a single function.) I think most of my functions that allocate a resource only release it on error; otherwise the allocated resource lives on and gets freed later by another function. Defer doesn't help at all here. It just helps with the trivial ones..
      - dataangel 5y ago
        The silver lining is that really 99% of the time it just doesn't matter. I just explicitly initialize everything to zero/nullptr (unless I have a specific reason to want a different explicit value), and I only worry about looking up the particular rules if I need them in a situation where I know initialization can be a significant cost like a gigantic array. It is annoying to look up every time that happens but it's not that often.