Array Declaration Initialization Overhead

What initialization is there for an array declaration which does not explicitly initialize itself? I fill it explicitly with data during the body of the routine in which it is declared. Thanks.

Hello Damian,

In the absence of explicit initialization or split-initialization, the array is filled initially with zeros, or generally with the default values of its element type. For example:

var A: [1..8] real;  // fills all elements with 0.0
forall i in 1..8 do A[i] = someCalculation(i);

To avoid this implicit initialization, use a for- or forall-expression as an explicit initializer:

var A: [1..8] real = [i in 1..8] someCalculation(i);

How does this look to you?

Thanks for the quick reply. Iwas asking what overhead there is in that initialization to zero, especially in routines which are quite simple.

I often have a routine which defines an array with a non-trivial for loop:

    var x [ 1..n ] : T;

    for i in 1..n do
        // there may be breaks
        x[i] = expression
     assert(all of x[i] is now defined);
     /// blah blah

In such a scenario, the initialization to zero is totally redundant. I wanted to know the overhead because if it is not insignificant, one could argue that there needs to be something like a do-nothing keyword to avoid redundant overhead.

var x [ 1..n] =  postponed:T; // leave until later

I think undef is probably a sub-optimal choice. You could use a word like missing or deferred or delayed but these have meaning already in the context of mathematics, statistics or programming. Irrespective of the word, there should be a warning by the compiler if it thinks the programmer forgot to initialize each element of the array to some value during the course of the routine, even if that is the floating point NaN.

I have been less than successful with my attempts at a split-init. I am not sure whether those attempts were me trying to do something too complex or whether it was just a case of brain-fade on my part.

It is not critical or urgent or a show-stopper. More curiosity, especially if I am trying to track down esoteric performance issues.

Hello Damian,

I expect that the overhead of filling an array with zeros will be as if you wrote:

forall elm in x do elm = 0;

Currently you can avoid default-initializing array elements with noinit as in:

var x: [1..n] T = noinit;

For a larger discussion, see Implement `noinit` for arrays · Issue #15703 · chapel-lang/chapel · GitHub and Add 'noinit' support to initializers · Issue #8792 · chapel-lang/chapel · GitHub


1 Like

Thanks. Likes like exactly what I need. That looks newish. Does that warn me if I am stupid enough to try and use it before I initialize it myself?

It would be great if that is cross referenced in the main array documentation.

See also the noinit technote here: Avoiding Array Element Initialization with noinit — Chapel Documentation 1.33

There is a bunch of work I'd expect we'd want to do on noinit before the spec talks about it itself (and in my opinion it would be unusual for the spec to link to the technote but I think it would be OK)

1 Like