Hi Richard —

Sorry for the delayed response, it's release season here (to wit: I started the day thinking "I'm going to reply to Richard's message first thing and here I am trying to sneak a response under the wire).

Let me start with the easy question first. I think the 1.21 upgrade problem you're running into is the following entry from the CHANGES.md file:

- made `use` private by default ...

Specifically, given a pattern like the following:

        module M {
          use Time;
        }

        module N {
          use N;
          ...Time.<something>...
        }

It used to be the case that the `use Time;` in M was considered "public" which meant that anything that used M would also see Time's symbols as well. As of Chapel 1.21, `use` statements are private, intended to prevent symbols from leaking throughout a code base in an undisciplined manner. The two ways to fix this would be to change the use back into
a public use:

        module M {
          public use Time;  // override the private default
        }

        module N {
          use N;
          ...Time.<something>...
        }

or to put another `use` into N itself:

        module M {
          use Time;
        }

        module N {
          use N, Time;
          ...Time.<something>...
        }

Either of these are valid, and the choice will probably depend on whether, logically, you'd like everything that uses M to have immediate access to Time's symbols or to have those modules state their reliance on Time themselves.

This has already gone on a bit long, so let me get to your other question in a distinct mail.

-Brad



On Mon, 13 Apr 2020, Barrett, Richard F via Chapel-users wrote:

Folks,

I have some questions regarding the use and subsequent performance of dmap. I’m 
doing some simple vector computations (add, scale, reduce), with the vectors 
defined in a record:

record RVectorRB { // Real valued vector.

   var dom = {1..num_vertices} dmapped Block ( boundingBox={1..num_vertices} );

   var val : [dom] real;
}

Instantiated as this:    var v1 : RVectorRB; , with num_vertices config const.

For RVectorRB vectors b, p, and z, reductions look like this:

  forall i in b.dom with ( + reduce bnrm2 ) {
     bnrm2 += b.val[i] * b.val[i];
  }

Vector updates : p.val = z.val + beta*p.val;   // beta real scalar.

Performance on 2 locales (2 nodes of a Cray XC30, 2x16 Haswells) is 44x slower 
than 1 locale/node. Further, when I comment out the dmap, single node runs 3x 
faster than with it. Vector lengths 1k up to 100M elements.

This is with v1.20. When I tried to compile with v1.21, I get these errors:

%  chpl main.chpl
main.chpl:12: In function 'main':
main.chpl:49: error: Attempt to 'new' a function or undefined symbol
main.chpl:59: error: 'timings' undeclared (first use this function)
main.chpl:61: error: 't' undeclared (first use this function)
main.chpl:63: error: 'TimeUnits' undeclared (first use this function)
main.chpl:77: error: 'alg' undeclared (first use this function)

'new' is for instantiating a record, alg is my enumeration, and I'm "using" 
Chapel's Time module within a module that's used by my main module which is used by main. 
Checked the release notes but not seeing what's changed. I'm seeing this on the XC as 
well as my Mac (not the homebrew version).

I'd greatly appreciate any help or information regarding any of the above.

Richard
--
Richard Barrett
PO Box 5800, MS-0620
Sandia National Laboratories
Albuquerque, NM 87185
Phone: 505-845-7655
Pager: 505-951-8087



_______________________________________________
Chapel-users mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_chapel-2Dusers&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=U-WL-8YdV3j-zOKUf2QYYqRb5SnBUsgaG03nnhB0ER8&s=WyrpdSULX-IJKEjZ7FFiUXjNk9i6gqxL4E1YABd1rYA&e=
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users

Reply via email to