New Issue: How can we express "localize this variable only if it is remote"?

18585, "e-kayrakli", "How can we express "localize this variable only if it is remote"?", "2021-10-15T17:53:27Z"

One pattern in remote data copies in Chapel is as follows:

var someArray: [1..n] int;
// populate someArray

on Locales[x] {
  var localSomeArray = someArray; // create a local copy on here

  // do work on localSomeArray 
}

This pattern also comes in the form

var someArray: [1..n] int;
// populate someArray

coforall l in Locales do on l {
  var localSomeArray = someArray; // create a local copy on here

  // do work on localSomeArray 
}

For both of these patterns, but maybe more for the second one, it is possible that we may create a redundant copy of the array on Locale 0. This is bad for performance, especially if you run this with -nl1. It also increases memory footprint on Locale 0 (or wherever someArray resides).

Proposal

This issue asks whether we can have some language feature to express "I want someArray to be local in this scope" or "localize someArray only if it is remote" and let the compiler/runtime copy the data only if necessary.

The approach I can think of involves (1) on intents and (2) some special flavor of intent that expresses this. Here are two alternatives with examples:

a. local intent:

coforall l in Locales do on l with (local localSomeArray) {
  // localSomeArray will be created automatically
  // it'll be copy of `someArray` if it is remote, it'll refer to `someArray` otherwise

  // do work on localSomeArray 
}

b. in? intent:

A variation of local intent. Builds on the idea that this is very similar to in intent, but a copy will be made only if necessary.

coforall l in Locales do on l with (in? localSomeArray) {
  // localSomeArray will be created automatically
  // it'll be copy of `someArray` if it is remote, it'll refer to `someArray` otherwise

  // do work on localSomeArray 
}

Notes/Questions

  • I demonstrated this with array, but it shouldn't be limited to arrays. @mppf noted that this can be useful for strings and bigints.
  • If we were to take up one of these approaches, should they also imply const ?
    • Does it limit the usability of this approach?
  • Or, should these intents be more akin to inout? Is out a weird task-like intent?
  • I also wonder if intent(s) we might add as part of this can be useful for foralls and other places where we can put intents.