17324, "mppf", "programming mode in which communication is decorated?", "2021-03-03T13:53:18Z"
The way that Chapel has implicit communication between locales can be a benefit and a hazard. It is a benefit because code can be more easily adjusted (say, changing the distribution). It is a hazard because when reviewing the code in a performance-critical sections it is not always easy to see where communication occurs.
One answer to seeing where communication occurs is to have tooling (counting, tracing, visualization, etc) that supports easily learning these details about a program. I think such tooling is a reasonable path. However, this issue proposes a different direction.
This issue proposes that the Chapel language include ways to decorate a portion of a program as:
- definitely not communicating, or
- possibly communicating
We already have local blocks for 1. and we could imagine adding a reverse operation - say, as a straw-person - an unlocal block - that indicates that communication is allowed within that region.
So, for example, we might have a loop that performs some communication at the end:
forall i in MyDomain {
local {
A[i] = computeSomething();
var result = computeSomethingElse();
unlocal {
B[f[i]] = result;
}
}
}
Note that, today, local blocks apply to called functions as well as the lexical scope. But sometimes we might want to call a function that does communication that we have identified. Would it be helpful in that case to be able to call a function that does communication if the function uses unlocal inside of it? Or is it better to require that the call site uses unlocal, so that any communication (inside of called functions) is decorated in the kernel?