From owner-hpff Wed Sep 6 05:35:28 1995 Received: by cs.rice.edu (FAA18060); Wed, 6 Sep 1995 05:35:28 -0500 Received: from moe.rice.edu by cs.rice.edu (FAA18054); Wed, 6 Sep 1995 05:35:21 -0500 Received: from gateway.lpac.ac.uk by moe.rice.edu (FAA07326); Wed, 6 Sep 1995 05:35:10 -0500 Received: from nereid.lpac.ac.uk.lpac.ac.uk (nereid [138.37.76.51]) by gateway.lpac.ac.uk (8.6.12/8.6.12) with SMTP id LAA10132 for ; Wed, 6 Sep 1995 11:34:50 +0100 From: Adriaan Joubert Date: Wed, 6 Sep 1995 11:34:49 +0100 Message-Id: <1199.9509061034@nereid.lpac.ac.uk.lpac.ac.uk> To: hpff@rice.edu Subject: hpff: Alignment of a single dimension Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Hello, I am trying to align one dimension of two 2-dimensional arrays, and cannot find a way of expressing this in HPF. The problem is the following PROGRAM MAIN REAL, ALLOCATABLE :: A(:,:), Res(:,:) !HPF$ DISTRIBUTE A(BLOCK,*) !HPF$ DISTRIBUTE Res(BLOCK,*) ... ALLOCATE(A(N,M)) ALLOCATE(Res(N,M*2)) Res = SUB (A) ... CONTAINS FUNCTION SUB (A) RESULT(B) REAL, INTENT(in) :: A(:,:) !HPF$ DISTRIBUTE *(BLOCK,*) :: A REAL :: B(SIZE(A,1),SIZE(A,2)*2) !HPF$ DISTRIBUTE (BLOCK,*) :: B ... END FUNCTION SUB END PROGRAM MAIN So the 1st dimension of B and A in the subroutine will be distributed in the same way. It seems however that compilers can generate faster code, if they know how arrays are aligned with one another. Among other things the compiler would have to know that B is exactly aligned with Res. In other words I would like to add to the main program something like !HPF$ TEMPLATE :: MYTemp(N,M*2) !HPF$ DISTRIBUTE MyTemp(BLOCK,*) !HPF$ ALIGN WITH MyTemp(:,I) :: A(:,I) !HPF$ ALIGN WITH MyTemp :: Res and in the subroutine !HPF$ TEMPLATE :: MYTemp(SIZE(A,1),SIZE(A,2)*2) !HPF$ DISTRIBUTE MyTemp(BLOCK,*) !HPF$ ALIGN WITH *MyTemp(:,I) :: A(:,I) !HPF$ ALIGN WITH MyTemp :: B and then the compiler should be able to figure out that everything is nicely aligned. But I cannot do this, as I do not know N and M at compile time. In this case I could probably get away with definitions !HPF$ ALIGN WITH A(:,*) :: Res(:,*) in the main program and !HPF$ ALIGN WITH A(:,*) :: B(:,*) in the subroutine. The replication of the second dimension would not matter, as it is all on the same processor. But if I have a (BLOCK,BLOCK) distribution for both arrays, but I still want to ensure that all elements in the first section of every column are on the same row of processors, i.e. REAL A(20,20), B(20,40) P1: A(1:10,1:10) P2: A(1:10,11:20) B(1:10,1:20) B(1:10,21:40) P3: A(11:20,1:10) P4: A(11:20,11:20) B(11:20,1:20) B(11:20,21:40) there seems to be no way of telling the compiler about this with a descriptive statement. Well, what about !HPF$ ALIGN WITH A(:,I) :: B(:,I*2-1) !HPF$ ALIGN WITH A(:,I) :: B(:,I*2) But is this legal? And this can be harder to do if the second dimension is (SIZE(A,2)-1)*SIZE(A,2)/2, as in my case. I'd appreciate any help on this one. Understanding the distribution directives seems to get harder the more you know, instead of easier ;-( Adriaan --------------------------------------+------------------------------- Adriaan Joubert | Phone: +44-171-975 5168 London Parallel Applications Centre | Fax: +44-181-981 9803 QMW, Mile End Road | e-mail: A.W.Joubert@lpac.ac.uk London E1 4NS | --------------------------------------+------------------------------- --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 6 12:52:58 1995 Received: by cs.rice.edu (MAA03818); Wed, 6 Sep 1995 12:52:58 -0500 Received: from moe.rice.edu by cs.rice.edu (MAA03806); Wed, 6 Sep 1995 12:52:52 -0500 Received: from frey.riacs.edu by moe.rice.edu (MAA15296); Wed, 6 Sep 1995 12:52:52 -0500 Received: by frey.riacs.edu (8.6.12/1.35) id KAA05595; Wed, 6 Sep 1995 10:56:30 -0700 Date: Wed, 6 Sep 1995 10:56:30 -0700 From: schreibr@frey.riacs.edu (Rob Schreiber) Message-Id: <199509061756.KAA05595@frey.riacs.edu> To: A.W.Joubert@lpac.ac.uk, hpff@rice.edu Subject: Re: hpff: Alignment of a single dimension Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Adriaan Joubert asks: ------------------------------------------------------------------------ I am trying to align one dimension of two 2-dimensional arrays, and cannot find a way of expressing this in HPF. The problem is the following PROGRAM MAIN REAL, ALLOCATABLE :: A(:,:), Res(:,:) !HPF$ DISTRIBUTE A(BLOCK,*) !HPF$ DISTRIBUTE Res(BLOCK,*) ... ALLOCATE(A(N,M)) ALLOCATE(Res(N,M*2)) Res = SUB (A) ... CONTAINS FUNCTION SUB (A) RESULT(B) REAL, INTENT(in) :: A(:,:) !HPF$ DISTRIBUTE *(BLOCK,*) :: A REAL :: B(SIZE(A,1),SIZE(A,2)*2) !HPF$ DISTRIBUTE (BLOCK,*) :: B ... END FUNCTION SUB END PROGRAM MAIN So the 1st dimension of B and A in the subroutine will be distributed in the same way. It seems however that compilers can generate faster code, if they know how arrays are aligned with one another. Among other things the compiler would have to know that B is exactly aligned with Res. In other words I would like to add to the main program something like !HPF$ TEMPLATE :: MYTemp(N,M*2) !HPF$ DISTRIBUTE MyTemp(BLOCK,*) !HPF$ ALIGN WITH MyTemp(:,I) :: A(:,I) !HPF$ ALIGN WITH MyTemp :: Res and in the subroutine !HPF$ TEMPLATE :: MYTemp(SIZE(A,1),SIZE(A,2)*2) !HPF$ DISTRIBUTE MyTemp(BLOCK,*) !HPF$ ALIGN WITH *MyTemp(:,I) :: A(:,I) !HPF$ ALIGN WITH MyTemp :: B and then the compiler should be able to figure out that everything is nicely aligned. But I cannot do this, as I do not know N and M at compile time. In this case I could probably get away with definitions !HPF$ ALIGN WITH A(:,*) :: Res(:,*) in the main program and !HPF$ ALIGN WITH A(:,*) :: B(:,*) in the subroutine. The replication of the second dimension would not matter, as it is all on the same processor. I see you want allocatable templates, a hole in HPF that we know about. But in your case, no template is needed. There is no reason to specify replicationin your alignment. You can use !HPF$ ALIGN A(I,J) WITH RES(I,J) and drop the distribute directive for A in the main program. In the function, you can use a distribute on B and a descriptive alignment of A to B. But if I have a (BLOCK,BLOCK) distribution for both arrays, but I still want to ensure that all elements in the first section of every column are on the same row of processors, i.e. REAL A(20,20), B(20,40) P1: A(1:10,1:10) P2: A(1:10,11:20) B(1:10,1:20) B(1:10,21:40) P3: A(11:20,1:10) P4: A(11:20,11:20) B(11:20,1:20) B(11:20,21:40) there seems to be no way of telling the compiler about this with a descriptive statement. Well, what about !HPF$ ALIGN WITH A(:,I) :: B(:,I*2-1) !HPF$ ALIGN WITH A(:,I) :: B(:,I*2) But is this legal? And this can be harder to do if the second dimension is (SIZE(A,2)-1)*SIZE(A,2)/2, as in my case. No, it's not legal. Align is not a symmetric relation, and the alignment map cannot be many to one unless it collapses a dimension; at least that's my understanding. In case this is not clear, your statement is equivalent to !HPF$ ALIGN B(:,2*I-1) WITH A(:,I) which only explicitly aligns the odd numbered columns of B! But why align the bigger of the two arrays (B) with the smaller (A)? My version of SUB would be: FUNCTION SUB (A) RESULT(B) REAL, INTENT(in) :: A(:,:) REAL :: B(SIZE(A,1),SIZE(A,2)*2) !HPF$ ALIGN *(I,J) WITH B(I,J) :: A !HPF$ DISTRIBUTE B (BLOCK,*) I'd appreciate any help on this one. Understanding the distribution directives seems to get harder the more you know, instead of easier ;-( Yup. Rob --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Fri Sep 8 12:40:09 1995 Received: by cs.rice.edu (KAA18362); Fri, 8 Sep 1995 10:50:41 -0500 Received: from mailhub.liverpool.ac.uk by cs.rice.edu (KAA18357); Fri, 8 Sep 1995 10:50:36 -0500 Received: from chad2-13.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Fri, 8 Sep 1995 16:50:16 +0100 From: "Dr A.C. Marshall" Message-Id: <199509081550.QAA25751@chad2-13.liv.ac.uk> Subject: Re: hpff: Alignment of a single dimension To: hpff@cs.rice.edu Date: Fri, 8 Sep 1995 16:50:10 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5195 Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Can I continue this discussion for one more iteration? Good then I'll begin. As I understand it Adriaan Joubert wants to tell HPF to set the data up as follows: REAL A(20,20), B(20,40) P1: A(1:10,1:10) P2: A(1:10,11:20) B(1:10,1:20) B(1:10,21:40) P3: A(11:20,1:10) P4: A(11:20,11:20) B(11:20,1:20) B(11:20,21:40) I would say (like Rob Schreiber) that you include, in Main, the line !HPF$ ALIGN A(I,J) WITH B(I,J*2-1) or equivalently !HPF$ ALIGN A(:,J) WITH B(:,J*2-1) PLUS (distribute them together) !HPF$ DISTRIBUTE B (BLOCK,BLOCK) And I would claim that the procedure should be coded as follows: FUNCTION SUB (A) RESULT(B) REAL, INTENT(in) :: A(:,:) REAL :: B(SIZE(A,1),SIZE(A,2)*2) !HPF$ ALIGN *(I,J) WITH B(I,J*2-1) :: A !HPF$ DISTRIBUTE *B (BLOCK,BLOCK) If I am wrong - why? Adam In the last mail Rob Schreiber said: | |Adriaan Joubert asks: | | ------------------------------------------------------------------------ | I am trying to align one dimension of two 2-dimensional arrays, and | cannot find a way of expressing this in HPF. The problem is the following | | PROGRAM MAIN | REAL, ALLOCATABLE :: A(:,:), Res(:,:) | !HPF$ DISTRIBUTE A(BLOCK,*) | !HPF$ DISTRIBUTE Res(BLOCK,*) | | ... | ALLOCATE(A(N,M)) | ALLOCATE(Res(N,M*2)) | Res = SUB (A) | ... | CONTAINS | | FUNCTION SUB (A) RESULT(B) | REAL, INTENT(in) :: A(:,:) | !HPF$ DISTRIBUTE *(BLOCK,*) :: A | REAL :: B(SIZE(A,1),SIZE(A,2)*2) | !HPF$ DISTRIBUTE (BLOCK,*) :: B | | ... | END FUNCTION SUB | END PROGRAM MAIN | | So the 1st dimension of B and A in the subroutine will be distributed in | the same way. It seems however that compilers can generate faster code, if | they know how arrays are aligned with one another. Among other things the | compiler would have to know that B is exactly aligned with Res. In other | words I would like to add to the main program something like | | | !HPF$ TEMPLATE :: MYTemp(N,M*2) | !HPF$ DISTRIBUTE MyTemp(BLOCK,*) | !HPF$ ALIGN WITH MyTemp(:,I) :: A(:,I) | !HPF$ ALIGN WITH MyTemp :: Res | | and in the subroutine | | !HPF$ TEMPLATE :: MYTemp(SIZE(A,1),SIZE(A,2)*2) | !HPF$ DISTRIBUTE MyTemp(BLOCK,*) | !HPF$ ALIGN WITH *MyTemp(:,I) :: A(:,I) | !HPF$ ALIGN WITH MyTemp :: B | | and then the compiler should be able to figure out that everything is | nicely aligned. But I cannot do this, as I do not know N and M at compile | time. | | In this case I could probably get away with definitions | | !HPF$ ALIGN WITH A(:,*) :: Res(:,*) | | in the main program and | | !HPF$ ALIGN WITH A(:,*) :: B(:,*) | | in the subroutine. The replication of the second dimension would not | matter, as it is all on the same processor. | |I see you want allocatable templates, a hole in HPF that we know about. |But in your case, no template is needed. |There is no reason to specify replicationin your alignment. You can use | |!HPF$ ALIGN A(I,J) WITH RES(I,J) | |and drop the distribute directive for A in the main program. In the function, |you can use a distribute on B and a descriptive alignment of A to B. | | But if I have a (BLOCK,BLOCK) distribution for both arrays, but I still | want to ensure that all elements in the first section of every column are | on the same row of processors, i.e. | | REAL A(20,20), B(20,40) | | P1: A(1:10,1:10) P2: A(1:10,11:20) | B(1:10,1:20) B(1:10,21:40) | | P3: A(11:20,1:10) P4: A(11:20,11:20) | B(11:20,1:20) B(11:20,21:40) | | there seems to be no way of telling the compiler about this with a | descriptive statement. | | Well, what about | !HPF$ ALIGN WITH A(:,I) :: B(:,I*2-1) | !HPF$ ALIGN WITH A(:,I) :: B(:,I*2) | But is this legal? And this can be harder to do if the second dimension is | (SIZE(A,2)-1)*SIZE(A,2)/2, as in my case. |No, it's not legal. Align is not a symmetric relation, and the alignment |map cannot be many to one unless it collapses a dimension; at least that's my |understanding. In case this is not clear, your statement is |equivalent to | |!HPF$ ALIGN B(:,2*I-1) WITH A(:,I) | |which only explicitly aligns the odd numbered columns of B! |But why align the bigger of the two arrays (B) with the smaller (A)? |My version of SUB would be: | | FUNCTION SUB (A) RESULT(B) | REAL, INTENT(in) :: A(:,:) | REAL :: B(SIZE(A,1),SIZE(A,2)*2) | !HPF$ ALIGN *(I,J) WITH B(I,J) :: A | !HPF$ DISTRIBUTE B (BLOCK,*) | | I'd appreciate any help on this one. Understanding the distribution | directives seems to get harder the more you know, instead of easier ;-( |Yup. | |Rob | | -- | AC Marshall | Computing Services Department, | University of Liverpool, | PO Box 147. | L69 3BX | UK | email: adamm@liv.ac.uk | Tel: 0151-794 3722 | Fax: 0151-794 3759 | --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Sat Sep 9 14:56:36 1995 Received: by cs.rice.edu (OAA29766); Sat, 9 Sep 1995 14:56:36 -0500 Received: from efn.efn.org by cs.rice.edu (OAA29759); Sat, 9 Sep 1995 14:56:31 -0500 Received: from garcia.efn.org by efn.efn.org (4.1/smail2.5/05-07-92) id AA05709; Sat, 9 Sep 95 12:55:32 PDT From: marc@efn.org (Marc Baber) Message-Id: <9509091955.AA05709@efn.efn.org> Subject: hpff: VISUAL NUMERICS JAPAN SIGNS ON AS DISTRIBUTOR FOR APPLIED PARALLEL RESEARCH To: hpff@cs.rice.edu Date: Sat, 9 Sep 1995 12:56:25 -0700 (PDT) Cc: comp-fortran-90@mailbase.ac.uk X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1135 Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- While we at APR are quite pleased to announce our new business relationship with VNIJ, we recognize that this news is of interest primarily to readers of this list in Japan and assorted HPFF/F90 industry analysts and APR fans. Therefore, the full text of the press release is not included here nd can be found at: http://www.infomall.org/apri/ in the "announcements and press releases section". Thank you, ___ _____ _____ __________/==|__|==__=\__|==__=\ Applied Parallel Research, Inc. _________/===|__|=|__\=\_|=|__\=\ 1723 Professional Drive ________/=/|=|__|=|__/=/_|=|__/=/ Sacramento, CA 95825 _______/=/_|=|__|==___/__|====_/_______________________________________________ ______/=___==|__|=|______|=|\=\________________________________________________ _____/=/___|=|__|=|______|=|_\=\_______________________________________________ /_/ |_| |_| |_| \_\ Voice: (916)481-9891 E-mail: support@apri.com FAX: (916)481-7924 APR Web Page: http://www.infomall.org/apri/ ------------------------------------------------------------------------------- --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Mon Sep 11 18:34:42 1995 Received: by cs.rice.edu (RAA09866); Mon, 11 Sep 1995 17:16:38 -0500 Received: from mail.think.com by cs.rice.edu (RAA09838); Mon, 11 Sep 1995 17:16:29 -0500 Received: from Delphi.Think.COM by mail.think.com; Mon, 11 Sep 95 18:16:27 -0400 Received: by delphi.think.com (4.1/Think-1.2) id AA14021; Mon, 11 Sep 95 18:16:26 EDT Date: Mon, 11 Sep 95 18:16:26 EDT Message-Id: <9509112216.AA14021@delphi.think.com> From: Doug MacDonald To: zosel@phoenix.ocf.llnl.gov Cc: hpff@cs.rice.edu In-Reply-To: Mary E Zosel's message of Tue, 15 Aug 1995 16:38:20 -0700 <9508152338.AA15107@phoenix.ocf.llnl.gov> Subject: hpff: July HPFF Meeting Minutes Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Date: Tue, 15 Aug 1995 16:38:20 -0700 From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) High Performance Fortran Forum Meeting July 26-28, Denver Colorado Record of Action: Mary Zosel ... Detailed Record of Action ... David Loveman began the subgroup reports with an overview of the subgroup E (external issues) discussions. Subgroup E meetings addressed a proposal for HPF kernel, a mechanisms to make interoperability between HPF and C/C++ easier, the role of the subset in HPF version 2, whether some features should be removed from the language, a list of tool requirements, and the problems associated with multilevel distributions when an arbitrary configuration involving clusters of SMPs and possibly workstations might exist. The goal of a kernel would be: new code, written well, should perform well high-performance across all platforms no "performance surprises" no runtime overhead no requirement for interprocedural analysis simplified user model (easily understood and taught, commonly used, and valuable for all platforms) For interoperability, issues discussed were: HPF calling C (C++) compiler convert all "basic" types X Windows library as a typical target define a module C_INTERFACE with definitions of Fortran 90 KINDs for C types EXTRINSIC(C) C (C++) calling HPF mapping of function (and module function) names parameter passing pointers structures An ISO group associated with WG5 is also discussing this. Initial contact was made with the group, but the leadership is in the process of changing. Hello, The portion of the July meeting minutes touches on a topic of interest to me: the object and data mapping descriptors used to provide interfaces between HPF routines and subroutines written in a "scalar" language such as C. For instance, given an array A with a given alignment or distribution, a HPF routine might pass A to a C subroutine in the form of a the address of a predefined descriptor object that contains information about the shape, type, layout, etc., of A. Is standardization of such descriptor sets a part of subgroup E's activities? If not, is such an effort underway elsewhere? Thanks, Doug MacDonald Thinking Machines --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Tue Sep 12 16:59:53 1995 Received: by cs.rice.edu (QAA21534); Tue, 12 Sep 1995 16:14:01 -0500 Received: from frey.riacs.edu by cs.rice.edu (QAA21526); Tue, 12 Sep 1995 16:13:53 -0500 Received: by frey.riacs.edu (8.6.12/1.35) id OAA03747; Tue, 12 Sep 1995 14:17:49 -0700 Date: Tue, 12 Sep 1995 14:17:49 -0700 From: schreibr@frey.riacs.edu (Rob Schreiber) Message-Id: <199509122117.OAA03747@frey.riacs.edu> To: macdon@think.com, zosel@phoenix.ocf.llnl.gov Subject: Re: hpff: July HPFF Meeting Minutes Cc: hpff@cs.rice.edu Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- I think that a standard descriptor format would be a good idea, but it should be in the form of a fortran 90 derived type, that can be replicated, for example, and passed as an ordinary parameter to an extrinsic routine; then a library routine would be used to set it up: interface extrinsic (c_local) function c_local_fn(desc) integer c_local_fn type (mapped_array_descriptor) desc end interface type (mapped_array_descriptor) x_desc real, x(100,200) !hpf$ distribute x(block, *) ! ! call an hpf library routne to create the exportable ! array descriptor for x ! x_desc = create_mapped_array_descriptor(x) call c_local_fn(x_desc) --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Tue Sep 12 19:07:12 1995 Received: by cs.rice.edu (TAA29355); Tue, 12 Sep 1995 19:07:12 -0500 Received: from odin.ucsd.edu by cs.rice.edu (TAA29346); Tue, 12 Sep 1995 19:07:07 -0500 Received: from gili.ucsd.edu by odin.ucsd.edu; id AA12171 sendmail 5.67/UCSDPSEUDO.4-CS via SMTP Tue, 12 Sep 95 17:06:58 -0700 for hpff@cs.rice.edu Received: by gili (5.67/UCSDPSEUDO.4) id AA20425 for presberg@tc.cornell.edu; Tue, 12 Sep 95 17:06:51 -0700 From: baden@cs.ucsd.edu (Scott B. Baden) Message-Id: <9509130006.AA20425@gili> Subject: hpff: Descriptors To: schreibr@frey.riacs.edu (Rob Schreiber) Date: Tue, 12 Sep 1995 17:06:51 -0700 (PDT) Cc: macdon@think.com, zosel@llnl.gov, hpff@cs.rice.edu, baden@cs.ucsd.edu (Scott Baden), presberg@tc.cornell.edu In-Reply-To: <199509122117.OAA03747@frey.riacs.edu> from "Rob Schreiber" at Sep 12, 95 02:17:49 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3225 Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Rob, As a follow on to this: what about the converse, that is calling HPF from another languge (e.g. C++)? In this case HPF is viewed as the extrinsic language. This has gotten somewhat bogged down (apparently in part due to leadership changes in the C++ committee), but it would be nice to discuss this next week. I've had some prelimenary discussions with Chuck. It appears that Annex A is a good source of ideas for deriving the facilities that would be needed on the C++ end. (This isn't surprising since we are in effect providing facilities that mirror the HPF-to-external interface) To get the ball rolling. Let's say we have an SPMD program, that is a group of processors (e.g. an MPI communicator) all executing the same program in loosely synchronous fashion. What we need need an etry to initialize the HPF run time system i.e. to identify global processor arrangments. We also need a routine much like your create_mapped_array_descriptor(), with arguments that specify the global shape, the processor array, distribution and alignment and so on. Our SPMD program collectively allocates mapped arrays, collectively calls HPF routines. There would have to be some agreements worked out, i.e. that on entry to an HPF routine from C++ a scalar must have the same value on all processors, (this mirrors the languge in Annex A for calling C from HPF) and that mapped arrays called from C++ would have to promise to match the declarations on the HPF end and so on. We can also support task parallelism, through the use of multiple MPI communicators. Then we could think of multiple SPMD programs calling different HPF routines. Though the facility should work in principle with any language, at this point I would tend to be biased to C++. Comments? Scott > > --------------------------------------------------------------------------- > hpff@cs.rice.edu is a mailing list for announcements related to High > Performance Fortran. Instructions for adding or deleting yourself > from this list appear at the bottom of this message. > --------------------------------------------------------------------------- > > I think that a standard descriptor format would be > a good idea, but it should be in the form of a fortran 90 > derived type, that can be replicated, for example, and passed as > an ordinary parameter to an extrinsic routine; then a library > routine would be used to set it up: > > interface > extrinsic (c_local) function c_local_fn(desc) > integer c_local_fn > type (mapped_array_descriptor) desc > end interface > > type (mapped_array_descriptor) x_desc > real, x(100,200) > !hpf$ distribute x(block, *) > > ! > ! call an hpf library routne to create the exportable > ! array descriptor for x > ! > x_desc = create_mapped_array_descriptor(x) > call c_local_fn(x_desc) > > --------------------------------------------------------------------------- > To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave > the subject line blank, and in the body put the line > (un)subscribe > --------------------------------------------------------------------------- > --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 13 10:24:26 1995 Received: by cs.rice.edu (KAA19330); Wed, 13 Sep 1995 10:24:26 -0500 Received: from mail.think.com by cs.rice.edu (KAA19322); Wed, 13 Sep 1995 10:24:19 -0500 Received: from Delphi.Think.COM by mail.think.com; Wed, 13 Sep 95 11:24:03 -0400 Received: by delphi.think.com (4.1/Think-1.2) id AA21995; Wed, 13 Sep 95 11:24:02 EDT Date: Wed, 13 Sep 95 11:24:02 EDT Message-Id: <9509131524.AA21995@delphi.think.com> From: Doug MacDonald To: schreibr@frey.riacs.edu Cc: zosel@phoenix.ocf.llnl.gov, hpff@cs.rice.edu In-Reply-To: Rob Schreiber's message of Tue, 12 Sep 1995 14:17:49 -0700 <199509122117.OAA03747@frey.riacs.edu> Subject: hpff: July HPFF Meeting Minutes Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Date: Tue, 12 Sep 1995 14:17:49 -0700 From: schreibr@frey.riacs.edu (Rob Schreiber) I think that a standard descriptor format would be a good idea, but it should be in the form of a fortran 90 derived type, that can be replicated, for example, and passed as an ordinary parameter to an extrinsic routine; then a library routine would be used to set it up: interface extrinsic (c_local) function c_local_fn(desc) integer c_local_fn type (mapped_array_descriptor) desc end interface type (mapped_array_descriptor) x_desc real, x(100,200) !hpf$ distribute x(block, *) ! ! call an hpf library routne to create the exportable ! array descriptor for x ! x_desc = create_mapped_array_descriptor(x) call c_local_fn(x_desc) H'mmm... I had assumed that HPF implementations generally passed data mapped array arguments as the address of a descriptor object. The code fragment above seems to assume that the mapped_array_descriptor object doesn't already exist and needs to be created as a preamble to the call to c_local_fn. Why wouldn't HPF simply pass the descriptor address and count on the called routine to examine the descriptor and do what was necessary? This might make sense in the absence of an interface block, or in an interface block containing transcriptive data mappings for x, or in an interface block for certain types of extrinsic function. Doug --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 13 11:22:50 1995 Received: by cs.rice.edu (LAA22052); Wed, 13 Sep 1995 11:22:50 -0500 Received: from alfa.caam.rice.edu by cs.rice.edu (LAA22045); Wed, 13 Sep 1995 11:22:46 -0500 Received: by alfa.caam.rice.edu (LAA06954); Wed, 13 Sep 1995 11:22:43 -0500 Date: Wed, 13 Sep 1995 11:22:43 -0500 Message-Id: <199509131622.LAA06954@alfa.caam.rice.edu> From: "David B. Serafini" To: hpff@cs.rice.edu In-reply-to: <199509122117.OAA03747@frey.riacs.edu> (schreibr@frey.riacs.edu) Subject: Re: hpff: July HPFF Meeting Minutes Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > Date: Tue, 12 Sep 1995 14:17:49 -0700 > From: schreibr@frey.riacs.edu (Rob Schreiber) > Cc: hpff@cs.rice.edu > I think that a standard descriptor format would be > a good idea, but it should be in the form of a fortran 90 > derived type, that can be replicated, for example, and passed as > an ordinary parameter to an extrinsic routine; then a library > routine would be used to set it up: This issue was dealt with at Thinking Machines when the CM Scientific Software Library project got started. In order to make the SSL routines callable from all the CM languages, an internal representation of a distributed array was needed. A structure was developed that contained the necessary info: (rank, bounds, datatype, memory-location, CM-geometry (equivalent to HPF distribution)). It was a hard battle getting all the compiler writers to agree to this, and compromises were made. Maybe somebody involved with the internals of the CMSSL could comment. (Doug? (you brought this up). Is rlk or cal out there?) -David (ex-TMCer) --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 13 13:20:10 1995 Received: by cs.rice.edu (NAA27826); Wed, 13 Sep 1995 13:20:10 -0500 Received: from frey.riacs.edu by cs.rice.edu (NAA27819); Wed, 13 Sep 1995 13:20:04 -0500 Received: by frey.riacs.edu (8.6.12/1.35) id LAA04111; Wed, 13 Sep 1995 11:23:54 -0700 Date: Wed, 13 Sep 1995 11:23:54 -0700 From: schreibr@frey.riacs.edu (Rob Schreiber) Message-Id: <199509131823.LAA04111@frey.riacs.edu> To: baden@cs.ucsd.edu Subject: hpff: Re: Descriptors Cc: hpff@cs.rice.edu, macdon@think.com, presberg@tc.cornell.edu, zosel@llnl.gov Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Scott: Some comments: As a follow on to this: what about the converse, that is calling HPF from another languge (e.g. C++)? In this case HPF is viewed as the extrinsic language. To get the ball rolling. Let's say we have an SPMD program, that is a group of processors (e.g. an MPI communicator) all executing the same program in loosely synchronous fashion. What we need need an etry to initialize the HPF run time system i.e. to identify global processor arrangments. i.e., we need HPF_INIT, which works like MPI_INIT. We also need a routine much like your create_mapped_array_descriptor(), with arguments that specify the global shape, the processor array, distribution and alignment and so on. The question of what NUMBER_OF_PROCESSORS and PROCESSORS_SHAPE should return is indeed interesting. Identifying the called HPF routine with an MPI communicator is appealing; and the caller could endow the communicator with a shape, as well as a size; doesn't MPI have a topology facility for shaping its processors? I think what we need is the inverse of create_mapped_array_descriptor. Something that is an ordinary struct or something in C++ that can be used to describe to the HPF runtime (not the application) the shape and mapping of an array that has been created by the C++ calling routine: subroutine hpf_called_from_extrinsic(x_desc, x) ! ! this routine is called collectively by an extrinsic that has passed in ! both the mapped array X, and a descriptor of this mapped array ! type (mapped_array_descriptor) x_desc real x(:,:,:) ! Use assumed sahpe array call describe_mapped_array_argument(x_desc, x) ! Tell HPF about X We can also support task parallelism, through the use of multiple MPI communicators. Then we could think of multiple SPMD programs or multiple process groups in a single MPI SPMD code calling different HPF routines. Its low level, but it kind of naturally falls out of the idea of hpf called by extrinsic spmd code collectively. Though the facility should work in principle with any language, at this point I would tend to be biased to C++. Lets make it lang independent! We tried to do that with Extrinsics, too. --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 13 13:28:06 1995 Received: by cs.rice.edu (NAA28216); Wed, 13 Sep 1995 13:28:06 -0500 Received: from frey.riacs.edu by cs.rice.edu (NAA28208); Wed, 13 Sep 1995 13:28:01 -0500 Received: by frey.riacs.edu (8.6.12/1.35) id LAA04144; Wed, 13 Sep 1995 11:31:59 -0700 Date: Wed, 13 Sep 1995 11:31:59 -0700 From: schreibr@frey.riacs.edu (Rob Schreiber) Message-Id: <199509131831.LAA04144@frey.riacs.edu> To: macdon@think.com Subject: Re: hpff: July HPFF Meeting Minutes Cc: hpff@cs.rice.edu, zosel@phoenix.ocf.llnl.gov Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Date: Tue, 12 Sep 1995 14:17:49 -0700 From: schreibr@frey.riacs.edu (Rob Schreiber) I think that a standard descriptor format would be a good idea, but it should be in the form of a fortran 90 derived type, that can be replicated, for example, and passed as an ordinary parameter to an extrinsic routine; then a library routine would be used to set it up: interface extrinsic (c_local) function c_local_fn(desc) integer c_local_fn type (mapped_array_descriptor) desc end interface type (mapped_array_descriptor) x_desc real, x(100,200) !hpf$ distribute x(block, *) ! ! call an hpf library routne to create the exportable ! array descriptor for x ! x_desc = create_mapped_array_descriptor(x) call c_local_fn(x_desc) H'mmm... I had assumed that HPF implementations generally passed data mapped array arguments as the address of a descriptor object. The code fragment above seems to assume that the mapped_array_descriptor object doesn't already exist and needs to be created as a preamble to the call to c_local_fn. Why wouldn't HPF simply pass the descriptor address and count on the called routine to examine the descriptor and do what was necessary? This might make sense in the absence of an interface block, or in an interface block containing transcriptive data mappings for x, or in an interface block for certain types of extrinsic function. The reason I had in mind was this: every implementation will want to choose its own particular internal format for a mapped array descriptor; but I would like to write an extrinsic subprogram that will work with any implementation. That is the reason for defining and using a standard "external" descriptor as a fortran derived type. Rob --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 13 15:46:10 1995 Received: by cs.rice.edu (PAA06516); Wed, 13 Sep 1995 15:46:10 -0500 Received: from mail.think.com by cs.rice.edu (PAA06490); Wed, 13 Sep 1995 15:45:53 -0500 Received: from Delphi.Think.COM by mail.think.com; Wed, 13 Sep 95 16:45:48 -0400 Received: by delphi.think.com (4.1/Think-1.2) id AA26366; Wed, 13 Sep 95 16:45:47 EDT Date: Wed, 13 Sep 95 16:45:47 EDT Message-Id: <9509132045.AA26366@delphi.think.com> From: Doug MacDonald To: schreibr@frey.riacs.edu Cc: hpff@cs.rice.edu, zosel@phoenix.ocf.llnl.gov In-Reply-To: Rob Schreiber's message of Wed, 13 Sep 1995 11:31:59 -0700 <199509131831.LAA04144@frey.riacs.edu> Subject: hpff: July HPFF Meeting Minutes Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Date: Wed, 13 Sep 1995 11:31:59 -0700 From: schreibr@frey.riacs.edu (Rob Schreiber) Date: Tue, 12 Sep 1995 14:17:49 -0700 From: schreibr@frey.riacs.edu (Rob Schreiber) I think that a standard descriptor format would be a good idea, but it should be in the form of a fortran 90 derived type, that can be replicated, for example, and passed as an ordinary parameter to an extrinsic routine; then a library routine would be used to set it up: interface extrinsic (c_local) function c_local_fn(desc) integer c_local_fn type (mapped_array_descriptor) desc end interface type (mapped_array_descriptor) x_desc real, x(100,200) !hpf$ distribute x(block, *) ! ! call an hpf library routne to create the exportable ! array descriptor for x ! x_desc = create_mapped_array_descriptor(x) call c_local_fn(x_desc) H'mmm... I had assumed that HPF implementations generally passed data mapped array arguments as the address of a descriptor object. The code fragment above seems to assume that the mapped_array_descriptor object doesn't already exist and needs to be created as a preamble to the call to c_local_fn. Why wouldn't HPF simply pass the descriptor address and count on the called routine to examine the descriptor and do what was necessary? This might make sense in the absence of an interface block, or in an interface block containing transcriptive data mappings for x, or in an interface block for certain types of extrinsic function. The reason I had in mind was this: every implementation will want to choose its own particular internal format for a mapped array descriptor; but I would like to write an extrinsic subprogram that will work with any implementation. That is the reason for defining and using a standard "external" descriptor as a fortran derived type. Rob I'm also interested in the reverse: an SPMD main program written in C or f77 with message passing wants to call a subroutine that was written and compiled in HPF. Either the user doesn't have HPF available in his installation (maybe the HPF routine is part of a subroutine library he purchased from a commercial vendor) or he has some other reason for not wanting to have an HPF main program. Can your proposal also take care of this case? --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 13 16:48:01 1995 Received: by cs.rice.edu (PAA07820); Wed, 13 Sep 1995 15:59:17 -0500 Received: from mail.think.com by cs.rice.edu (PAA07797); Wed, 13 Sep 1995 15:59:04 -0500 Received: from Delphi.Think.COM by mail.think.com; Wed, 13 Sep 95 16:59:02 -0400 Received: by delphi.think.com (4.1/Think-1.2) id AA26423; Wed, 13 Sep 95 16:59:02 EDT Date: Wed, 13 Sep 95 16:59:02 EDT Message-Id: <9509132059.AA26423@delphi.think.com> From: Doug MacDonald To: dbs@caam.rice.edu Cc: hpff@cs.rice.edu In-Reply-To: "David B. Serafini"'s message of Wed, 13 Sep 1995 11:22:43 -0500 <199509131622.LAA06954@alfa.caam.rice.edu> Subject: hpff: July HPFF Meeting Minutes Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Date: Wed, 13 Sep 1995 11:22:43 -0500 From: "David B. Serafini" --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- > Date: Tue, 12 Sep 1995 14:17:49 -0700 > From: schreibr@frey.riacs.edu (Rob Schreiber) > Cc: hpff@cs.rice.edu > I think that a standard descriptor format would be > a good idea, but it should be in the form of a fortran 90 > derived type, that can be replicated, for example, and passed as > an ordinary parameter to an extrinsic routine; then a library > routine would be used to set it up: This issue was dealt with at Thinking Machines when the CM Scientific Software Library project got started. In order to make the SSL routines callable from all the CM languages, an internal representation of a distributed array was needed. A structure was developed that contained the necessary info: (rank, bounds, datatype, memory-location, CM-geometry (equivalent to HPF distribution)). It was a hard battle getting all the compiler writers to agree to this, and compromises were made. Maybe somebody involved with the internals of the CMSSL could comment. (Doug? (you brought this up). Is rlk or cal out there?) -David (ex-TMCer) --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- Hi David! Hope things are going well there. When did you move from NASA Ames to Rice? But I'm not sure what kind of comment you're looking for... yes, we have CMF array descriptors, array geometries, and machine geometries, but their design is nonstandard, somewhat dated, and linked to a number of assumptions CMF makes that don't correspond to HPF. So sharing the details of those could be confusing. Anyhow, I _think_ people know in general what kind of information is included in a mapped array descriptor (tell me if I'm wrong or if you disagree). I got started on this question because I'm working on ways to simulate some aspects of HPF behavior on message-passing platforms. To do this, it helps to have information about an array's location, type, data mapping, etc., in a compact form so they can be referenced as a unit, e.g., in subroutine interfaces. The above will sound very familiar to you, but note that so far I haven't mentioned a global language such as HPF. That's because I want the scheme to work when no global language is present. If one _is_ there, however, I want to be able to call a subroutine written in the global language without a lot of overhead. Of course, the HPFF folks usually think about it the other way around, but a standard extrinsic descriptor (or one per extrinsic language) might be a useful idea going in that direction as well. Doug --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 13 19:09:39 1995 Received: by cs.rice.edu (RAA12447); Wed, 13 Sep 1995 17:30:25 -0500 Received: from odin.ucsd.edu by cs.rice.edu (RAA12399); Wed, 13 Sep 1995 17:30:08 -0500 Received: from gili.ucsd.edu by odin.ucsd.edu; id AA29098 sendmail 5.67/UCSDPSEUDO.4-CS via SMTP Wed, 13 Sep 95 15:23:03 -0700 for macdon@think.com Received: by gili (5.67/UCSDPSEUDO.4) id AA01316 for hpff@cs.rice.edu; Wed, 13 Sep 95 15:22:56 -0700 From: baden@cs.ucsd.edu (Scott B. Baden) Message-Id: <9509132222.AA01316@gili> Subject: Re: hpff: July HPFF Meeting Minutes To: macdon@Think.COM (Doug MacDonald) Date: Wed, 13 Sep 1995 15:22:55 -0700 (PDT) Cc: hpff@cs.rice.edu In-Reply-To: <9509132045.AA26366@delphi.think.com> from "Doug MacDonald" at Sep 13, 95 04:45:47 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 969 Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Doug, This is a subject of another discussion. Rob and I have been chatting about this.. I'm quite interested in calling HPF SPMD code. Have you seen our email? Scott > I'm also interested in the reverse: an SPMD main program written in C or > f77 with message passing wants to call a subroutine that was written and > compiled in HPF. Either the user doesn't have HPF available in his > installation (maybe the HPF routine is part of a subroutine library he > purchased from a commercial vendor) or he has some other reason for not > wanting to have an HPF main program. > > Can your proposal also take care of this case? > --------------------------------------------------------------------------- > To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave > the subject line blank, and in the body put the line > (un)subscribe > --------------------------------------------------------------------------- > --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Thu Sep 14 11:17:42 1995 Received: by cs.rice.edu (LAA12821); Thu, 14 Sep 1995 11:17:42 -0500 Received: from mail.think.com by cs.rice.edu (LAA12807); Thu, 14 Sep 1995 11:17:34 -0500 Received: from Delphi.Think.COM by mail.think.com; Thu, 14 Sep 95 12:17:28 -0400 Received: by delphi.think.com (4.1/Think-1.2) id AA01747; Thu, 14 Sep 95 12:17:27 EDT Date: Thu, 14 Sep 95 12:17:27 EDT Message-Id: <9509141617.AA01747@delphi.think.com> From: Doug MacDonald To: baden@cs.ucsd.edu Cc: hpff@cs.rice.edu In-Reply-To: Scott B. Baden's message of Wed, 13 Sep 1995 15:22:55 -0700 (PDT) <9509132222.AA01316@gili> Subject: hpff: July HPFF Meeting Minutes Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- From: baden@cs.ucsd.edu (Scott B. Baden) Date: Wed, 13 Sep 1995 15:22:55 -0700 (PDT) Doug, This is a subject of another discussion. Rob and I have been chatting about this.. I'm quite interested in calling HPF SPMD code. Have you seen our email? Hi Scott, I don't think I did see it. If it was an ongoing conversation between you two CC'd to hpff-external, I wouldn't have seen it previously to yesterday, when I added myself to that list. I've done some thinking about this as regards HPF 1.0. I would be interested in seeing your earlier remarks and/or proposal, as well as participating in any standardization of these things. Regards, Doug MacDonald Scott > I'm also interested in the reverse: an SPMD main program written in C or > f77 with message passing wants to call a subroutine that was written and > compiled in HPF. Either the user doesn't have HPF available in his > installation (maybe the HPF routine is part of a subroutine library he > purchased from a commercial vendor) or he has some other reason for not > wanting to have an HPF main program. > > Can your proposal also take care of this case? > --------------------------------------------------------------------------- > To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave > the subject line blank, and in the body put the line > (un)subscribe > --------------------------------------------------------------------------- > --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Fri Sep 15 16:20:09 1995 Received: by cs.rice.edu (QAA17663); Fri, 15 Sep 1995 16:20:09 -0500 Received: from wildcat.cs.dartmouth.edu by cs.rice.edu (QAA17652); Fri, 15 Sep 1995 16:20:02 -0500 Received: by wildcat.cs.dartmouth.edu (8.6.12/4.2) id RAA10519; Fri, 15 Sep 1995 17:18:33 -0400 Date: Fri, 15 Sep 1995 17:18:33 -0400 From: dfk@wildcat.cs.dartmouth.edu (David Kotz) Message-Id: <199509152118.RAA10519@wildcat.cs.dartmouth.edu> To: hpff@cs.rice.edu Subject: hpff: Second CFP: Workshop on I/O in Parallel and Distributed Systems Reply-to: IOPADS Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- CALL FOR PAPERS Fourth Annual Workshop on I/O in Parallel and Distributed Systems (IOPADS) in conjunction with the ACM 1996 Federated Computing Research Conference May 27-28, 1996 Philadelphia, PA Co-sponsored by: ACM SIGACT ACM SIGARCH ACM SIGOPS IEEE TCOS In cooperation with: ACM SIGMETRICS In 1996, its fourth year, IOPADS graduates from an informal workshop held in conjunction with IPPS, to a format more like a symposium to be co-located with many others at FCRC '96. The thrust of IOPADS has always been to bring together researchers in all aspects of parallel I/O, which we broadly place into five categories: architecture, algorithms, applications, file and operating systems, and compilers and runtime systems. It is our opinion that the problems of parallel I/O are most effectively addressed by investigating all these areas rather than working in each area in isolation. Although I/O-related papers appear in many other conferences, the value of IOPADS is in gathering interested researchers from all these areas of computer science, encouraging cross-disciplinary interaction, rather than working in each area in isolation. Through ACM Press, IOPADS will publish a formal proceedings, which will be provided to all registrants and will be available for sale at FCRC and afterwards. Papers are invited on related topics, including but not limited to * Experimental characterization of I/O demand * Design and implementation of I/O-intensive applications * Real-time and multimedia I/O * Parallel I/O issues in database systems * Theory and implementation of parallel I/O algorithms * I/O-subsystem architecture * Empirical evaluation of parallel I/O subsystems * Language and compiler support for parallel I/O * Operating-system support for parallel I/O * Concurrent and parallel file systems Papers submitted to IOPADS must be unpublished and must not submitted for publication elsewhere. All papers will be reviewed by a blind referee process, with decisions made by the Program Committee as a whole. The first page, which will be withheld from reviewers, must include only the title, names of all authors, and the telephone number and electronic mail address of the contact author. The text of the paper, including the title and abstract (but no author information) should start on the second page. The manuscript should be at most 20 8.5 x 11 or A4 pages long (including figures, tables, and references but excluding the page withheld from reviewers), typeset with a 10-point font on 20-point spacing, i.e., double spaced. Electronic submission (of PostScript) is strongly encouraged (details available on the Web page below, or contact the Program Chair). For hard-copy submission, send 7 copies of the paper (preferably double-sided) to the Program Chair. All submissions, electronic or hard copy, must arrive by 6 P.M. Eastern Time on October 17, 1995. Decisions will be announced by December 22, 1995. General Chairs David Kotz Thomas H. Cormen Ravi Jain Department of Department of Bellcore Computer Science Computer Science 445 South Street Dartmouth College Dartmouth College Morristown, NJ 07962 Hanover, NH 03755-3510 Hanover, NH 03755-3510 (201) 829-4756 (603) 646-1439 (603) 646-2417 rjain@thumper.bellcore.com dfk@cs.dartmouth.edu thc@cs.dartmouth.edu Program Chair Alok Choudhary ECE Dept., 121 Link Hall Syracuse University Syracuse, NY 13244 (315) 443-4280 choudhar@cat.syr.edu Program Committee Sandra Johnson Baylor, IBM T. J. Watson Alok Choudhary, Syracuse University Tom Cormen, Dartmouth College Denise Ecklund, Intel SSD Garth Gibson, Carnegie Mellon University Charles Koelbel, Rice University David Kotz, Dartmouth College Ethan Miller, University of Maryland, Baltimore County Richard Muntz, UCLA Dan Reed, University of Illinois at Urbana-Champaign Jeffrey Vitter, Duke University John Wilkes, Hewlett-Packard Laboratories David Womble, Sandia National Laboratories For updates and more information, see http://www.cs.dartmouth.edu/iopads/. For general inquiries, send electronic mail to iopads@cs.dartmouth.edu. --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Mon Sep 18 22:41:19 1995 Received: by cs.rice.edu (WAA24483); Mon, 18 Sep 1995 22:41:19 -0500 Received: from moe.rice.edu by cs.rice.edu (WAA24477); Mon, 18 Sep 1995 22:41:14 -0500 Received: from cs.rice.edu by moe.rice.edu (WAA09012); Mon, 18 Sep 1995 22:41:14 -0500 Received: from [128.42.5.149] by cs.rice.edu (WAA24472); Mon, 18 Sep 1995 22:41:09 -0500 Date: Mon, 18 Sep 1995 22:41:09 -0500 X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hpff@rice.edu From: chk@cs.rice.edu (Chuck Koelbel) Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- send documents/sep-95/sep-95-proposals.shar --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Wed Sep 20 01:55:01 1995 Received: by cs.rice.edu (BAA09203); Wed, 20 Sep 1995 01:55:01 -0500 Received: from VNET.IBM.COM by cs.rice.edu (BAA09195); Wed, 20 Sep 1995 01:54:55 -0500 From: zernik@vnet.ibm.com Received: from HAIFA by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8927; Wed, 20 Sep 95 02:54:29 EDT Received: by HAIFA (XAGENTA 3.0) id 0746; Wed, 20 Sep 1995 08:54:45 +0200 Received: by rs250-05.haifa.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA27519; Wed, 20 Sep 1995 08:54:17 +0200 Date: Wed, 20 Sep 1995 08:54:17 +0200 Message-Id: <9509200654.AA27519@rs250-05.haifa.ibm.com> To: hpff-external@cs.rice.edu, hpff@cs.rice.edu Subject: hpff: HPF tools. Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Could anybody provide me some information about tools for HPF? Automatic parallelization, performance tuning, debugging, testing, whatever? Does any of the existing HPF forums relate to these issues? Thnx, Dror --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------