Hi Damian --
Good question. I don't have a ton of intuition here, but let me make some
notes and see where that leads us:
* First, it's important to know that in its preferred configuration,
Chapel uses jemalloc as its memory allocator, which should yield
better malloc/free performance than using the system allocator.
That said, allocating and freeing memory (to say nothing of initializing
arrays) is still not free.
* Next, it's good to know that slicing arrays (accessing them with a range
or group of ranges to refer to a sub-array) is somewhat expensive as
well.
Stylistically, I think I prefer taking the approach of putting the xcoli
array into the loop to make its scoping and purpose clear to a human
reader if not to an optimizer. But I can't estimate how the costs above
would compare to one another (and they may vary from one system to the
nexet), so can't make a guess as to what impact it would have on
performance.
A couple of other notes here:
* Given an array declaration like `var A: [1..n] [1..3] real;`, there's
been some confusion at points in the language's history about what
indexing a slice expression should do: `A[2..n-1][2]` (in fact, you
may have been involved in some of these conversations in the past?)
- one intuitive interpretation is to say that '2..n-1' refers to the
outer dimension and '2' to the inner, so this would give a conceptual
(n-2)-element array of reals.
- however, the interpretation taken in the language today is different:
it says that the expression `A[2..n-1]` is virtually an array like
any other and can therefore be indexed like any other array. As a
result, `A[2..n-1][2]` is essentially equivalent to `A[2]`, resulting
in a `[1..3] real` element. Another way of viewing this is that if I
were to do:
var tmp = A[2..n-1]; // or `ref tmp = ...`
...tmp[2]...
I think there's arguably no question what should happen, so
essentially writing it all as one expression should do the same thing.
The main downside being that it's a common point of confusion (so
maybe the compiler could/should issue a warning in such cases?)
This issue is batted about a bit here:
https://github.com/chapel-lang/chapel/issues/5568
and would be a good place to add comments on the issue. I thought it
was particularly interesting that this wasn't an area where we could
learn from Fortran 90 because it apparently doesn't support arrays of
arrays (which was itself surprising to me).
One way to work around issues like this is to use a multidimensional
array instead of an array of arrays. Sometimes this is appropriate /
reasonable, sometimes not. For codes that really want/need to use an
array of arrays, another workaround would be needed.
* If you did go with your first approach and your code used xcoli[R] a
lot, you'd probably want to either:
- declare a reference to that slice to avoid recomputing it again and
again, as in:
ref xcoliSlice = xcoli[R];
- or, pass xcoli[R] into a routine such that you can just refer to it
via the formal argument name (essentially equivalent to the above,
but has the tradeoff of introducing a procedure where maybe you
don't want/need one).
Hope this is helpful,
-Brad
On Mon, 17 Dec 2018, Damian McGuckin wrote:
Hi Chaps,
Does declaring space and then only refering to slices thereof
var xcoli : [1..n] real;
for i in 1..n do
{
var R = i..m;
xcoli[R] = x[R][i];
// code which always refers to just xcoli[R]
// so as to only use the slice over i..m
}
put as much load on the run-time as the alternative which allocate space each
time through the loop, i.e. like
for i in 1..n do
{
var R = i..m;
var xcolii = x[R][i];
// code can simply refer to xcoli because
// it is by definition the slice over i..m
}
Then again, does the restricted scope of xci in the second example make it
easier for a future optimizer.
One can also argue that the restricted scope makes it easier for a reader of
a program or even a verification tool. However, instantiation of lots of
space allocations and copies will often be prohibitive.
Thanks - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
