Announcing Chapel 1.24.0!

Dear Chapel community –

We’re proud to announce the release of Chapel version 1.24 today!

This release continues our push towards a future Chapel 2.0 release, by:

  • significantly improving the syntax and semantics of operator overloads
  • clarifying the relationship between various ways of converting between types
  • improving the ergonomics of nilable class checks within conditionals and while-loops
    (e.g., if const obj = foo() then obj.bar(); ensures obj is non-nilable)
  • improving the definition and handling of tertiary methods
  • unifying the handling of out intents and return statements
  • adding initial support for constrained generic interfaces

In addition, we've deprecated implicit reads and writes of sync and single variables, in favor of explicit methods like .readFE() and writeEF().

From a performance perspective, Chapel 1.24.0 contains some nice improvements. We've:

  • improved the performance of --cache-remote and enabled it by default
  • added a new opt-in --auto-aggregation optimization that combines communications
  • improved the generality and reporting for the --auto-local-access optimization
  • improved performance of scan operations for a number of 1D array cases
  • improved compile times for programs that make heavy use of zippered forall-loops

Some other niceties in this release include:

  • support for Chapel syntax highlighting in the geany editor
  • significant portability and performance improvements for ofi-based communication
  • significant improvements to the LLVM-based compiler back-end
  • closing the last known cases of memory leaks from Chapel 1.23

We have also upgraded our code base to make better use of Python 3, and to make better choices with respect to default launchers.

For a more complete list of changes, including pointers to supporting documentation, please refer to CHANGES.md .

To download and install the release, see: Chapel: Download.

And for a list of everyone who contributed to Chapel 1.24, please refer to CONTRIBUTORS.md.

As always, we’re interested in feedback on how we can make the Chapel language, implementation, libraries, and tools more useful to you and your work.

On behalf of the Chapel project,
-Brad Chamberlain

1 Like

I have yet to try and build LinearAlgebra with 1.24.0,

Is the 'lu' routine within LinearAlgebra able to accept a matrix from
existing user code like

 var A : [1..n, 1..n] real(64);

What allows it to use array subscripts with a domain of

 (0..<n, 0..<n)

without doing a reindexing. How does that work?

What is the overhead of a reindex()?

If 'kron' is given 1-based indices as input, is the result 1-based?

Regards - 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

@damianmoz : Good index-neutral routines won't try to impose their bounds on their input arguments, but will use the input arguments as they stand. For example, if I were writing an "increment" routine for an array, I'd tend to write:

proc increment(A: [?D] ?t) {
  forall i in D do
    A[i] += 1;
}

or:

proc increment(A: [?D] ?t) {
  forall a in A do
    a += 1;
}

or ...(imagine other variants here) rather than:

proc increment(A: [?D] ?t) {
  ref A0 = A.reindex({0..<A.dim(0).size, 0..<A.dim(1).size});
  forall i in 0..<A.dim(0).size do
    for j in 0..<A.dim(1).size do
     A0[i,j] += 1;
}

(say).

If I did need to operate on A's indices more directly, I'd rely on queries like D.dim(i).low and D.dim(i).high to compute on A using its natural indices rather than reindexing the array to fit my preferred indexing mode.

I assume that the LinearAlgebra module takes a similar approach, but would need someone else closer to the package to validate that assumption (where @ben-albrecht or @mstrout might be good candidates).

-Brad

Good index-neutral routines won't try to impose their bounds on their input arguments, but will use the input arguments as they stand.

This is a design goal of the LinearAlgebra module. However, not all linear algebra functions fulfill this criteria yet. In Chapel 1.23, some functions always returned 1-based indexed array or would only accept 1-based indexed arrays as input arguments. In Chapel 1.24, some of those functions were updated to be index-neutral, but many were simply updated to expect / always return 0-indexed arrays instead. Taking a peek at the source, it looks like lu is one of the functions that assumes 0-based indexing in 1.24. kron is index-neutral w.r.t. arguments, but always returns a 0-indexed array in 1.24. It remains an ongoing effort to update the remaining functions in LinearAlgebra to be index-neutral w.r.t. arguments and returns.

Quoting from the DIscourse post by @brad immediately before the most recent,

Good index-neutral routines will not try to impose their bounds on their input arguments, but will use the input arguments as they stand

I agree. I cannot see this approach in LinearAlgebra but maybe I need to look harder.

I apologise for the slight mis-quote there. I change won't to will not because Discourse goes anti-social with a quote inside a block because it thinks it is a string and starts using red text!

Quoting from the most recent Discourse post of @Ben

This is a design goal of the LinearAlgebra module.

Quoting from the most recent Discourse post again,

This is a design goal of the LinearAlgebra module.

Actually, that is a mandate as per the original concepts of the email from @bradcray of 5th Nov 2019 with the subject Should Chapel use 0-based indexing for tuples, strings, etc. Part of the email talks about Indexing cases that won't need to change:

The "in cases where the language chooses..." qualification above is crucial
because the most common places in Chapel that deal with indexing require the
programmer to specify low and high bounds:

* ranges (e.g., `0..n-1` vs. `1..n` vs. `-3..3`)

* domain values (e.g., `{1..n, 0..n-1, -3..3}`)

* array types (e.g., var `A: [1..n, 0..n-1, -3..3] real;`)

Such cases would not require any changes in user code if we were to make the proposed change.

In that same Nov 2019 email (and its correction), there was mention that

array types inferred from literals (e.g., var A = ["hi", "there"];  results in A having type [1..2] string today; in the proposal, it  would have type [0..1] string)

There was no mention that Chapel was zero-based across the board, only that a base of would be the default where array bounds were to be inferred from a declaration. In fact, I can still do

var A : [1..2] string = [ "hi", "there" ];

and things should still work.

Quoting from the most recent Discourse post,

In Chapel 1.24, some of those functions were updated to be index-neutral, but many were simply updated to expect / always return 0-indexed arrays instead.

Again it is counter to the mandate. It breaks existing code.

Taking a peek at the source, it looks like lu is one of the functions that assumes 0-based indexing in 1.24. kron is index-neutral w.r.t. arguments, but always returns a 0-indexed array in 1.24.

That is the worst of both worlds. It breaks everybody's code. See also my comments below about a reindex such as exists in kron.

It remains an ongoing effort to update the remaining functions in LinearAlgebra to be index-neutral w.r.t. arguments and returns.

Can you point me at any index-neutral approach in the existing LinearAlgebra routines? I am struggling to find them. Things like a reindex are not an index neutral approach in my humble opinion but others may have differing views.