From zheng.gb@bimp.pku.edu.cn Wed Dec 17 22:25 EST 1997
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id WAA04141; Wed, 17 Dec 1997 22:25:19 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA12427; Thu, 18 Dec 1997 11:19:44 +0800
Date: Thu, 18 Dec 1997 11:19:44 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Zhang Guansong <zgs@npac.syr.edu>
Message-Id: <Pine.HPP.3.91.971218111739.12404A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 264
Status: RO


Hi,

 How can I get the local size of an array from the DAD?


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page:
http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail: 
zhegn.gb@svr.bimp.pku.edu.cn



From zgs@npac.syr.edu Thu Dec 18 10:08 EST 1997
Received: from cairngorm.npac.syr.edu (cairngorm.npac.syr.edu [128.230.117.24]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA10567 for <dbc@postoffice.npac.syr.edu>; Thu, 18 Dec 1997 10:08:33 -0500 (EST)
Received: (from zgs@localhost) by cairngorm.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA09329; Thu, 18 Dec 1997 10:08:15 -0500
From: "Guansong Zhang" <zgs@npac.syr.edu>
Message-Id: <9712181008.ZM9327@cairngorm.npac.syr.edu>
Date: Thu, 18 Dec 1997 10:08:13 -0500
In-Reply-To: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
        "" (Dec 18, 11:19am)
References: <Pine.HPP.3.91.971218111739.12404A-100000@svr.bimp.pku.edu.cn>
X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail)
To: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
Cc: Bryan Carpenter <dbc@postoffice.npac.syr.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 36
Status: ROr

I remember as pcrc_size ?

Guansong

From dbc@npac.syr.edu Thu Dec 18 10:34 EST 1997
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA10933; Thu, 18 Dec 1997 10:34:54 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA01505; Thu, 18 Dec 1997 10:37:42 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199712181537.KAA01505@weed.npac.syr.edu>
Subject: Re: your mail
To: zgs@postoffice.npac.syr.edu (Guansong Zhang)
Date: Thu, 18 Dec 1997 10:37:41 -0500 (EST)
Cc: zheng.gb@bimp.pku.edu.cn, dbc@postoffice.npac.syr.edu
In-Reply-To: <9712181008.ZM9327@cairngorm.npac.syr.edu> from "Guansong Zhang" at Dec 18, 97 10:08:13 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 136
Status: RO


Yes, `pcrc_size' should do it.

Bryan

PS I'm just looking at your `shift' problem.


> 
> I remember as pcrc_size ?
> 
> Guansong
> 


From dbc@npac.syr.edu Thu Dec 18 14:26 EST 1997
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id OAA14505; Thu, 18 Dec 1997 14:26:06 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id OAA01690; Thu, 18 Dec 1997 14:28:25 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199712181928.OAA01690@weed.npac.syr.edu>
Subject: Re: about shift
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Thu, 18 Dec 1997 14:28:24 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter),
        zgs@weed.npac.syr.edu (Guansong Zhang), lxm@[162.105.181.215]
In-Reply-To: <Pine.HPP.3.91.971216091433.24527A-300000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Dec 16, 97 09:49:25 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 6568
Status: ROr


Hi Zheng

I'm copying this to Guansong and Xiaoming because there are some
interesting issues.

The program you enclosed (see below) did core dump when I ran it on
LINUX, but not because of a bug in `shift', just some misunderstanding
about how to use it.

In HPJava notation (which is more understandable, to me) you have,
essentially

  Procs P = new Procs1(4) ;

  Range TMP001 = new BlockRange(4, P.dim(0)) ;

  int [[#]] A = new int [[new BlockRange(4, P.dim(0), 1, 0)]] on P ;
                                // Adds ghost widths 1, 0 to TMP001.

  Index irg0 = new Index(A.rng(0) [1 : 3]) ;

  int [[#]] sdd0 = A [[1 : 3]] ;

  int [[#]] sdd1 = A [[0 : 2]] ;

  int [[#]] tdd1 = new int [[sdd0.rng(0)]] on sdd0.grp() ;
                                // Original fortran didn't copy `sdd0' here.

  HPJlib.shift(tdd1, sdd1, 0, -1) ;

  on(sdd0.grp())
    over(irg0)
      A [irg0] = tdd1 [irg0] ;

This is incorrect use of `shift'.  `shift' assumes its two arrays
arguments are identically aligned, whereas you have alignments offset
by one.  This explains why shift would crash.  Bet even *if* `shift'
relaxed its alignment requirements, it wouldn't do what you want here,
because it is defined to be analogous to the Fortran:

  tdd1 = EOSHIFT(sdd1, 0, -1, ..)

which isn't what you want, because it will lose an end element of
the section.

What you really want is a shift in the *template* array, not the section.
This is provided by `pcrc_tshift'.  (There's no HPJava analogue, because
HPJava assumes you will use the more modern `writeHalo' in this situation).
You should replace

      call pcrc_shift (pcrc_tdd1,pcrc_sdd1,1,-1)

with

      call pcrc_tshift (pcrc_integer_stack(pcrc_tbs1+pcrc_sdx0),pcrc_sdd1,1,-1)

(For obscure reasons, `tshift' doesn't take a DAD for its first argument).

BTW, I guess you realize you have created `A' with ghost regions, although
you aren't using them here.  It will work, but it looks odd.

     ---=+ O +=---

A couple of issues:

1) Guansong has been trying to persuade me there should be a debug mode
for Adlib that adds runtime checks for constraints like alignment
restrictions on arguments of communication functions.  A mode like that
would trap errors like this.

2) This example illustrates how much cleaner the HPJava interface is than
the PCRC Fortran interface.  Really something needs to be done about the
Fortran interface to make it more sane (speaking as the person who mainly
designed that interface...)

Bryan


> 
> On Mon, 15 Dec 1997, Bryan Carpenter wrote:
> 
> > 
> > Hi,
> > 
> >     Sorry about that.  My shift test cases seem to work on our
> > Beowulf.  Can you send me the example that's crashing?  (It makes my
> > life easier you send the C++ equivalent, but HPF source + Fortran
> > generated code will do).
> > 
> > Bryan
> > 
> 
> I use the old shift function in pcrc.C (pcrcFortran)
> 
> void pcrc_shift(int* dad, int* dad_source, int* dim, int* amount) {
>   DAD* ptr    = (DAD*) ad_ToPointer(*dad) ;
>   DAD* srcPtr = (DAD*) ad_ToPointer(*dad_source) ;
> 
>   Shift schedule(ptr, srcPtr, ptr->elementLen, *amount, *dim - 1, EDGE) ;
>   schedule.execute(ptr->data, srcPtr->data) ;
> }
> 
> to perforam the shift.
> I attached a HPF source code and Fortrans code here. 
> 
> Also in the testsuite of Adlib-1.12,
> 	test14.C  Adlib-1.12 . In fact the compiler will complain as:
> test14.C:70: type unification failed for function template `template <int 
> const R, class T> void shift(Section_<...> &, Section_<...> &, int, int, 
> enum Mode)'
> test14.C:71: type unification failed for function template `template <int 
> const R, class T> void copy(Section_<...> &, Section_<...> &)'
> test14.C:76: type unification failed for function template `template <int 
> const R, class T> void shift(Section_<...> &, Section_<...> &, int, int, 
> enum Mode)'
> test14.C:77: type unification failed for function template `template <int 
> const R, class T> void copy(Section_<...> &, Section_<...> &)'
> 
> 
> 
> PS,
> 
> I don't know if you have new version ready so that I can update here.
> 

[Enclosed program text unscrambled from attachments...]

        program try
        
!HPF$   PROCESSORS P(4)
        integer A(4)
!HPF$   DISTRIBUTE A(BLOCK) onto P

        forall (i=2:4) a(i)=a(i-1)

        end

      program try
      integer :: pcrc_dad_A
      integer :: pcrc_sdd0,pcrc_sdd1
      integer :: pcrc_tbs1
      integer :: pcrc_tdd1
      integer :: pcrc_irg0
      integer :: pcrc_lil_i,pcrc_liu_i,pcrc_lis_i
      integer :: pcrc_u00
      integer :: pcrc_v00
      integer :: pcrc_sdx0
      include 'pcrc.inc'
      include 'pcrc_stack.inc'
      integer :: A(0:1)
      integer :: pcrc_rng_TMP000(1)
      integer :: pcrc_grp_P
      integer :: pcrc_shp_P(1)
      call pcrc_init ()
      pcrc_shp_P(1) = 4
      pcrc_grp_P = pcrc_new_group_grid (1,pcrc_shp_P)
      pcrc_rng_TMP000(1) = pcrc_new_range_distribute (1,4,1,pcrc_grp_P,1&
     &)
      pcrc_dad_A = pcrc_new_array_data (A,pcrc_integer,pcrc_size_integer&
     &,1,pcrc_grp_P)
      call pcrc_set_array_align (pcrc_dad_A,1,1,4,1,0,1,0,pcrc_rng_TMP00&
     &0(1))
      pcrc_irg0 = pcrc_new_range_loop (2,4,1,1,0,pcrc_range (pcrc_dad_A,&
     &1))
      call pcrc_loop_bounds (pcrc_irg0,pcrc_lil_i,pcrc_liu_i,pcrc_lis_i)

      pcrc_sdd0 = pcrc_new_array_section (1,pcrc_dad_A)
      call pcrc_set_array_triplet (pcrc_sdd0,1,2,4,1,pcrc_dad_A,1)
      call pcrc_coef (pcrc_dad_A,1,2,4,1,1,0,0,pcrc_u00,pcrc_v00)
      pcrc_sdx0 = pcrc_v00
      pcrc_sdd1 = pcrc_new_array_section (1,pcrc_dad_A)
      call pcrc_set_array_triplet (pcrc_sdd1,1,1,3,1,pcrc_dad_A,1)
      pcrc_tdd1 = pcrc_new_array_section (1,pcrc_dad_A)
      call pcrc_set_array_triplet (pcrc_tdd1,1,2,4,1,pcrc_dad_A,1)
      pcrc_tbs1 = pcrc_integer_alloc (pcrc_size (pcrc_tdd1))
      call pcrc_reset_array_base (pcrc_tdd1,pcrc_integer_stack(pcrc_tbs1&
     &))
      call pcrc_shift (pcrc_tdd1,pcrc_sdd1,1,-1)
      if (pcrc_on (pcrc_group (pcrc_sdd0))) then 
          do  i=0,(pcrc_liu_i-pcrc_lil_i)/pcrc_lis_i,1
            A(pcrc_sdx0) = pcrc_integer_stack(pcrc_tbs1+pcrc_sdx0)
            pcrc_sdx0 = pcrc_sdx0+pcrc_u00
         enddo
       endif
      call pcrc_integer_free (pcrc_tbs1)
      call pcrc_delete_array (pcrc_tdd1)
      call pcrc_delete_array (pcrc_sdd1)
      call pcrc_delete_array (pcrc_sdd0)
      call pcrc_delete_range (pcrc_irg0)
      call pcrc_delete_array (pcrc_dad_A)
      call pcrc_delete_range (pcrc_rng_TMP000(1))
      call pcrc_delete_group (pcrc_grp_P)
      call pcrc_finalize ()
      end program


From zheng.gb@bimp.pku.edu.cn Mon Dec 15 20:55 EST 1997
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id UAA29159 for <dbc@npac.syr.edu>; Mon, 15 Dec 1997 20:54:58 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA25375; Tue, 16 Dec 1997 09:49:26 +0800
Date: Tue, 16 Dec 1997 09:49:25 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>
Subject: Re: about shift
In-Reply-To: <199712151834.NAA24312@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.971216091433.24527A-300000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="2015027970-851401618-882236965=:24527"
Content-Length: 5639
Status: ROr

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--2015027970-851401618-882236965=:24527
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 15 Dec 1997, Bryan Carpenter wrote:

> 
> Hi,
> 
>     Sorry about that.  My shift test cases seem to work on our
> Beowulf.  Can you send me the example that's crashing?  (It makes my
> life easier you send the C++ equivalent, but HPF source + Fortran
> generated code will do).
> 
> Bryan
> 

I use the old shift function in pcrc.C (pcrcFortran)

void pcrc_shift(int* dad, int* dad_source, int* dim, int* amount) {
  DAD* ptr    = (DAD*) ad_ToPointer(*dad) ;
  DAD* srcPtr = (DAD*) ad_ToPointer(*dad_source) ;

  Shift schedule(ptr, srcPtr, ptr->elementLen, *amount, *dim - 1, EDGE) ;
  schedule.execute(ptr->data, srcPtr->data) ;
}

to perforam the shift.
I attached a HPF source code and Fortrans code here. 

Also in the testsuite of Adlib-1.12,
	test14.C  Adlib-1.12 . In fact the compiler will complain as:
test14.C:70: type unification failed for function template `template <int 
const R, class T> void shift(Section_<...> &, Section_<...> &, int, int, 
enum Mode)'
test14.C:71: type unification failed for function template `template <int 
const R, class T> void copy(Section_<...> &, Section_<...> &)'
test14.C:76: type unification failed for function template `template <int 
const R, class T> void shift(Section_<...> &, Section_<...> &, int, int, 
enum Mode)'
test14.C:77: type unification failed for function template `template <int 
const R, class T> void copy(Section_<...> &, Section_<...> &)'



PS,

I don't know if you have new version ready so that I can update here.

Gengbin
--2015027970-851401618-882236965=:24527
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="t9.f"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.HPP.3.91.971216094925.24527B@svr.bimp.pku.edu.cn>
Content-Description: 

CXByb2dyYW0gdHJ5DQoJDQohSFBGJCAgIFBST0NFU1NPUlMgUCg0KQ0KCWlu
dGVnZXIgQSg0KQ0KIUhQRiQgICBESVNUUklCVVRFIEEoQkxPQ0spIG9udG8g
UA0KDQoJZm9yYWxsIChpPTI6NCkgYShpKT1hKGktMSkNCg0KCWVuZA0K
--2015027970-851401618-882236965=:24527
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="t9f.f"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.HPP.3.91.971216094925.24527C@svr.bimp.pku.edu.cn>
Content-Description: 

ICAgICAgcHJvZ3JhbSB0cnkNCiAgICAgIGludGVnZXIgOjogcGNyY19kYWRf
QQ0KICAgICAgaW50ZWdlciA6OiBwY3JjX3NkZDAscGNyY19zZGQxDQogICAg
ICBpbnRlZ2VyIDo6IHBjcmNfdGJzMQ0KICAgICAgaW50ZWdlciA6OiBwY3Jj
X3RkZDENCiAgICAgIGludGVnZXIgOjogcGNyY19pcmcwDQogICAgICBpbnRl
Z2VyIDo6IHBjcmNfbGlsX2kscGNyY19saXVfaSxwY3JjX2xpc19pDQogICAg
ICBpbnRlZ2VyIDo6IHBjcmNfdTAwDQogICAgICBpbnRlZ2VyIDo6IHBjcmNf
djAwDQogICAgICBpbnRlZ2VyIDo6IHBjcmNfc2R4MA0KICAgICAgaW5jbHVk
ZSAncGNyYy5pbmMnDQogICAgICBpbmNsdWRlICdwY3JjX3N0YWNrLmluYycN
CiAgICAgIGludGVnZXIgOjogQSgwOjEpDQogICAgICBpbnRlZ2VyIDo6IHBj
cmNfcm5nX1RNUDAwMCgxKQ0KICAgICAgaW50ZWdlciA6OiBwY3JjX2dycF9Q
DQogICAgICBpbnRlZ2VyIDo6IHBjcmNfc2hwX1AoMSkNCiAgICAgIGNhbGwg
cGNyY19pbml0ICgpDQogICAgICBwY3JjX3NocF9QKDEpID0gNA0KICAgICAg
cGNyY19ncnBfUCA9IHBjcmNfbmV3X2dyb3VwX2dyaWQgKDEscGNyY19zaHBf
UCkNCiAgICAgIHBjcmNfcm5nX1RNUDAwMCgxKSA9IHBjcmNfbmV3X3Jhbmdl
X2Rpc3RyaWJ1dGUgKDEsNCwxLHBjcmNfZ3JwX1AsMSYNCiAgICAgJikNCiAg
ICAgIHBjcmNfZGFkX0EgPSBwY3JjX25ld19hcnJheV9kYXRhIChBLHBjcmNf
aW50ZWdlcixwY3JjX3NpemVfaW50ZWdlciYNCiAgICAgJiwxLHBjcmNfZ3Jw
X1ApDQogICAgICBjYWxsIHBjcmNfc2V0X2FycmF5X2FsaWduIChwY3JjX2Rh
ZF9BLDEsMSw0LDEsMCwxLDAscGNyY19ybmdfVE1QMDAmDQogICAgICYwKDEp
KQ0KICAgICAgcGNyY19pcmcwID0gcGNyY19uZXdfcmFuZ2VfbG9vcCAoMiw0
LDEsMSwwLHBjcmNfcmFuZ2UgKHBjcmNfZGFkX0EsJg0KICAgICAmMSkpDQog
ICAgICBjYWxsIHBjcmNfbG9vcF9ib3VuZHMgKHBjcmNfaXJnMCxwY3JjX2xp
bF9pLHBjcmNfbGl1X2kscGNyY19saXNfaSkNCg0KICAgICAgcGNyY19zZGQw
ID0gcGNyY19uZXdfYXJyYXlfc2VjdGlvbiAoMSxwY3JjX2RhZF9BKQ0KICAg
ICAgY2FsbCBwY3JjX3NldF9hcnJheV90cmlwbGV0IChwY3JjX3NkZDAsMSwy
LDQsMSxwY3JjX2RhZF9BLDEpDQogICAgICBjYWxsIHBjcmNfY29lZiAocGNy
Y19kYWRfQSwxLDIsNCwxLDEsMCwwLHBjcmNfdTAwLHBjcmNfdjAwKQ0KICAg
ICAgcGNyY19zZHgwID0gcGNyY192MDANCiAgICAgIHBjcmNfc2RkMSA9IHBj
cmNfbmV3X2FycmF5X3NlY3Rpb24gKDEscGNyY19kYWRfQSkNCiAgICAgIGNh
bGwgcGNyY19zZXRfYXJyYXlfdHJpcGxldCAocGNyY19zZGQxLDEsMSwzLDEs
cGNyY19kYWRfQSwxKQ0KICAgICAgcGNyY190ZGQxID0gcGNyY19uZXdfYXJy
YXlfc2VjdGlvbiAoMSxwY3JjX2RhZF9BKQ0KICAgICAgY2FsbCBwY3JjX3Nl
dF9hcnJheV90cmlwbGV0IChwY3JjX3RkZDEsMSwyLDQsMSxwY3JjX2RhZF9B
LDEpDQogICAgICBwY3JjX3RiczEgPSBwY3JjX2ludGVnZXJfYWxsb2MgKHBj
cmNfc2l6ZSAocGNyY190ZGQxKSkNCiAgICAgIGNhbGwgcGNyY19yZXNldF9h
cnJheV9iYXNlIChwY3JjX3RkZDEscGNyY19pbnRlZ2VyX3N0YWNrKHBjcmNf
dGJzMSYNCiAgICAgJikpDQogICAgICBjYWxsIHBjcmNfc2hpZnQgKHBjcmNf
dGRkMSxwY3JjX3NkZDEsMSwtMSkNCiAgICAgIGlmIChwY3JjX29uIChwY3Jj
X2dyb3VwIChwY3JjX3NkZDApKSkgdGhlbiANCiAgICAgICAgICBkbyAgaT0w
LChwY3JjX2xpdV9pLXBjcmNfbGlsX2kpL3BjcmNfbGlzX2ksMQ0KICAgICAg
ICAgICAgQShwY3JjX3NkeDApID0gcGNyY19pbnRlZ2VyX3N0YWNrKHBjcmNf
dGJzMStwY3JjX3NkeDApDQogICAgICAgICAgICBwY3JjX3NkeDAgPSBwY3Jj
X3NkeDArcGNyY191MDANCiAgICAgICAgIGVuZGRvDQogICAgICAgZW5kaWYN
CiAgICAgIGNhbGwgcGNyY19pbnRlZ2VyX2ZyZWUgKHBjcmNfdGJzMSkNCiAg
ICAgIGNhbGwgcGNyY19kZWxldGVfYXJyYXkgKHBjcmNfdGRkMSkNCiAgICAg
IGNhbGwgcGNyY19kZWxldGVfYXJyYXkgKHBjcmNfc2RkMSkNCiAgICAgIGNh
bGwgcGNyY19kZWxldGVfYXJyYXkgKHBjcmNfc2RkMCkNCiAgICAgIGNhbGwg
cGNyY19kZWxldGVfcmFuZ2UgKHBjcmNfaXJnMCkNCiAgICAgIGNhbGwgcGNy
Y19kZWxldGVfYXJyYXkgKHBjcmNfZGFkX0EpDQogICAgICBjYWxsIHBjcmNf
ZGVsZXRlX3JhbmdlIChwY3JjX3JuZ19UTVAwMDAoMSkpDQogICAgICBjYWxs
IHBjcmNfZGVsZXRlX2dyb3VwIChwY3JjX2dycF9QKQ0KICAgICAgY2FsbCBw
Y3JjX2ZpbmFsaXplICgpDQogICAgICBlbmQgcHJvZ3JhbQ0KDQoNCg==
--2015027970-851401618-882236965=:24527--

From zheng.gb@bimp.pku.edu.cn Mon Apr 21 21:33 EDT 1997
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id VAA14455; Mon, 21 Apr 1997 21:33:49 -0400 (EDT)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA19861; Tue, 22 Apr 1997 09:27:12 +0800
Date: Tue, 22 Apr 1997 09:27:12 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Guansong Zhang <zgs@npac.syr.edu>
Cc: zheng.gb@ibmrs1.pku.edu.cn, Bryan Carpenter <dbc@npac.syr.edu>
Subject: Re: About configure of Adlib
In-Reply-To: <9704171050.ZM21802@cairngorm.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.970422091521.19413A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1484
Status: RO

On Thu, 17 Apr 1997, Guansong Zhang wrote:

> I met this problem before. Bryan, the Adlib designer, want to use compiler flag
> to solve this problem and put one trailing under-line in each case.


	I think this method is not so good , because on Linux there is no
such flag , and 2 underscore is added .

 
> Now since you put this problem back again, I still think this is a better way,
> it gets ride of the constains brought by the compiler flag.
> 
> Before I discuss this with Bryan again, I want to know if it is possible for
> you to solve this problem in another way, using Fortran compiler flag, like in
> the case of AIX, using -qextname to solve this problme.
> 


	I have notice this , this flag is useful only to xlf on RS6000 .


> Also I don't know why you need to consern this, the default seting seems OK on
> HP.


	Our work now is mainly on Linux .

> 
> Another thing concerned with the codes:
> 
> 
> >	Some compiler will complain about -lm , since they have no libm.a .
> > You'd better test if m exists .
> 
> Does libm.a always come with gcc? Bryan told me so.
>

	I have tried this , HP seems cannot accept this .
 
> 
> (cd src/pcrcFortran ; /bin/rm -f pcrc_stack.o ; \
>         $FCL $FC_OPT -c pcrc_stack.f > /dev/null 2>&1 )
> 
> Why you need to rm .o first? What does it mean in B shell "2>&1" ?
> 
>

	In case if the compilation failed , existing pcrc_stack.o is used for 
test. 2>&1 means direct standard error output to standand output .  




Zheng

From zheng.gb@bimp.pku.edu.cn Mon Dec 15 09:16 EST 1997
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id JAA18535 for <dbc@npac.syr.edu>; Mon, 15 Dec 1997 09:16:36 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA17021; Mon, 15 Dec 1997 21:42:03 +0800
Date: Mon, 15 Dec 1997 21:42:03 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Subject: about shift
Message-Id: <Pine.HPP.3.91.971215212133.16753A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 278
Status: ROr


Hi,

  I found shift() will core dump on Linux. Has it same problem with remap? 


Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page:
http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail: 
zhegn.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Mon Dec 15 13:31 EST 1997
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id NAA22291 for <dbc@postoffice.npac.syr.edu>; Mon, 15 Dec 1997 13:31:55 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id NAA24312; Mon, 15 Dec 1997 13:34:08 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199712151834.NAA24312@weed.npac.syr.edu>
Subject: Re: about shift
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 15 Dec 1997 13:34:07 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.971215212133.16753A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Dec 15, 97 09:42:03 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 556
Status: RO


Hi,

    Sorry about that.  My shift test cases seem to work on our
Beowulf.  Can you send me the example that's crashing?  (It makes my
life easier you send the C++ equivalent, but HPF source + Fortran
generated code will do).

Bryan

> 
> 
> Hi,
> 
>   I found shift() will core dump on Linux. Has it same problem with remap? 
> 
> 
> Gengbin
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page:
> http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail: 
> zhegn.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From dbc@npac.syr.edu Thu Dec 18 14:37 EST 1997
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id OAA14663; Thu, 18 Dec 1997 14:37:37 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id OAA01706; Thu, 18 Dec 1997 14:40:24 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199712181940.OAA01706@weed.npac.syr.edu>
Subject: Re: about shift
To: dbc@postoffice.npac.syr.edu (Bryan Carpenter)
Date: Thu, 18 Dec 1997 14:40:23 -0500 (EST)
Cc: zheng.gb@bimp.pku.edu.cn, zgs@weed.npac.syr.edu, lxm@[162.105.181.215]
In-Reply-To: <199712181928.OAA01690@weed.npac.syr.edu> from "Bryan Carpenter" at Dec 18, 97 02:28:24 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 302
Status: RO

> You should replace
> 
>       call pcrc_shift (pcrc_tdd1,pcrc_sdd1,1,-1)
> 
> with
> 
>       call pcrc_tshift (pcrc_integer_stack(pcrc_tbs1+pcrc_sdx0),pcrc_sdd1,1,-1)

That should have been just

      call pcrc_tshift (pcrc_integer_stack(pcrc_tbs1),pcrc_sdd1,1,-1)

---no `pcrc_sdx0' here.

Bryan


From zheng.gb@bimp.pku.edu.cn Sun Dec 21 02:42 EST 1997
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id CAA19289 for <dbc@postoffice.npac.syr.edu>; Sun, 21 Dec 1997 02:42:45 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA28620; Sun, 21 Dec 1997 15:36:59 +0800
Date: Sun, 21 Dec 1997 15:36:59 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Guansong Zhang <zgs@npac.syr.edu>
Cc: Bryan Carpenter <dbc@postoffice.npac.syr.edu>
Subject: Re: your mail
In-Reply-To: <9712181008.ZM9327@cairngorm.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.971221153635.28275A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 150
Status: ROr

On Thu, 18 Dec 1997, Guansong Zhang wrote:

> I remember as pcrc_size ?
> 

I thought this function will return the global size of an array.

Gengbin

From zheng.gb@bimp.pku.edu.cn Sun Dec 21 04:04 EST 1997
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id EAA19973; Sun, 21 Dec 1997 04:04:07 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA29392; Sun, 21 Dec 1997 16:58:28 +0800
Date: Sun, 21 Dec 1997 16:58:26 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>,
        Guansong Zhang <zgs@weed.npac.syr.edu>, lxm@arch.cs.pku.edu.cn
Subject: Re: about shift
In-Reply-To: <199712181928.OAA01690@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.971221154138.28275B-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 3246
Status: ROr


Hi,

> BTW, I guess you realize you have created `A' with ghost regions, although
> you aren't using them here.  It will work, but it looks odd.
>

	Yes, in fact I changed the remap to shift manually in this exmaple.
After dect_communication, the communication pattern is set to SHIFT, which 
generated ghost regions, but after data dependence checking, the loop 
turn out to contain some data flow dependence, so writeHalo cannot do the 
right thing and the shift is changed to remap. That is why I didn't use 
writeHalo ,but pcrc_shift.  pcrc_shift will communicated in temporary stack.

	This time pcrc_tshift is right. But I don't know if pcrc_tshift is
faster than pcrc_remap enough so I should use pcrc_tshift rather than 
pcrc_remap if flow data dependence is detected.


>      ---=+ O +=---
> 
> A couple of issues:
> 
> 1) Guansong has been trying to persuade me there should be a debug mode
> for Adlib that adds runtime checks for constraints like alignment
> restrictions on arguments of communication functions.  A mode like that
> would trap errors like this.
> 
> 2) This example illustrates how much cleaner the HPJava interface is than
> the PCRC Fortran interface.  Really something needs to be done about the
> Fortran interface to make it more sane (speaking as the person who mainly
> designed that interface...)
>

   Another interest thing is that if Adlib provide a function that can 
decide if two arrays(DAD) have same data mapping patterns during runtime?
I found it will be very convenient 

   I also encountered a problem when using transformation functions. I think 
these collective functions have inherit collision with our owner-compute 
rule. There is a very simple example(maybe unresonable):

	integer a(1:4),b(1:4)
	forall (i=1:3)
		a(i)=sum(b)

Suppose there are 4 processors(P) and block mapping is assumed to a and b , 
according to owner-compute rule, processors: P(1)-P(3) will enter the do 
loop to compute their holding part of a. But the execution of sum require that 
all processors participate in the computation. This will cause deadlock 
of the node programs. It is also very hard to extract the execution of sum 
out of the do-loop, because the parameters of sum may contain the loop 
variables. 

Ok, so many questions, anyway,
Merry Christmas ! 


               .-~~\
      *   *   /     \ _     *        *
              ~x   .-~_)_       *
    *   *       ~x".-~   ~-.             *
            _   ( /         \   _    *
       *    ||   T  o  o     Y  ||       Here's wishing all of you
   *      ==:l   l   <       !  I;==     the very best of holidays!!!
             \\   \  .__/   /  //
     *        \\ ,r"-,___.-'r.//
          *    }^ \.( )   _.'//.   *
              /    }~Xi--~  //  \         *
       *     Y    Y I\ \    "    Y
             |    | |o\ \        |      *
   *         |    l_l  Y T       |         *
        *    l      "o l_j       !  *
              \                 /
     * ___,.---^.     o       .^---.._____

   "~~~          "           ~            ~~~"

Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

Home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Mon Dec 29 14:01 EST 1997
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id OAA07589; Mon, 29 Dec 1997 14:01:08 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id OAA10688; Mon, 29 Dec 1997 14:03:35 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199712291903.OAA10688@weed.npac.syr.edu>
Subject: Re: your mail
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 29 Dec 1997 14:03:34 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter),
        zgs@weed.npac.syr.edu (Guansong Zhang)
In-Reply-To: <Pine.HPP.3.91.971221153635.28275A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Dec 21, 97 03:36:59 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 379
Status: RO


No.  It's the size of the locally allocated segment.

There's no direct function for computing the size of the total
array---you have to multiply together the extents of the individual
dimensions.

Bryan

> 
> On Thu, 18 Dec 1997, Guansong Zhang wrote:
> 
> > I remember as pcrc_size ?
> > 
> 
> I thought this function will return the global size of an array.
> 
> Gengbin
> 


From dbc@npac.syr.edu Mon Dec 29 14:43 EST 1997
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id OAA08049; Mon, 29 Dec 1997 14:43:28 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id OAA10786; Mon, 29 Dec 1997 14:46:00 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199712291946.OAA10786@weed.npac.syr.edu>
Subject: Re: about shift
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 29 Dec 1997 14:45:59 -0500 (EST)
Cc: dbc@postoffice.npac.syr.edu, zgs@weed.npac.syr.edu, lxm@[162.105.181.215]
In-Reply-To: <Pine.HPP.3.91.971221154138.28275B-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Dec 21, 97 04:58:26 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2576
Status: RO

> > 
> > A couple of issues:
> > 
> > 1) Guansong has been trying to persuade me there should be a debug mode
> > for Adlib that adds runtime checks for constraints like alignment
> > restrictions on arguments of communication functions.  A mode like that
> > would trap errors like this.
> > 
> > 2) This example illustrates how much cleaner the HPJava interface is than
> > the PCRC Fortran interface.  Really something needs to be done about the
> > Fortran interface to make it more sane (speaking as the person who mainly
> > designed that interface...)
> >
> 
>    Another interest thing is that if Adlib provide a function that can 
> decide if two arrays(DAD) have same data mapping patterns during runtime?
> I found it will be very convenient 

Yes, this function would be needed for the run-time checks mentioned
above, so it could be made available in the external interface.

> 
>    I also encountered a problem when using transformation functions. I think 
> these collective functions have inherit collision with our owner-compute 
> rule. There is a very simple example(maybe unresonable):
> 
> 	integer a(1:4),b(1:4)
> 	forall (i=1:3)
> 		a(i)=sum(b)
> 
> Suppose there are 4 processors(P) and block mapping is assumed to a and b , 
> according to owner-compute rule, processors: P(1)-P(3) will enter the do 
> loop to compute their holding part of a. But the execution of sum require that 
> all processors participate in the computation. This will cause deadlock 
> of the node programs. It is also very hard to extract the execution of sum 
> out of the do-loop, because the parameters of sum may contain the loop 
> variables. 

Clearly you can't use both naive owner-computes *and* collective
computation of `sum' in this situation.  But I'd say that's the
compiler's problem, not the library's.  The library supports *either*
owner computes:

  integer tmp(1:4)
  align tmp(*) with a(*)       ! collapsed-replicated alignment

  adlib_remap(tmp, b) ;

  forall(i = 1 : 3)
    a(i) = sum(tmp)            ! sequential sum, repeated on every processor


*or* parallel sum:

  integer tmp
  align tmp with a(*)          ! replicated alignment

  adlib_sum(tmp, b) ;          ! distributed sum

  forall(i = 1 : 3)
    a(i) = tmp

It's up to the compiler which strategy to adopt.

This part of HPF compilation---how to map computation in general
parallel loops---always seems very mysterious to me.  Intuitively the
second version seems best, but it isn't what the owner computes rule
implies.  I expect somebody has done a lot of research on this.

Bryan


From zheng.gb@bimp.pku.edu.cn Tue Jan  6 04:14 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id EAA10320 for <dbc@postoffice.npac.syr.edu>; Tue, 6 Jan 1998 04:13:37 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA08719; Tue, 6 Jan 1998 17:06:54 +0800
Date: Tue, 6 Jan 1998 17:06:54 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: dbc@postoffice.npac.syr.edu, zgs@weed.npac.syr.edu, lxm@arch.cs.pku.edu.cn
Subject: Re: about shift
In-Reply-To: <199712291946.OAA10786@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.971231172338.6384A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2528
Status: ROr

On Mon, 29 Dec 1997, Bryan Carpenter wrote:

> >    Another interest thing is that if Adlib provide a function that can 
> > decide if two arrays(DAD) have same data mapping patterns during runtime?
> > I found it will be very convenient 
> 
> Yes, this function would be needed for the run-time checks mentioned
> above, so it could be made available in the external interface.
>

  I am trying to figure out how many things we must compare in order to 
decide two DADs are same distributed . The first thing I think is to compare
the rank, element type, process group. Then I must compare the two ranges, 
include the g_lb, g_ub and extent. One thing I am not sure is how to compare
the distcode ?
And are these enough? 

 
> > 
> >    I also encountered a problem when using transformation functions. I think 
> > these collective functions have inherit collision with our owner-compute 
> > rule. There is a very simple example(maybe unresonable):
> > 
> > 	integer a(1:4),b(1:4)
> > 	forall (i=1:3)
> > 		a(i)=sum(b)
> > 
> > Suppose there are 4 processors(P) and block mapping is assumed to a and b , 
> > according to owner-compute rule, processors: P(1)-P(3) will enter the do 
> > loop to compute their holding part of a. But the execution of sum require that 
> > all processors participate in the computation. This will cause deadlock 
> > of the node programs. It is also very hard to extract the execution of sum 
> > out of the do-loop, because the parameters of sum may contain the loop 
> > variables. 
> 
> Clearly you can't use both naive owner-computes *and* collective
> computation of `sum' in this situation.  But I'd say that's the
> compiler's problem, not the library's.  The library supports *either*
> owner computes:
> 
>   integer tmp(1:4)
>   align tmp(*) with a(*)       ! collapsed-replicated alignment
> 
>   adlib_remap(tmp, b) ;
> 
>   forall(i = 1 : 3)
>     a(i) = sum(tmp)            ! sequential sum, repeated on every processor
> 

	So forall have to be done as do , a sequential one ?

> 
> *or* parallel sum:
> 
>   integer tmp
>   align tmp with a(*)          ! replicated alignment
> 
>   adlib_sum(tmp, b) ;          ! distributed sum
> 
>   forall(i = 1 : 3)
>     a(i) = tmp
> 

	If the sum function contains a parameter with loop variable i,then
this strategy cannot work.




Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn




From dbc@npac.syr.edu Tue Jan  6 11:15 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id LAA14775; Tue, 6 Jan 1998 11:15:23 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id LAA18001; Tue, 6 Jan 1998 11:17:58 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801061617.LAA18001@weed.npac.syr.edu>
Subject: Re: about shift
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Tue, 6 Jan 1998 11:17:57 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter),
        zgs@weed.npac.syr.edu (Guansong Zhang), lxm@[162.105.181.215]
In-Reply-To: <Pine.HPP.3.91.971231172338.6384A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Jan 6, 98 05:06:54 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 4016
Status: RO

> 
> On Mon, 29 Dec 1997, Bryan Carpenter wrote:
> 
> > >    Another interest thing is that if Adlib provide a function that can 
> > > decide if two arrays(DAD) have same data mapping patterns during runtime?
> > > I found it will be very convenient 
> > 
> > Yes, this function would be needed for the run-time checks mentioned
> > above, so it could be made available in the external interface.
> >
> 
>   I am trying to figure out how many things we must compare in order to 
> decide two DADs are same distributed . The first thing I think is to compare
> the rank, element type, process group. Then I must compare the two ranges, 
> include the g_lb, g_ub and extent. One thing I am not sure is how to compare
> the distcode ?
> And are these enough? 

There are a lot of things to compare.  That's why I haven't put these
checks in before.  You have to check equivalence of process group and
all ranges.

Equivalence of process groups reduces to

  1) Equivalence of parent process array.
  2) Equality of the dimension mask.
  3) Equality of the lead process id in the group.

Only 1 is non-trivial.  There's a question of whether you want a sort
of strong ``name equivalence'' between process arrays.  That's easy to
test---you just compare pointers to the process array structure.  But
you may also want a weaker ``structural equivalence''.  That's more
expensive to test---you may have to compare shape of the process arrays
*and* (depending on whether you used this facility) the
logical-to-physical mapping vector in the process array.

More generally you may want to only check some sort of containment relation
between groups, because often it is sufficient that input arguments are
aligned to output arguments with some replicated alignment---not necessarily
identically aligned.  This would alter tests 2 and 3 above.

For *ranges*, equivalence depends strongly on the distribution format.
In Adlib this ought to be handled by adding an equivalence-test virtual
function to the `RangeRep' subclasses that deal with different
distribution formats.  This isn't terribly difficult to do, but it
hasn't been implemented yet.

If you are only dealing with the subset of distribution formats
specified by Xiaoming in the PCRC DAD, I guess it's sufficient to
compare extent alignment parameters and template range parameters.  In
Adlib the extent is given by

  int Range :: size()

and alignment parameters are given by

  int Range :: str()
  int Range :: bas()

The template range is given by

  Range Range :: tem()

You need to compare the extent and distribution code of the template
range.  These are given by `size', again, and

  Format Range :: format()

ie, for a range `x' I think you need compare

  x.size()

  x.str()
  x.bas()

  x.tem().size()
  x.tem().format()

You also need to check that two ranges are mapped to the same process
dimension.  If you are requiring ``name'' equivalence of process arrays you
can do this by comparing

  x.dim()

If you are assuming ``structural'' equivalence between process arrays,
you need something else.

> > 
> > Clearly you can't use both naive owner-computes *and* collective
> > computation of `sum' in this situation.  But I'd say that's the
> > compiler's problem, not the library's.  The library supports *either*
> > owner computes:
> > 
> >   integer tmp(1:4)
> >   align tmp(*) with a(*)       ! collapsed-replicated alignment
> > 
> >   adlib_remap(tmp, b) ;
> > 
> >   forall(i = 1 : 3)
> >     a(i) = sum(tmp)            ! sequential sum, repeated on every processor
> > 
> 
> 	So forall have to be done as do , a sequential one ?
> 
> > 
> > *or* parallel sum:
> > 
> >   integer tmp
> >   align tmp with a(*)          ! replicated alignment
> > 
> >   adlib_sum(tmp, b) ;          ! distributed sum
> > 
> >   forall(i = 1 : 3)
> >     a(i) = tmp
> > 
> 
> 	If the sum function contains a parameter with loop variable i,then
> this strategy cannot work.
> 

I guess you need to give me the example you're really interested in.

Bryan


From zheng.gb@bimp.pku.edu.cn Fri Jan  9 03:09 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id DAA03850 for <dbc@npac.syr.edu>; Fri, 9 Jan 1998 03:09:17 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA24586; Fri, 9 Jan 1998 16:02:45 +0800
Date: Fri, 9 Jan 1998 16:02:45 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>,
        Guansong Zhang <zgs@weed.npac.syr.edu>, lxm@arch.cs.pku.edu.cn
Subject: Re: about shift
In-Reply-To: <199801061617.LAA18001@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980109154657.23790A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2082
Status: ROr


> The template range is given by
> 
>   Range Range :: tem()
> 
> You need to compare the extent and distribution code of the template
> range.  These are given by `size', again, and
> 
>   Format Range :: format()
>

	template Range must be new. I cannot find this in my version.
 
> > > 
> > > Clearly you can't use both naive owner-computes *and* collective
> > > computation of `sum' in this situation.  But I'd say that's the
> > > compiler's problem, not the library's.  The library supports *either*
> > > owner computes:
> > > 
> > >   integer tmp(1:4)
> > >   align tmp(*) with a(*)       ! collapsed-replicated alignment
> > > 
> > >   adlib_remap(tmp, b) ;
> > > 
> > >   forall(i = 1 : 3)
> > >     a(i) = sum(tmp)            ! sequential sum, repeated on every processor
> > > 
> > 
> > 	So forall have to be done as do , a sequential one ?
> > 
> > > 
> > > *or* parallel sum:
> > > 
> > >   integer tmp
> > >   align tmp with a(*)          ! replicated alignment
> > > 
> > >   adlib_sum(tmp, b) ;          ! distributed sum
> > > 
> > >   forall(i = 1 : 3)
> > >     a(i) = tmp
> > > 
> > 
> > 	If the sum function contains a parameter with loop variable i,then
> > this strategy cannot work.
> > 
> 
> I guess you need to give me the example you're really interested in.
> 

here is an example:

integer a(4)
forall (i=1:3) a(i)=sum(b(i:10))

Assume a is block-distributed onto 4 processors, so the node programs on
processor node 1-3 will be

do pcrc_i=0,0,1
  a(pcrc_i) = sum(b(i:10))       ! sum() need some translation
enddo

however in processor 4, the code will be

do pcrc_i=0,-10000,1
...
enddo

which will do nothing in loop, because it hold no array element to compute.

So the problem is how to translate the function call 'sum' here.Since i is
appeared in the sum function call, the function seems can not be extracted
out of the forall statement.


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Fri Jan  9 10:39 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA07778; Fri, 9 Jan 1998 10:39:22 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA21919; Fri, 9 Jan 1998 10:41:44 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801091541.KAA21919@weed.npac.syr.edu>
Subject: Re: about shift
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Fri, 9 Jan 1998 10:41:44 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter),
        zgs@weed.npac.syr.edu (Guansong Zhang), lxm@[162.105.181.215]
In-Reply-To: <Pine.HPP.3.91.980109154657.23790A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Jan 9, 98 04:02:45 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2610
Status: RO

> 
> 
> > The template range is given by
> > 
> >   Range Range :: tem()
> > 
> > You need to compare the extent and distribution code of the template
> > range.  These are given by `size', again, and
> > 
> >   Format Range :: format()
> >
> 
> 	template Range must be new. I cannot find this in my version.

The inquiry function probably changed name (I think it used to be
`prm').  Anyway, I'll be putting the most recent release of the
software on our Web page sometime in the next day or two.

> > 
> > I guess you need to give me the example you're really interested in.
> > 
> 
> here is an example:
> 
> integer a(4)
> forall (i=1:3) a(i)=sum(b(i:10))
> 
> Assume a is block-distributed onto 4 processors, so the node programs on
> processor node 1-3 will be
> 
> do pcrc_i=0,0,1
>   a(pcrc_i) = sum(b(i:10))       ! sum() need some translation
> enddo
> 
> however in processor 4, the code will be
> 
> do pcrc_i=0,-10000,1
> ...
> enddo
> 
> which will do nothing in loop, because it hold no array element to compute.
> 
> So the problem is how to translate the function call 'sum' here.Since i is
> appeared in the sum function call, the function seems can not be extracted
> out of the forall statement.
> 

OK.  I'm still not completely sure how you want to translate this.  I
guess you want the loop to go in parallel with the sums inside the
loop also implemented as parallel operations.

Adlib only really supports this kind of nested parallelism if you have
more than one process dimension to work with.  Eg if `a', `b' are
distributed over orthogonal process dimensions:

  !hpf$ processors p(4, 4)
  !hpf$ template t(4, 10)
  !hpf$ distribute t onto p(BLOCK, BLOCK)

  !hpf$ align a(:) with t(:, *)
  !hpf$ align b(:) with t(*, :)

  etc

then the forall and the sum can both be parallelized.  In Adlib (using
the HPJava notation again, because its shorter) it can be implemented like

  Procs p = new Procs2(4, 4) ;
  on(p) {

    Range x = p.dim(0), y = new BlockRange(10, p.dim(1)) ; 

    int [[#]] a = new int [[x]], b = new int [[y]] ;

    Index i ;
    over(i = x | 0 : 2)
      a [i] = HPJlib.sum(b [[x.idx(i) : 9]])

  }

Because the `over' construct restricts the active process group
suitably, calls to `sum' inside the loop will work correctly.

If you want this functionality from Fortran, you will have to improve
the Fortran interface so that it updates the `apg' global variable
(which describes the current active process group) inside parallel
loops.

If you don't have a pair of process dimensions, I'm not really
sure how you envisage doing the parallelization.

Bryan


From zheng.gb@bimp.pku.edu.cn Sat Jan 10 03:48 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id DAA19527 for <dbc@npac.syr.edu>; Sat, 10 Jan 1998 03:48:21 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA27794; Sat, 10 Jan 1998 16:18:07 +0800
Date: Sat, 10 Jan 1998 16:18:06 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980110161255.27774A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 334
Status: ROr


How can I translate this code use Adlib class lib, 

a=1

where a is an array whose dimensions can only be known during runtime?


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Sat Jan 10 15:36 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id PAA24538 for <dbc@postoffice.npac.syr.edu>; Sat, 10 Jan 1998 15:36:21 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id PAA23250; Sat, 10 Jan 1998 15:39:11 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801102039.PAA23250@weed.npac.syr.edu>
Subject: Re: your mail
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Sat, 10 Jan 1998 15:39:10 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980110161255.27774A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Jan 10, 98 04:18:06 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1042
Status: RO

> 
> 
> How can I translate this code use Adlib class lib, 
> 
> a=1
> 
> where a is an array whose dimensions can only be known during runtime?
> 


Well, in HPJava it would be

  Index i ;
  over(i = a.rng(0) | :)
    a [i] = 1 ;

for rank-1, 

  Index i, j ;
  over(i = a.rng(0) | :)
    over(j = a.rng(1) | :)
       a [i, j] = 1 ;

for rank2, etc.  You would have to write a recursive function if the
rank wasn't known in advance.

That isn't exactly Adlib.  In ad++ the corresponding thing is

  Index i(a.rng(0)) ;
  OVERALL(i) {
    a(i) = 1 ;
  } ALLOVER(i) ;

for rank-1, 

  Index i(a.rng(0)), j(a.rng(1)) ;
  OVERALL(i) {
    OVERALL(j) {
      a(i, j) = 1 ;
    } ALLOVER(j) ;
  } ALLOVER(i) ;

for rank 2, etc.  (the old ad++ WHERE construct has been renamed to
OVERALL in the latest version).

If you wanted a single library function to initialize an array with a
constant, there's no such function at the moment.  It would only take a
few minutes to write such a function, but I'm not sure how generally
useful it is.

Bryan


From zheng.gb@bimp.pku.edu.cn Sat Jan 10 21:03 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id VAA26902 for <dbc@weed.npac.syr.edu>; Sat, 10 Jan 1998 21:03:14 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA02107; Sun, 11 Jan 1998 09:56:50 +0800
Date: Sun, 11 Jan 1998 09:56:47 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>
Subject: Re: your mail
In-Reply-To: <199801102039.PAA23250@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980111094512.2083A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2759
Status: ROr

On Sat, 10 Jan 1998, Bryan Carpenter wrote:

> > 
> > 
> > How can I translate this code use Adlib class lib, 
> > 
> > a=1
> > 
> > where a is an array whose dimensions can only be known during runtime?
> > 
> 
> 
> Well, in HPJava it would be
> 
>   Index i ;
>   over(i = a.rng(0) | :)
>     a [i] = 1 ;
> 
> for rank-1, 
> 
>   Index i, j ;
>   over(i = a.rng(0) | :)
>     over(j = a.rng(1) | :)
>        a [i, j] = 1 ;
> 
> for rank2, etc.  You would have to write a recursive function if the
> rank wasn't known in advance.
> 
> That isn't exactly Adlib.  In ad++ the corresponding thing is
> 
>   Index i(a.rng(0)) ;
>   OVERALL(i) {
>     a(i) = 1 ;
>   } ALLOVER(i) ;
> 
> for rank-1, 
> 
>   Index i(a.rng(0)), j(a.rng(1)) ;
>   OVERALL(i) {
>     OVERALL(j) {
>       a(i, j) = 1 ;
>     } ALLOVER(j) ;
>   } ALLOVER(i) ;
> 
> for rank 2, etc.  (the old ad++ WHERE construct has been renamed to
> OVERALL in the latest version).
> 
> If you wanted a single library function to initialize an array with a
> constant, there's no such function at the moment.  It would only take a
> few minutes to write such a function, but I'm not sure how generally
> useful it is.
> 

I encounter this problem when I am writing HPF intrinsic library using Ad++,
for example:

 A(1:10) = sum(B)

This means I must replicate the sum value to every element of array "a" after
I call the transformation function 'sum'.
In your code above the only thing I donot know is how to get an Array in 
Ad++ according to a DAD , so that I can write the code you mentioned above:
a(i,j)=1 ?           ( I understand there is an operator overloading )

My code is here:

      DAD *resPtr;
      switch (resPtr->rank) {
	...
      case 2:
        LocBlocksIndex i(resPtr->ranges[0]),j(resPtr->ranges[1]) ;
        for (i.begin(); i.test(); i.next() ) {
          int off0_bas = resPtr->str(0).offset(i);
          int off0_stp = resPtr->str(0).step(i);
          for (int l=0; l<i.blockCount; l++) {
             for (j.begin(); j.test(); j.next() ) {
                int off1_bas = resPtr->str(1).offset(j);
                int off1_stp = resPtr->str(1).step(j);
                for (int m=0; m<j.blockCount; m++) {
                        ((int*)resPtr->data)[off0_bas+off0_stp*l + 
                               off1_bas+off1_stp*m] = 1
                }
             }
          }
        }
        break;
      case 3:
	...


So I have to enumerate all rank and all possible element type of
(resPtr->data) in this function, do you think I have a simple way to do this?


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Sun Jan 11 15:03 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id PAA04842 for <dbc@postoffice.npac.syr.edu>; Sun, 11 Jan 1998 15:03:37 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id PAA24109; Sun, 11 Jan 1998 15:06:26 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801112006.PAA24109@weed.npac.syr.edu>
Subject: Re: your mail
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Sun, 11 Jan 1998 15:06:25 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980111094512.2083A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Jan 11, 98 09:56:47 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 4507
Status: ROr



> 
> I encounter this problem when I am writing HPF intrinsic library using Ad++,
> for example:
> 
>  A(1:10) = sum(B)
> 
> This means I must replicate the sum value to every element of array "a" after
> I call the transformation function 'sum'.
> In your code above the only thing I donot know is how to get an Array in 
> Ad++ according to a DAD , so that I can write the code you mentioned above:
> a(i,j)=1 ?           ( I understand there is an operator overloading )

In ad++ it would just be something like

  float s = sum(b) ;

  Index i(a.rng(0).subrng(10, 0)) ;
  OVERALL(i) {
    a(i) = s ;
  } ALLOVER(i) ;

If you really want to construct the DAD for the section, it's something like

  Range x = a.rng(0) ;
  Section1<float> as = a.sect(x.subrng(10, 0)) ;

The optimized version you produced using the kernel Adlib looks as if
it should work, but if you really need something that works for any
rank, I'd recommend writing a recursive function that does the job.
The following code is modelled on the library implementation of `copy'.
It isn't tested, but it may work.

Bryan

------------

template<class T>
inline void blockInit(T* dst, int* dstStrs,
                      int* exts, int rank,
                      T* val)
  if(rank == 0)
    *dst = *val ;
  else if(rank == 1) {
    const int count   = *exts ;
    const int dstStep = *dstStrs ;
    for(int i = 0 ; i < count ; i++) {
      *dst = *val ;
      dst += dstStep ;
    }
  }
  else {
    rank-- ;
    const int count   = exts [rank] ;
    const int dstStep = dstStrs [rank] ;
    for(int i = 0 ; i < count ; i++) {
      blockCopy(dst, dstStrs, exts, rank, val) ;
      dst += dstStep ;
    }
  }
}

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
//                                                                     //
//  Class Map: blockwise mapping operation.                            //
//                                                                     //
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //

class Map {
public :
  Map(const DAD* _arr) : arr(_arr), rank(_arr->rnk()) {
    exts     = new int [rank] ;
    step = new int [rank] ;
  }

  ~Map() {
    delete [] steps ;
    delete [] exts ;
  }

  void execute() {
    if(arr->grp().member())
      loop(0, 0, 0) ;
  }

protected :
  int rank ;
  int *exts, *steps ;

  virtual void opMap(const int offset) = 0 ;

private :
  const DAD* arr ;

  void loop(int offset, const int r) {
    if(r == rank)
      opMap(offset) ;
    else {
      Stride str = arr->str(r) ;

      LocBlocksIndex i(arr->rng(r)) ;
      for(i.beginLocBlk() ; i.test() ; i.nextLocBlk()) {
        exts  [r] = i.count ;
        steps [r] = str.step(i) ;

        loop(offset + str.offset(i), r + 1) ;
      }
    }
  }
} ;

template<class T>
class Init : public Map {
public :
  Init(const DAD* _dst) : Map(_dst) {}

  void execute(T* _dstBase, T* _val) {
    dstBase = _dstBase ;
    val     = _val ;
    Map :: execute() ;
  }

  void opMap(const int dstOffset) {
    blockCopy(dstBase + dstOffset, dstSteps, exts, rank, val) ;
  }

private :
  T *dstBase, *val ;
} ;


template<class T>
inline void init(const Section1<T>& dst, T& val) {
  Init<T> schedule(&dst) ;

  schedule.execute(dst.dat(), &val) ;
}



> 
> My code is here:
> 
>       DAD *resPtr;
>       switch (resPtr->rank) {
> 	...
>       case 2:
>         LocBlocksIndex i(resPtr->ranges[0]),j(resPtr->ranges[1]) ;
>         for (i.begin(); i.test(); i.next() ) {
>           int off0_bas = resPtr->str(0).offset(i);
>           int off0_stp = resPtr->str(0).step(i);
>           for (int l=0; l<i.blockCount; l++) {
>              for (j.begin(); j.test(); j.next() ) {
>                 int off1_bas = resPtr->str(1).offset(j);
>                 int off1_stp = resPtr->str(1).step(j);
>                 for (int m=0; m<j.blockCount; m++) {
>                         ((int*)resPtr->data)[off0_bas+off0_stp*l + 
>                                off1_bas+off1_stp*m] = 1
>                 }
>              }
>           }
>         }
>         break;
>       case 3:
> 	...
> 
> 
> So I have to enumerate all rank and all possible element type of
> (resPtr->data) in this function, do you think I have a simple way to do this?
> 
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From dbc@npac.syr.edu Sun Jan 11 15:05 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id PAA04860 for <dbc@postoffice.npac.syr.edu>; Sun, 11 Jan 1998 15:05:53 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id PAA24146; Sun, 11 Jan 1998 15:09:05 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801112009.PAA24146@weed.npac.syr.edu>
Subject: Re: your mail
To: dbc@postoffice.npac.syr.edu (Bryan Carpenter)
Date: Sun, 11 Jan 1998 15:09:04 -0500 (EST)
Cc: zheng.gb@bimp.pku.edu.cn
In-Reply-To: <199801112006.PAA24109@weed.npac.syr.edu> from "Bryan Carpenter" at Jan 11, 98 03:06:25 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 274
Status: RO


>     for(int i = 0 ; i < count ; i++) {
>       blockCopy(dst, dstStrs, exts, rank, val) ;
             ^^^^
....
> 
>   void opMap(const int dstOffset) {
>     blockCopy(dstBase + dstOffset, dstSteps, exts, rank, val) ;
           ^^^^

Should have been `blockInit'.

B


From zheng.gb@bimp.pku.edu.cn Mon Jan 12 21:02 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id VAA23535 for <dbc@npac.syr.edu>; Mon, 12 Jan 1998 21:02:41 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA03002; Tue, 13 Jan 1998 09:56:28 +0800
Date: Tue, 13 Jan 1998 09:56:28 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@postoffice.npac.syr.edu>
Subject: Re: your mail
In-Reply-To: <199801112009.PAA24146@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980113093841.2673B-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 255
Status: ROr

Hi,

 How can I get your latest version of Adlib ?


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Tue Jan 13 10:22 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA29566 for <dbc@postoffice.npac.syr.edu>; Tue, 13 Jan 1998 10:22:53 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA25992; Tue, 13 Jan 1998 10:25:36 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801131525.KAA25992@weed.npac.syr.edu>
Subject: Re: your mail
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Tue, 13 Jan 1998 10:25:35 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980113093841.2673B-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Jan 13, 98 09:56:28 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 388
Status: RO


It should appear on our Web page either today or tomorrow.
I just have to do the README.

Bryan

> 
> Hi,
> 
>  How can I get your latest version of Adlib ?
> 
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From dbc@npac.syr.edu Tue Jan 13 18:21 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id SAA07617 for <dbc@postoffice.npac.syr.edu>; Tue, 13 Jan 1998 18:21:00 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id SAA28379; Tue, 13 Jan 1998 18:23:51 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801132323.SAA28379@weed.npac.syr.edu>
Subject: Re: your mail
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Tue, 13 Jan 1998 18:23:51 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980113093841.2673B-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Jan 13, 98 09:56:28 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 371
Status: RO


It's now available at

http://www.npac.syr.edu/projects/pcrc/adlib.html

Bryan

> 
> Hi,
> 
>  How can I get your latest version of Adlib ?
> 
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From dbc@npac.syr.edu Wed Jan 14 13:36 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id NAA20688 for <dbc@postoffice.npac.syr.edu>; Wed, 14 Jan 1998 13:36:11 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id NAA29190; Wed, 14 Jan 1998 13:38:58 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801141838.NAA29190@weed.npac.syr.edu>
Subject: Re: your mail (fwd)
To: zheng.gb@bimp.pku.edu.cn
Date: Wed, 14 Jan 1998 13:38:58 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 694
Status: RO


Unfortunately the pcrcFortran interface in the version on the Web
doesn't work, because of some name-shifts to the kernel classes.  I'll
make a new version with a fixed Fortran interface available ASAP.

Bryan

----- Forwarded message from Bryan Carpenter -----


It's now available at

http://www.npac.syr.edu/projects/pcrc/adlib.html

Bryan

> 
> Hi,
> 
>  How can I get your latest version of Adlib ?
> 
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


----- End of forwarded message from Bryan Carpenter -----

From dbc@npac.syr.edu Wed Jan 14 17:44 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id RAA24838 for <dbc@postoffice.npac.syr.edu>; Wed, 14 Jan 1998 17:44:09 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id RAA29745; Wed, 14 Jan 1998 17:47:02 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801142247.RAA29745@weed.npac.syr.edu>
Subject: Re: your mail (fwd)
To: zheng.gb@bimp.pku.edu.cn
Date: Wed, 14 Jan 1998 17:47:01 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 797
Status: RO


I've put an ``unofficial'' revised release at

http://www.npac.syr.edu/projects/pcrc/Adlib_2.00a.tar.gz

The pcrcFortran interface in this version is supposed to work.

The name-shifts going from previous to new version of the Adlib kernel are

  DAD -> pcrcfDAD
  Frame -> DAD
  Subscript -> Location

Bryan

----- Forwarded message from Bryan Carpenter -----

...

It's now available at

http://www.npac.syr.edu/projects/pcrc/adlib.html

Bryan

> 
> Hi,
> 
>  How can I get your latest version of Adlib ?
> 
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


----- End of forwarded message from Bryan Carpenter -----

From zheng.gb@bimp.pku.edu.cn Fri Jan 16 03:19 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id DAA20677 for <dbc@npac.syr.edu>; Fri, 16 Jan 1998 03:19:02 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA17407; Fri, 16 Jan 1998 16:12:37 +0800
Date: Fri, 16 Jan 1998 16:12:37 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Subject: writeHalo
Message-Id: <Pine.HPP.3.91.980116161057.17331A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 486
Status: ROr


I figured out the problem in writehalo,
in Remap.h: line 177:
if(mode [r] != NONE && (wlo [r] > 0 || whi [r] > 0))

if mode is NULL as default , mode[r] is illegal reference,
so after I changed it to 
if((mode == 0 || mode [r] != NONE) && (wlo [r] > 0 || whi [r] > 0))
it's ok now.

Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From zheng.gb@bimp.pku.edu.cn Fri Jan 16 02:41 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id CAA20248 for <dbc@npac.syr.edu>; Fri, 16 Jan 1998 02:41:05 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA17167; Fri, 16 Jan 1998 15:34:34 +0800
Date: Fri, 16 Jan 1998 15:34:34 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Subject: new adlib
Message-Id: <Pine.HPP.3.91.980116153130.17162A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 627
Status: RO


  I have got your new version adlib-2.00 , I found everything is ok except
writeHalo, it caused node program core dump on Linux but seemed work
on IBM RS6000.

here is example:

        program try
        PARAMETER (N=4)
        integer a(N,N),b(N,N),c(N,N)
!HPF$   DISTRIBUTE a(block,block)
!HPF$   DISTRIBUTE b(cyclic,cyclic)
!HPF$   DISTRIBUTE c(block,block)

        forall (i=1:N,j=2:N) a(i,j)=c(i,j-1)

        end


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Fri Jan 16 10:53 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA26295 for <dbc@postoffice.npac.syr.edu>; Fri, 16 Jan 1998 10:53:18 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA01371; Fri, 16 Jan 1998 10:55:55 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801161555.KAA01371@weed.npac.syr.edu>
Subject: Re: writeHalo
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Fri, 16 Jan 1998 10:55:54 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980116161057.17331A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Jan 16, 98 04:12:37 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 728
Status: RO


Sorry about that.  I made a quick fix to allow the new `mode' vector to
be omitted, to support the old Fortran interface.  Obviously I didn't
test it properly.  Thanks for the correction.

Bryan

> 
> 
> I figured out the problem in writehalo,
> in Remap.h: line 177:
> if(mode [r] != NONE && (wlo [r] > 0 || whi [r] > 0))
> 
> if mode is NULL as default , mode[r] is illegal reference,
> so after I changed it to 
> if((mode == 0 || mode [r] != NONE) && (wlo [r] > 0 || whi [r] > 0))
> it's ok now.
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From zheng.gb@bimp.pku.edu.cn Sat Jan 17 22:41 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id WAA23390 for <dbc@npac.syr.edu>; Sat, 17 Jan 1998 22:41:17 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA20077; Sun, 18 Jan 1998 11:34:52 +0800
Date: Sun, 18 Jan 1998 11:34:52 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980118112926.20073A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1151
Status: ROr


I am writing a runtime function of detect_communication,
I am not sure if I got the information on template correctly:

  pcrcfDAD *dad_src;
  int d;

  //number of abstract processors in the dimension
  dad_y.numProcs = dad_src->rngs[d].dim()?dad_src->rngs[d].dim().size() : 1;

  //distribution code (BLOCK=1, CYCLIC=2, *=0)
  switch (dad_

From zhenggb@pubms.pku.edu.cn Sun Feb  8 05:28 EST 1998
Received: from pubms.pku.edu.cn (pubms.pku.edu.cn [162.105.128.10]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with ESMTP id FAA14828 for <dbc@npac.syr.edu>; Sun, 8 Feb 1998 05:28:01 -0500 (EST)
Received: from localhost (zhenggb@localhost)
	by pubms.pku.edu.cn (8.8.5/8.8.5) with SMTP id SAA10567
	for <dbc@npac.syr.edu>; Sun, 8 Feb 1998 18:26:21 +0800 (CST)
From: zhenggb@pubms.pku.edu.cn
Date: Sun, 8 Feb 1998 18:26:21 +0800 (CST)
To: dbc@npac.syr.edu
Subject: pcrc_loc
Message-ID: <Pine.GSO.3.95.980208181242.10449B-100000@pubms.pku.edu.cn>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 735
Status: ROr


  I have a question on the meaning of pcrc_loc(int *rng, int *g_i)
defined in pcrcFortran?
  As I understand, it will return the offset of g_i to the template
of this range. But I think this function should return the local index of
g_i in a node program as an inverse function of pcrc_glob().

  Another question, if I have defined a range with ghostarea, how can I
get the size of the ghostarea ?


PS,
 this is my new temperary e-mail adress, the old e-mail adress:
zheng.gb@svr.bimp.pku.edu  can not be used due to the holiday.


Gengbin Zheng
---------------------------------  
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:	   zhenggb@pubms.pku.edu.cn



From dbc@npac.syr.edu Sun Feb  8 14:37 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id OAA19243 for <dbc@postoffice.npac.syr.edu>; Sun, 8 Feb 1998 14:37:03 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id OAA18283; Sun, 8 Feb 1998 14:40:38 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802081940.OAA18283@weed.npac.syr.edu>
Subject: Re: pcrc_loc
To: zhenggb@pubms.pku.edu.cn
Date: Sun, 8 Feb 1998 14:40:37 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.GSO.3.95.980208181242.10449B-100000@pubms.pku.edu.cn> from "zhenggb@pubms.pku.edu.cn" at Feb 8, 98 06:26:21 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2648
Status: RO


Hi Gengbin

I sent a reply to a previous email of yours a little while back and it
didn't get through, presumably due to problems with your email.  Do you
know whether Xiaoming is similarly affected, I haven't heard from him
recently?

It's possible there is some anachronism (ie, bug) in the most current
version of `pcrc_loc'/`pcrc_glob'.  I little while ago I was
experimenting with alternate definitions of ``local subscript'' in
Adlib.  It may be that the current version Fortran interface has got
left with one of these experimental definitions that was later
abandoned.  As you say, the two functions should be inverses.  I'll get
a fix to you soon.

Below I'm including my previous email to you.

Bryan

> 
> 
>   I have a question on the meaning of pcrc_loc(int *rng, int *g_i)
> defined in pcrcFortran?
>   As I understand, it will return the offset of g_i to the template
> of this range. But I think this function should return the local index of
> g_i in a node program as an inverse function of pcrc_glob().
> 
>   Another question, if I have defined a range with ghostarea, how can I
> get the size of the ghostarea ?
> 
> 
> PS,
>  this is my new temperary e-mail adress, the old e-mail adress:
> zheng.gb@svr.bimp.pku.edu  can not be used due to the holiday.
> 
> 
> Gengbin Zheng
> ---------------------------------  
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:	   zhenggb@pubms.pku.edu.cn
> 
> 
> 

----------------

Sorry, not to reply sooner.  I somehow forgot your message.  Also
somehow the message got truncated.

You shouldn't need the conditional expression for `numProcs'.  Simply

  dad_src->rngs[d].dim().size()

should do, because `size' returns 1 on a null dimension.

Distribution code is given by the inquiry `Range :: format', which
will return

  DIST_BLOCK, DIST_CYCLIC, DIST_COLLAPSED

for your three cases.  You probably need to set up a little translation
table, because unfortunately they probably aren't 1, 2, 0.  They're currently
defined

enum Format {DIST_PRIMITIVE, DIST_COLLAPSED,
             DIST_BLOCK, DIST_CYCLIC, DIST_STEP} ;

so probably they're 2, 3, 1.  So you could just subtract 1, I suppose.

What else did you need to know?

Bryan

>
>
> I am writing a runtime function of detect_communication,
> I am not sure if I got the information on template correctly:
>
>   pcrcfDAD *dad_src;
>   int d;
>
>   //number of abstract processors in the dimension
>   dad_y.numProcs = dad_src->rngs[d].dim()?dad_src->rngs[d].dim().size() : 1;
>
>   //distribution code (BLOCK=1, CYCLIC=2, *=0)
>   switch (dad_
>




From zheng.gb@bimp.pku.edu.cn Sun Feb  8 20:06 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id UAA22223 for <dbc@npac.syr.edu>; Sun, 8 Feb 1998 20:06:18 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA01204; Mon, 9 Feb 1998 08:59:49 +0800
Date: Mon, 9 Feb 1998 08:59:49 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Subject: Re:pcrc_loc
In-Reply-To: <Pine.GSO.3.95.980209085138.17734A-100000@pubms.pku.edu.cn>
Message-Id: <Pine.HPP.3.91.980209084808.1091A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 907
Status: ROr

> I sent a reply to a previous email of yours a little while back and it
> didn't get through, presumably due to problems with your email.  Do you
> know whether Xiaoming is similarly affected, I haven't heard from him
> recently?
>

     Prof. Li is in vacation and not in Beijing now. He will be back
very soon. 

These are the information I want to obtain from template range.
I don't know if there are correct,

       dad_x.t_lb = lhsDad->rngs[lpd].tem().g_lb();
       dad_x.t_size = lhsDad->rngs[lpd].tem().size() ;
       dad_x.t_stride = lhsDad->rngs[lpd].str()/lhsDad->rngs[lpd].g_stride();
       dad_x.t_offset = 
dad_x.t_lb+lhsDad->rngs[lpd].bas()-dad_x.t_stride*lhsDad->rngs[lpd].g_lb(); 


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From zheng.gb@bimp.pku.edu.cn Mon Feb  9 04:27 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id EAA25574 for <dbc@npac.syr.edu>; Mon, 9 Feb 1998 04:27:45 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA17778; Mon, 9 Feb 1998 17:21:27 +0800
Date: Mon, 9 Feb 1998 17:21:26 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980209171909.17759A@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 375
Status: ROr


Hi,

I am trying to port Adlib-2.00 to HPUX, but I failed to find the correct
argc and argv AdlibInit needed. How can I decide the name from the Fortran
runtime library?


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Mon Feb  9 13:50 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id NAA02657; Mon, 9 Feb 1998 13:50:01 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id NAA19233; Mon, 9 Feb 1998 13:53:15 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802091853.NAA19233@weed.npac.syr.edu>
Subject: Re: pcrc_loc
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 9 Feb 1998 13:53:15 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter), lxm@[162.105.181.215],
        zgs@weed.npac.syr.edu (Guansong Zhang)
In-Reply-To: <Pine.HPP.3.91.980209084808.1091A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Feb 9, 98 08:59:49 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 32123
Status: RO

> 
> These are the information I want to obtain from template range.
> I don't know if there are correct,
> 
>        dad_x.t_lb = lhsDad->rngs[lpd].tem().g_lb();
>        dad_x.t_size = lhsDad->rngs[lpd].tem().size() ;
>        dad_x.t_stride = lhsDad->rngs[lpd].str()/lhsDad->rngs[lpd].g_stride();
>        dad_x.t_offset = 
> dad_x.t_lb+lhsDad->rngs[lpd].bas()-dad_x.t_stride*lhsDad->rngs[lpd].g_lb(); 
> 

They look about right.  Offhand I don't remember the exact definition
of `t_offset'.

I've never been very happy having `g_lb', `g_stride' in the runtime
representation of the arrays.  I always work in terms of reduced
template and array subscripts that start from 0.  The
``shift-homomorphism'' conditions and coefficients can be computed
without them as described in the short document below, which I wrote a
while ago when I was trying to understand Xiaoming's ideas.

(I'm not exactly expecting to persuade anyone here, just reopening an
old debate).

Bryan

----------------------------
%!PS-Adobe-2.0
%%Creator: dvips 5.521 Copyright 1986, 1993 Radical Eye Software
%%Title: shift.dvi
%%CreationDate: Wed Aug 14 11:33:04 1996
%%Pages: 2
%%PageOrder: Ascend
%%BoundingBox: 0 0 612 792
%%EndComments
%DVIPSCommandLine: dvips shift.dvi -o shift.ps
%DVIPSSource:  TeX output 1996.08.14:1133
%%BeginProcSet: tex.pro
/TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N
/X{S N}B /TR{translate}N /isls false N /vsize 11 72 mul N /hsize 8.5 72
mul N /landplus90{false}def /@rigin{isls{[0 landplus90{1 -1}{-1 1}
ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale
isls{landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div
hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul
TR matrix currentmatrix dup dup 4 get round 4 exch put dup dup 5 get
round 5 exch put setmatrix}N /@landscape{/isls true N}B /@manualfeed{
statusdict /manualfeed true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0
0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{/nn 8 dict N nn
begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N string /base X
array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N end dup{/foo
setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{/sf 1 N /fntrx
FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]N df-tail}B /E{
pop nn dup definefont setfont}B /ch-width{ch-data dup length 5 sub get}
B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{128 ch-data dup
length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub get 127 sub}B
/ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data dup type
/stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp
0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2
index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff
ch-yoff ch-height sub ch-xoff ch-width add ch-yoff setcachedevice
ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff .1 add]{
ch-image}imagemask restore}B /D{/cc X dup type /stringtype ne{]}if nn
/base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup length 1
sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{cc 1 add D
}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin 0 0
moveto /V matrix currentmatrix dup 1 get dup mul exch 0 get dup mul add
.99 lt{/QV}{/RV}ifelse load def pop pop}N /eop{SI restore showpage
userdict /eop-hook known{eop-hook}if}N /@start{userdict /start-hook
known{start-hook}if pop /VResolution X /Resolution X 1000 div /DVImag X
/IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for
65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N /RMat[1 0 0 -1 0
0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V
{}B /RV statusdict begin /product where{pop product dup length 7 ge{0 7
getinterval dup(Display)eq exch 0 4 getinterval(NeXT)eq or}{pop false}
ifelse}{false}ifelse end{{gsave TR -.1 -.1 TR 1 1 scale rulex ruley
false RMat{BDot}imagemask grestore}}{{gsave TR -.1 -.1 TR rulex ruley
scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /QV{gsave
transform round exch round exch itransform moveto rulex 0 rlineto 0
ruley neg rlineto rulex neg 0 rlineto fill grestore}B /a{moveto}B /delta
0 N /tail{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{S p tail}
B /c{-4 M}B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{
3 M}B /k{4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p
-1 w}B /q{p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{
3 2 roll p a}B /bos{/SS save N}B /eos{SS restore}B end
%%EndProcSet
TeXDict begin 40258431 52099146 1000 300 300
(/tmp_mnt/home/R4D/dbc/pcrc/doc/shift.dvi) @start /Fa
4 100 df<FFFFFF80FFFFFF8019027D8A20>0 D<01800180018001804182F18F399C0FF0
03C003C00FF0399CF18F4182018001800180018010127E9215>3
D<4000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C0
00C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C0
00C000C000C000C000FFC07FC00A2A799E12>98 D<004000C000C000C000C000C000C000
C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000
C000C000C000C000C000C000C000C000C000C000C000C000C000C000C0FFC0FFC00A2A80
9E12>I E /Fb 1 49 df<040E0E1C1C1C38383070706060C0C0070F7F8F0A>48
D E /Fc 5 115 df<387CFEFEFE7C380000000000000000387CFEFEFE7C3807167C9510>
58 D<FFFFFF00FFFFFFE007F007F007F001FC07F000FC07F0007E07F0007E07F0007F07
F0007F07F0007F07F0007F07F0007F07F0007E07F0007E07F000FC07F001FC07F007F007
FFFFE007FFFF0007F0000007F0000007F0000007F0000007F0000007F0000007F0000007
F0000007F0000007F0000007F0000007F0000007F00000FFFF8000FFFF800020227EA126
>80 D<003F8000FFC001E3E003C7E007C7E00F87E00F83C00F80000F80000F80000F8000
0F80000F8000FFFC00FFFC000F80000F80000F80000F80000F80000F80000F80000F8000
0F80000F80000F80000F80000F80000F80000F80000F80000F80000F80007FF8007FF800
13237FA211>102 D<00FE0007FFC00F83E01E00F03E00F87C007C7C007C7C007CFC007E
FC007EFC007EFC007EFC007EFC007EFC007E7C007C7C007C3E00F81F01F00F83E007FFC0
00FE0017167E951C>111 D<FE1F00FE3FC01E67E01EC7E01E87E01E87E01F83C01F0000
1F00001F00001F00001F00001F00001F00001F00001F00001F00001F00001F00001F0000
FFF000FFF00013167E9517>114 D E /Fd 3 122 df<02000600060006000C00FF800C00
0C001800180018001800300031003100320032001C0009127F910D>116
D<0E3C13CE238E430C43000300030006000608C608E610CA2071C00F0D7F8C13>120
D<38184C184C188C3098301830183030603060306030E011C00EC000C00080E180E30046
003C000D137F8C11>I E /Fe 10 120 df<00010003000600060006000C000C000C0018
001800180030003000300060006000C000C000C001800180018003000300030006000600
0C000C000C00180018001800300030003000600060006000C000C00010297E9E15>61
D<01E3000717000C0F00180F00380E00300E00700E00700E00E01C00E01C00E01C00E01C
00E03880E03880E038806078803199001E0E0011127E9116>97 D<01C003C003C0018000
00000000000000000000001C00270047004700870087000E000E001C001C001C00380038
8038807080710032001C000A1C7E9B0E>105 D<0007000F000F00060000000000000000
000000000070009C010C020C021C041C001C001C00380038003800380070007000700070
00E000E000E000E001C061C0F180F300E6007C001024809B11>I<0FC00001C00001C000
0380000380000380000380000700000700000700000700000E07000E18800E21C00E23C0
1C47801C83001D00001E00003F800039C00038E00038E00070E10070E10070E10070E200
E06200603C00121D7E9C16>I<1F800380038007000700070007000E000E000E000E001C
001C001C001C0038003800380038007000700070007000E400E400E400E4006400380009
1D7E9C0C>I<381F81F04E20C6184640E81C4680F01C8F00F01C8E00E01C0E00E01C0E00
E01C1C01C0381C01C0381C01C0381C01C0703803807138038071380380E1380380E27007
00643003003820127E9124>I<381F004E61804681C04701C08F01C08E01C00E01C00E01
C01C03801C03801C03801C0700380710380710380E10380E2070064030038014127E9119
>I<01F0060C04040C0E180C1C001F000FE00FF003F80038201C7018F018F01080306060
1F800F127E9113>115 D<1C00C0802701C1C04701C1C04701C0C087038040870380400E
0380400E0380401C0700801C0700801C0700801C07010018060100180602001C0E02001C
0F04000E13080003E1F0001A127E911E>119 D E /Ff 38 122 df<60F0F0F0F0F0F0F0
F0F0F0F0F0F0F0F0600000000060F0F0600419779816>33 D<00C00001C00001C00001C0
0007F0001FFC003FFE007DCF0071C780E1C380E1C780E1C780F1C30079C0003FC0001FF0
0007FC0001FE0001CF0001C70061C380F1C380F1C380E1C38071C70079DF003FFE001FF8
0007E00001C00001C00000C00011207E9C16>36 D<30787C3C1C1C1C1C3878F0E040060D
789816>39 D<00E001E0038007000E001C001C0038003800700070007000E000E000E000
E000E000E000E000E000E000700070007000380038001C001C000E000700038001E000E0
0B217A9C16>I<C000E000700038001C000E000E000700070003800380038001C001C001
C001C001C001C001C001C001C0038003800380070007000E000E001C0038007000E000C0
000A217B9C16>I<01C00001C00001C00001C00071C700F9CF807FFF001FFC0007F00007
F0001FFC007FFF00F9CF8071C70001C00001C00001C00001C00011127E9516>I<01C000
01C00001C00001C00001C00001C00001C00001C000FFFF80FFFF80FFFF8001C00001C000
01C00001C00001C00001C00001C00001C00011137E9516>I<387C7E7E3E0E1E1C78F060
070B798416>I<FFFF80FFFF80FFFF8011037E8D16>I<03E0000FF8001FFC001E3C00380E
00780F00700700700700E00380E00380E00380E00380E00380E00380E00380E00380F007
80700700700700780F003C1E001E3C001FFC000FF80003E00011197E9816>48
D<01800380038007800F807F80FF80738003800380038003800380038003800380038003
8003800380038003807FF87FFC7FF80E197C9816>I<70F8F8F870000000000000000070
F8F8F8700512789116>58 D<00E00001F00001F00001B00001B00003B80003B80003B800
031800071C00071C00071C00071C00071C000E0E000E0E000FFE000FFE001FFF001C0700
1C07001C07007F1FC0FF1FE07F1FC013197F9816>65 D<7FF800FFFE007FFF001C0F001C
07801C03801C03801C03801C07801C07001FFF001FFE001FFE001C1F001C03801C03C01C
01C01C01C01C01C01C01C01C03C01C07807FFF80FFFF007FFC0012197F9816>I<01F180
07FB800FFF801F0F803C0780380380700380700380F00000E00000E00000E00000E00000
E00000E00000E00000F000007003807003803803803C07001F0F000FFE0007FC0001F000
11197E9816>I<7FF800FFFE007FFF001C0F001C07801C03C01C01C01C01C01C01E01C00
E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C01C01C01C01C03C01C07801C0F
807FFF00FFFE007FF8001319809816>I<7FFFC0FFFFC07FFFC01C01C01C01C01C01C01C
01C01C00001C00001C1C001C1C001FFC001FFC001FFC001C1C001C1C001C00001C00E01C
00E01C00E01C00E01C00E07FFFE0FFFFE07FFFE013197F9816>I<FFFFE0FFFFE0FFFFE0
1C00E01C00E01C00E01C00E01C00001C00001C1C001C1C001FFC001FFC001FFC001C1C00
1C1C001C00001C00001C00001C00001C00001C0000FF8000FFC000FF800013197F9816>
I<03E30007FF000FFF001E1F003C0F00380700700700700700F00000E00000E00000E000
00E00000E03F80E07FC0E03F80F00700700700700700380F003C0F001E1F000FFF0007F7
0003E70012197E9816>I<7F1FC0FFBFE07F1FC01C07001C07001C07001C07001C07001C
07001C07001FFF001FFF001FFF001C07001C07001C07001C07001C07001C07001C07001C
07001C07007F1FC0FFBFE07F1FC013197F9816>I<FFFEFFFEFFFE038003800380038003
8003800380038003800380038003800380038003800380038003800380FFFEFFFEFFFE0F
197D9816>I<7F0FE0FF8FF07F0FE01C07801C0F001C0E001C1C001C3C001C78001CF000
1CE0001DF0001FF0001FF8001F38001E1C001C1C001C0E001C0E001C07001C07001C0380
7F07E0FF8FF07F07E01419809816>75 D<FFC000FFC000FFC0001C00001C00001C00001C
00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00401C
00E01C00E01C00E01C00E0FFFFE0FFFFE0FFFFE013197F9816>I<FC07E0FE0FE0FE0FE0
3A0B803B1B803B1B803B1B803B1B803B1B803BBB8039B38039B38039B38039B38039F380
38E38038E380380380380380380380380380380380FE0FE0FE0FE0FE0FE013197F9816>
I<7E1FC0FF3FE07F1FC01D07001D87001D87001D87001DC7001DC7001CC7001CC7001CE7
001CE7001CE7001C67001C67001C77001C77001C37001C37001C37001C17007F1F00FF9F
007F0F0013197F9816>I<1FFC003FFE007FFF00780F00F00780E00380E00380E00380E0
0380E00380E00380E00380E00380E00380E00380E00380E00380E00380E00380F00780F0
0780780F007FFF003FFE001FFC0011197E9816>I<7FF800FFFE007FFF001C0F801C0380
1C03C01C01C01C01C01C01C01C03C01C03801C0F801FFF001FFE001FF8001C00001C0000
1C00001C00001C00001C00001C00007F0000FF80007F000012197F9816>I<7FE000FFF8
007FFC001C1E001C0F001C07001C07001C07001C07001C0F001C1E001FFC001FF8001FFC
001C1C001C0E001C0E001C0E001C0E001C0E201C0E701C0E707F07E0FF87E07F03C01419
7F9816>82 D<07E3001FFF003FFF00781F00F00700E00700E00700E00000F00000780000
3F80001FF00007FC0000FE00000F00000700000380000380600380E00380E00700F80F00
FFFE00FFFC00C7F00011197E9816>I<7FFFE0FFFFE0FFFFE0E0E0E0E0E0E0E0E0E0E0E0
E000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E0
0000E00000E00000E00007FC000FFE0007FC0013197F9816>I<7F07F0FF8FF87F07F01C
01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C
01C01C01C01C01C01C01C00E03800E038007070007FF0003FE0000F8001519809816>I<
FC07E0FE0FE0FC07E07001C07001C07001C030018038038038038038038038E38039F380
39F38039B38019B30019B30019B30019B30019B30019B3001913001B1B000F1E000F1E00
0E0E0013197F9816>87 D<018003C003C0018000000000000000007FC07FC07FC001C001
C001C001C001C001C001C001C001C001C001C001C07FFFFFFF7FFF101A7D9916>105
D<7E3C00FEFE007FFF000F87800F03800E03800E03800E03800E03800E03800E03800E03
800E03800E03800E03807FC7F0FFE7F87FC7F01512809116>110
D<7E3E00FEFF007FFF800F83C00F00E00E00E00E00700E00700E00700E00700E00700E00
700E00E00F01E00F83C00FFF800EFF000E3C000E00000E00000E00000E00000E00000E00
007FC000FFE0007FC000141B809116>112 D<0300000700000700000700000700007FFF
00FFFF00FFFF000700000700000700000700000700000700000700000701000703800703
8007038007870003FE0001FC0000F80011177F9616>116 D<7F1FC07F3FC07F1FC00F1C
00073C0003B80003F00001F00000E00001E00001F00003B800073C00071C000E0E007F1F
C0FF3FE07F1FC013127F9116>120 D<7F1FC0FF9FE07F1FC01C07000E07000E0E000E0E
00070E00071C00071C00039C00039C0003980001B80001B80000F00000F00000F00000E0
0000E00000E00001C00079C0007BC0007F80003F00003C0000131B7F9116>I
E /Fg 49 123 df<007E1F0001C1B1800303E3C00703C3C00E03C1800E01C0000E01C000
0E01C0000E01C0000E01C0000E01C000FFFFFC000E01C0000E01C0000E01C0000E01C000
0E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C000
0E01C0000E01C0000E01C0007F87FC001A1D809C18>11 D<6060F0F0F8F8686808080808
0808101010102020404080800D0C7F9C15>34 D<004000800100020006000C000C001800
1800300030007000600060006000E000E000E000E000E000E000E000E000E000E000E000
E000600060006000700030003000180018000C000C00060002000100008000400A2A7D9E
10>40 D<800040002000100018000C000C000600060003000300038001800180018001C0
01C001C001C001C001C001C001C001C001C001C001C00180018001800380030003000600
06000C000C00180010002000400080000A2A7E9E10>I<00060000000600000006000000
060000000600000006000000060000000600000006000000060000000600000006000000
060000FFFFFFE0FFFFFFE000060000000600000006000000060000000600000006000000
0600000006000000060000000600000006000000060000000600001B1C7E9720>43
D<60F0F0701010101020204080040C7C830C>I<FFE0FFE00B0280890E>I<60F0F0600404
7C830C>I<03C00C301818300C300C700E60066006E007E007E007E007E007E007E007E0
07E007E007E007E007E00760066006700E300C300C18180C3007E0101D7E9B15>48
D<030007003F00C700070007000700070007000700070007000700070007000700070007
00070007000700070007000700070007000F80FFF80D1C7C9B15>I<07C01830201C400C
400EF00FF80FF807F8077007000F000E000E001C001C00380070006000C0018003000601
0C01180110023FFE7FFEFFFE101C7E9B15>I<60F0F0600000000000000000000060F0F0
6004127C910C>58 D<7FFFFFC0FFFFFFE000000000000000000000000000000000000000
00000000000000000000000000FFFFFFE07FFFFFC01B0C7E8F20>61
D<000600000006000000060000000F0000000F0000000F00000017800000178000001780
000023C0000023C0000023C0000041E0000041E0000041E0000080F0000080F0000180F8
000100780001FFF80003007C0002003C0002003C0006003E0004001E0004001E000C001F
001E001F00FF80FFF01C1D7F9C1F>65 D<FFFFC00F00F00F00380F003C0F001C0F001E0F
001E0F001E0F001E0F001C0F003C0F00780F01F00FFFE00F00780F003C0F001E0F000E0F
000F0F000F0F000F0F000F0F000F0F001E0F001E0F003C0F0078FFFFE0181C7E9B1D>I<
001F808000E0618001801980070007800E0003801C0003801C0001803800018078000080
7800008070000080F0000000F0000000F0000000F0000000F0000000F0000000F0000000
F0000000700000807800008078000080380000801C0001001C0001000E00020007000400
0180080000E03000001FC000191E7E9C1E>I<FFFFF80F00780F00180F00080F00080F00
0C0F00040F00040F02040F02000F02000F02000F06000FFE000F06000F02000F02000F02
000F02000F00000F00000F00000F00000F00000F00000F00000F8000FFF800161C7E9B1B
>70 D<FFF3FFC00F003C000F003C000F003C000F003C000F003C000F003C000F003C000F
003C000F003C000F003C000F003C000F003C000FFFFC000F003C000F003C000F003C000F
003C000F003C000F003C000F003C000F003C000F003C000F003C000F003C000F003C000F
003C00FFF3FFC01A1C7E9B1F>72 D<FFF00F000F000F000F000F000F000F000F000F000F
000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F00FFF00C
1C7F9B0F>I<FF007FC00F800E000F8004000BC0040009E0040009E0040008F0040008F8
040008780400083C0400083C0400081E0400080F0400080F0400080784000807C4000803
C4000801E4000801E4000800F40008007C0008007C0008003C0008003C0008001C000800
0C001C000C00FF8004001A1C7E9B1F>78 D<FFFF800F00E00F00780F003C0F001C0F001E
0F001E0F001E0F001E0F001E0F001C0F003C0F00780F00E00FFF800F00000F00000F0000
0F00000F00000F00000F00000F00000F00000F00000F00000F0000FFF000171C7E9B1C>
80 D<07E0801C1980300580700380600180E00180E00080E00080E00080F00000F80000
7C00007FC0003FF8001FFE0007FF0000FF80000F800007C00003C00001C08001C08001C0
8001C0C00180C00180E00300D00200CC0C0083F800121E7E9C17>83
D<7FFFFFC0700F01C0600F00C0400F0040400F0040C00F0020800F0020800F0020800F00
20000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F00
00000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000001F80
0003FFFC001B1C7F9B1E>I<FFF07FC00F000E000F0004000F0004000F0004000F000400
0F0004000F0004000F0004000F0004000F0004000F0004000F0004000F0004000F000400
0F0004000F0004000F0004000F0004000F0004000F0004000F0004000700080007800800
038010000180100000C020000070C000001F00001A1D7E9B1F>I<080810102020404040
40808080808080B0B0F8F8787830300D0C7A9C15>92 D<1FC000307000783800781C0030
1C00001C00001C0001FC000F1C00381C00701C00601C00E01C40E01C40E01C40603C4030
4E801F870012127E9115>97 D<FC00001C00001C00001C00001C00001C00001C00001C00
001C00001C00001C00001C7C001D86001E03001C01801C01C01C00C01C00E01C00E01C00
E01C00E01C00E01C00E01C00C01C01C01C01801E030019060010F800131D7F9C17>I<07
E00C301878307870306000E000E000E000E000E000E00060007004300418080C3007C00E
127E9112>I<003F00000700000700000700000700000700000700000700000700000700
00070003E7000C1700180F00300700700700600700E00700E00700E00700E00700E00700
E00700600700700700300700180F000C370007C7E0131D7E9C17>I<03E00C301818300C
700E6006E006FFFEE000E000E000E00060007002300218040C1803E00F127F9112>I<00
F8018C071E061E0E0C0E000E000E000E000E000E00FFE00E000E000E000E000E000E000E
000E000E000E000E000E000E000E000E000E007FE00F1D809C0D>I<00038003C4C00C38
C01C3880181800381C00381C00381C00381C001818001C38000C300013C0001000003000
001800001FF8001FFF001FFF803003806001C0C000C0C000C0C000C06001803003001C0E
0007F800121C7F9215>I<FC00001C00001C00001C00001C00001C00001C00001C00001C
00001C00001C00001C7C001C87001D03001E03801C03801C03801C03801C03801C03801C
03801C03801C03801C03801C03801C03801C03801C0380FF9FF0141D7F9C17>I<18003C
003C0018000000000000000000000000000000FC001C001C001C001C001C001C001C001C
001C001C001C001C001C001C001C001C00FF80091D7F9C0C>I<FC00001C00001C00001C
00001C00001C00001C00001C00001C00001C00001C00001C3FC01C0F001C0C001C08001C
10001C20001C40001CE0001DE0001E70001C78001C38001C3C001C1C001C0E001C0F001C
0F80FF9FE0131D7F9C16>107 D<FC001C001C001C001C001C001C001C001C001C001C00
1C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C00FF80
091D7F9C0C>I<FC7E07E0001C838838001D019018001E01E01C001C01C01C001C01C01C
001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C00
1C01C01C001C01C01C001C01C01C001C01C01C00FF8FF8FF8021127F9124>I<FC7C001C
87001D03001E03801C03801C03801C03801C03801C03801C03801C03801C03801C03801C
03801C03801C03801C0380FF9FF014127F9117>I<03F0000E1C00180600300300700380
600180E001C0E001C0E001C0E001C0E001C0E001C06001807003803003001806000E1C00
03F00012127F9115>I<FC7C001D86001E03001C01801C01C01C00C01C00E01C00E01C00
E01C00E01C00E01C00E01C01C01C01C01C01801E03001D06001CF8001C00001C00001C00
001C00001C00001C00001C0000FF8000131A7F9117>I<FCE01D301E781E781C301C001C
001C001C001C001C001C001C001C001C001C001C00FFC00D127F9110>114
D<1F9030704030C010C010E010F8007F803FE00FF000F880388018C018C018E010D0608F
C00D127F9110>I<04000400040004000C000C001C003C00FFE01C001C001C001C001C00
1C001C001C001C001C101C101C101C101C100C100E2003C00C1A7F9910>I<FC1F801C03
801C03801C03801C03801C03801C03801C03801C03801C03801C03801C03801C03801C03
801C07800C07800E1B8003E3F014127F9117>I<FF07E03C03801C01001C01000E02000E
020007040007040007040003880003880003D80001D00001D00000E00000E00000E00000
400013127F9116>I<FF3FCFE03C0F03801C0701801C0701001C0B01000E0B82000E0B82
000E1182000711C4000711C4000720C40003A0E80003A0E80003C0680001C0700001C070
0001803000008020001B127F911E>I<7F8FF00F03800F030007020003840001C80001D8
0000F00000700000780000F800009C00010E00020E000607000403801E07C0FF0FF81512
809116>I<FF07E03C03801C01001C01000E02000E020007040007040007040003880003
880003D80001D00001D00000E00000E00000E000004000004000008000008000F08000F1
0000F300006600003C0000131A7F9116>I<7FFC70386038407040F040E041C003C00380
07000F040E041C043C0C380870087038FFF80E127F9112>I E /Fh
13 117 df<0700E00F81F01F83F01F83F01F83F00E81D000801000801001002001002002
0040020040040080080100100200200400400800801000141275A91F>34
D<003FFFE7FFFC003FFFE7FFFC0001F8003F000001F0003E000001F0003E000001F0003E
000001F0003E000003E0007C000003E0007C000003E0007C000003E0007C000007C000F8
000007C000F8000007C000F8000007C000F800000F8001F000000F8001F000000F8001F0
00000F8001F000001FFFFFE000001FFFFFE000001F0003E000001F0003E000003E0007C0
00003E0007C000003E0007C000003E0007C000007C000F8000007C000F8000007C000F80
00007C000F800000F8001F000000F8001F000000F8001F000000F8001F000001F0003E00
0001F0003E000001F0003E000003F0007E00007FFF8FFFF000FFFF9FFFF0002E297CA82C
>72 D<00003F010001FFC30003C0E70007007F000E003E001C001E0038001E0078001E00
70001C00F0001C00F0001C00F0001C01F0001801F0001801F0000001F8000000FC000000
FF000000FFF000007FFE00003FFF00001FFF800003FFC000007FC000000FE0000003E000
0003E0000003E0000001E0180001E0180001E0180001E0380003C0380003C03800038038
000780780007007C000E007C001C0077003800E3C0F000C1FFE000807F0000202B7BA922
>83 D<008010010020020040040080080100100200100200200400200400400800400800
4008009C1380BE17C0FE1FC0FE1FC07C0F80380700141270A91F>92
D<0000078000001840000038E0000071E0000073E00000F3E00000F1C00000F0000001E0
000001E0000001E0000001E0000001E0000003C0000003C0000003C00000FFFF0000FFFF
000007800000078000000780000007800000078000000F0000000F0000000F0000000F00
00000F0000001E0000001E0000001E0000001E0000001E0000003C0000003C0000003C00
00003C0000003C0000007800000078000000780000007800000078000000F0000000F000
0000F0000000E0000031E0000079E00000F9C00000F9800000F3800000630000003C0000
001B3681A912>102 D<003C000007FC000007FC0000007C000000780000007800000078
00000078000000F0000000F0000000F0000000F0000001E0000001E0000001E0000001E0
000003C3E00003CC380003D01C0003E01C0007E01E0007C01E0007801E0007801E000F00
3C000F003C000F003C000F003C001E0078001E0078001E0078001E00F0003C00F0003C00
F0603C01E0603C01E0407801E0C07803C0807801C1807801C300F000C600600078001B2A
7BA91F>104 D<001C003E003E003C003800000000000000000000000000000000000007
800CE0186030F030F060F060F061E0C1E001E003C003C00780078007800F000F000F0C1E
0C1E0C1E183C181C301C200C4007800F287BA712>I<07807E00F80008C1C3830E0010E3
01C4070030F601C8070030FC01F8078060F801F0078060F001E0078060F001E00780C1E0
03C00F0001E003C00F0001E003C00F0001E003C00F0003C007801E0003C007801E0003C0
07801E0003C007803C0007800F003C0007800F003C1807800F00781807800F0078100F00
1E0078300F001E00F0200F001E0070600F001E0070C01E003C0031800C0018001E002D1A
7B9931>109 D<000FC000787000E03803C01C07801C0F001E1F001E1E001F3E001F3C00
1F7C001F7C001FF8003EF8003EF8003EF8003CF0007CF00078F000F8F000F07001E07801
C03803801807000E1C0003F000181A79991F>111 D<00780F80008C18E0010E6070030F
C070030F8078060F0038060F007C060F007C0C1E007C001E007C001E007C001E007C003C
00F8003C00F8003C00F8003C00F0007801F0007801F0007801E0007803C000F803C000F8
078000F8070000FC0E0001E6380001E3E00001E0000001E0000003C0000003C0000003C0
000003C000000780000007800000078000000F8000007FF80000FFF800001E267F991F>
I<0781F808C30C10E40E30FC1E30F83E60F03E60F01C60F000C1E00001E00001E00001E0
0003C00003C00003C00003C0000780000780000780000780000F00000F00000F00000F00
001E00000C0000171A7B9919>114 D<003F0000E0C001C0600380600300E00701E00701
E00700C007800007E00007FC0007FE0003FF0001FF80001F800007800007803803807C03
807C0380F80700700600600E00600C003830000FC000131A7B9918>I<00300078007800
F000F000F000F001E001E001E001E0FFFFFFFF03C003C007800780078007800F000F000F
000F001E001E001E001E003C003C063C063C0C780C78183810383018400F8010257AA414
>I E end
%%EndProlog
%%BeginSetup
%%Feature: *Resolution 300dpi
TeXDict begin

%%EndSetup
%%Page: 1 1
1 0 bop 262 307 a Fh(\\Shift)20 b(Homomorphism")262 398
y Fg(Consider)14 b(the)g(follo)o(wing)e(fragmen)o(t)g(of)h(HPF)i
(pseudo)q(co)q(de:)262 476 y Ff(!HPF$)34 b(TEMPLATE)20
b(tx)i(\(0)f(:)43 b(\),)22 b(ty)f(\(0)h(:)43 b(\))262
526 y(!HPF$)34 b(DISTRIBUTE)20 b(tx)h(\(BLOCK)g(\()p
Fe(w)916 532 y Fd(x)936 526 y Ff(\)\))h(ONTO)f(p)262
576 y(!HPF$)34 b(DISTRIBUTE)20 b(ty)h(\(BLOCK)g(\()p
Fe(w)916 582 y Fd(y)935 576 y Ff(\)\))h(ONTO)f(p)262
675 y(!HPF$)34 b(DIMENSION)20 b(x)i(\(0)f(:)43 b(n)22
b(-)g(1\),)f(y)g(\(0)h(:)43 b(n)22 b(-)f(1\))262 725
y(!HPF$)34 b(ALIGN)21 b(x)g(\(i\))h(WITH)f(tx)g(\()p
Fe(k)886 731 y Fd(x)906 725 y Ff(+)h Fe(s)969 731 y Fd(tx)1003
725 y Ff(*)f(i\))262 775 y(!HPF$)34 b(ALIGN)21 b(y)g(\(i\))h(WITH)f(ty)
g(\()p Fe(k)886 781 y Fd(y)905 775 y Ff(+)h Fe(s)968
781 y Fd(ty)1001 775 y Ff(*)f(i\))406 875 y Fg(x)14 b(=)g(y)262
953 y(By)9 b(suitable)h(comp)q(osition)e(of)h(section)h(and)g(alignmen)
o(t)d(parameters,)j(p)q(ossibly)g(com)o(bined)262 1003
y(with)j(trivial)f(relab)q(elling)g(so)i(that)f(index)h(ranges)g(start)
g(at)f(0,)g(an)o(y)g(assignmen)o(t)f(b)q(et)o(w)o(een)262
1052 y(one-dimensional)g(sections)k(blo)q(c)o(k-distributed)f(o)o(v)o
(er)g(the)h(same)e(one-dimensional)f(pro-)262 1102 y(cessor)i
(arrangemen)o(t)e(can)h(b)q(e)h(reduced)g(to)f(this)g(case.)324
1152 y(The)g(arra)o(ys)g Ff(x)g Fg(and)f Ff(y)h Fg(are)g
(\\shift-homomo)o(rphic")d(i\013)827 1237 y Fe(s)846
1243 y Fd(tx)879 1237 y Fe(=w)930 1243 y Fd(x)962 1237
y Fg(=)h Fe(s)1025 1243 y Fd(ty)1058 1237 y Fe(=w)1109
1243 y Fd(y)262 1323 y Fg(If)h(this)g(condition)g(holds)g(the)h
(assignmen)o(t)e(of)h Ff(y)g Fg(to)g Ff(x)h Fg(can)f(b)q(e)h(implemen)o
(ted)d(b)o(y)j(shifting)262 1372 y(the)g(v)n(alues)g(of)f
Ff(y)h Fg(along)e(template)h Ff(ty)h Fg(then)g(p)q(erforming)f(a)g(lo)q
(cal)g(cop)o(y)m(.)262 1487 y Fc(Pro)r(of:)262 1564 y
Fg(The)18 b(elemen)o(t)f Fe(i)h Fg(of)f Ff(x)h Fg(is)f(aligned)g(with)h
(elemen)o(t)f Fe(k)1101 1570 y Fd(x)1133 1564 y Fg(+)12
b Fe(s)1196 1570 y Fd(tx)1230 1564 y Fe(i)18 b Fg(of)f(template)g
Ff(tx)g Fg(and)h(the)262 1614 y(elemen)o(t)13 b Fe(i)h
Fg(of)f Ff(y)h Fg(is)g(aligned)f(with)g(elemen)o(t)h
Fe(k)981 1620 y Fd(y)1009 1614 y Fg(+)c Fe(s)1070 1620
y Fd(ty)1103 1614 y Fe(i)k Fg(of)f(template)g Ff(ty)p
Fg(.)324 1664 y(A)h(temp)q(orary)f(arra)o(y)h Ff(y')f
Fg(is)h(created)h(b)o(y)f(shifting)f(the)h(v)n(alues)g(in)f
Ff(y)h Fg(b)o(y)g(amoun)o(t)872 1749 y Fe(a)d Fg(=)h
Fe(k)972 1732 y Fb(0)971 1759 y Fd(y)1000 1749 y Fa(\000)e
Fe(k)1064 1755 y Fd(y)262 1834 y Fg(along)18 b(template)h
Ff(ty)p Fg(.)34 b(So)19 b(elemen)o(t)g Fe(i)h Fg(of)f
Ff(y')g Fg(is)h(aligned)e(with)i(elemen)o(t)f Fe(k)1498
1819 y Fb(0)1497 1844 y Fd(y)1529 1834 y Fg(+)13 b Fe(s)1593
1840 y Fd(ty)1626 1834 y Fe(i)20 b Fg(of)262 1884 y(template)12
b Ff(ty)p Fg(.)324 1934 y(In)i(particular,)f(c)o(ho)q(ose)829
1984 y Fe(k)852 1966 y Fb(0)851 1994 y Fd(y)882 1984
y Fg(=)f Fa(b)p Fe(k)966 1990 y Fd(x)987 1984 y Fe(w)1017
1990 y Fd(y)1036 1984 y Fe(=w)1087 1990 y Fd(x)1108 1984
y Fa(c)262 2055 y Fg(so)h(the)i(alignmen)o(t)d(of)h(elemen)o(t)g
Fe(i)h Fg(of)g Ff(y')f Fg(is)h(to)f(elemen)o(t)640 2140
y Fe(k)663 2123 y Fb(0)662 2150 y Fd(y)691 2140 y Fg(+)d
Fe(s)752 2146 y Fd(ty)785 2140 y Fe(i)42 b Fg(=)f Fa(b)p
Fe(k)954 2146 y Fd(x)975 2140 y Fe(w)1005 2146 y Fd(y)1025
2140 y Fe(=w)1076 2146 y Fd(x)1096 2140 y Fa(c)10 b Fg(+)g
Fe(s)1185 2146 y Fd(ty)1217 2140 y Fe(i)841 2202 y Fg(=)41
b Fa(b)p Fe(k)954 2208 y Fd(x)975 2202 y Fe(w)1005 2208
y Fd(y)1025 2202 y Fe(=w)1076 2208 y Fd(x)1106 2202 y
Fg(+)9 b Fe(s)1166 2208 y Fd(ty)1199 2202 y Fe(i)p Fa(c)841
2264 y Fg(=)41 b Fa(b)p Fg(\()p Fe(k)970 2270 y Fd(x)991
2264 y Fe(w)1021 2270 y Fd(y)1050 2264 y Fg(+)10 b Fe(s)1111
2270 y Fd(ty)1144 2264 y Fe(w)1174 2270 y Fd(x)1194 2264
y Fe(i)p Fg(\))p Fe(=w)1275 2270 y Fd(x)1296 2264 y Fa(c)262
2350 y Fg(of)j(template)g Ff(ty)p Fg(.)324 2399 y(No)o(w,)e(elemen)o(t)
f Fe(j)595 2405 y Fd(x)628 2399 y Fg(of)g(template)g
Ff(tx)h Fg(is)g(mapp)q(ed)g(to)g(pro)q(cessor)i Fa(b)p
Fe(j)1354 2405 y Fd(x)1375 2399 y Fe(=w)1426 2405 y Fd(x)1446
2399 y Fa(c)f Fg(and)f(elemen)o(t)262 2449 y Fe(j)279
2455 y Fd(y)312 2449 y Fg(of)j(template)f Ff(ty)g Fg(is)h(mapp)q(ed)f
(to)h(pro)q(cessor)h Fa(b)p Fe(j)1057 2455 y Fd(y)1078
2449 y Fe(=w)1129 2455 y Fd(y)1148 2449 y Fa(c)p Fg(.)967
2574 y(1)p eop
%%Page: 2 2
2 1 bop 324 307 a Fg(So)13 b(elemen)o(t)h Fe(i)g Fg(of)f
Ff(x)h Fg(is)g(mapp)q(ed)f(to)g(pro)q(cessor)827 399
y Fa(b)p Fg(\()p Fe(k)883 405 y Fd(x)913 399 y Fg(+)d
Fe(s)974 405 y Fd(tx)1008 399 y Fe(i)p Fg(\))p Fe(=w)1089
405 y Fd(x)1110 399 y Fa(c)262 490 y Fg(and)j(elemen)o(t)h
Fe(i)g Fg(of)f Ff(y')g Fg(is)h(mapp)q(ed)f(to)h(pro)q(cessor)829
581 y Fa(b)p Fg(\()p Fe(k)886 564 y Fb(0)885 591 y Fd(y)914
581 y Fg(+)9 b Fe(s)974 587 y Fd(ty)1007 581 y Fe(i)p
Fg(\))p Fe(=w)1088 587 y Fd(y)1108 581 y Fa(c)324 672
y Fg(But)517 764 y Fa(b)p Fg(\()p Fe(k)574 747 y Fb(0)573
774 y Fd(y)602 764 y Fg(+)h Fe(s)663 770 y Fd(ty)696
764 y Fe(i)p Fg(\))p Fe(=w)777 770 y Fd(y)797 764 y Fa(c)42
b Fg(=)f Fa(bb)p Fg(\()p Fe(k)1004 770 y Fd(x)1026 764
y Fe(w)1056 770 y Fd(y)1085 764 y Fg(+)9 b Fe(s)1145
770 y Fd(ty)1178 764 y Fe(w)1208 770 y Fd(x)1229 764
y Fe(i)p Fg(\))p Fe(=w)1310 770 y Fd(x)1331 764 y Fa(c)p
Fe(=w)1400 770 y Fd(y)1420 764 y Fa(c)857 826 y Fg(=)41
b Fa(b)p Fg(\()p Fe(k)986 832 y Fd(x)1008 826 y Fe(w)1038
832 y Fd(y)1066 826 y Fg(+)10 b Fe(s)1127 832 y Fd(ty)1160
826 y Fe(w)1190 832 y Fd(x)1211 826 y Fe(i)p Fg(\))p
Fe(=w)1292 832 y Fd(x)1312 826 y Fe(w)1342 832 y Fd(y)1362
826 y Fa(c)857 888 y Fg(=)41 b Fa(b)p Fe(k)970 894 y
Fd(x)991 888 y Fe(=w)1042 894 y Fd(x)1072 888 y Fg(+)10
b Fe(s)1133 894 y Fd(ty)1166 888 y Fe(i=w)1231 894 y
Fd(y)1250 888 y Fa(c)857 951 y Fg(=)41 b Fa(b)p Fg(\()p
Fe(k)986 957 y Fd(x)1017 951 y Fg(+)9 b Fe(s)1077 957
y Fd(tx)1111 951 y Fe(i)p Fg(\))p Fe(=w)1192 957 y Fd(x)1213
951 y Fa(c)262 1042 y Fg(In)k(the)i(second)g(step)g(w)o(e)f(used)h(a)e
(general)h(prop)q(ert)o(y)h(of)e(non-negativ)o(e)h(in)o(tegers:)789
1133 y Fa(bb)p Fe(l)q(=m)p Fa(c)p Fe(=n)p Fa(c)f Fg(=)f
Fa(b)p Fe(l)q(=mn)p Fa(c)262 1225 y Fg(and)h(in)h(the)g(last)g(step)h
(w)o(e)f(used)h(the)f(shift)g(homom)o(orphism)c(condition.)324
1274 y(This)18 b(establishes)i(that)f(elemen)o(ts)f Fe(i)h
Fg(of)f Ff(x)h Fg(and)f Ff(y')h Fg(map)e(to)h(the)h(same)f(pro)q
(cessor.)262 1324 y(Supp)q(ose)e(this)f(is)g(pro)q(cessor)i
Fe(n)p Fg(.)k(Assuming)14 b(arra)o(y)h(segmen)o(ts)g(are)h(allo)q
(cated)f(according)262 1374 y(to)e(the)i(template)e(size,)h(the)g(lo)q
(cal)f(subscript)j(in)d Ff(x)h Fg(is)770 1465 y Fe(l)782
1471 y Fd(x)815 1465 y Fg(=)e Fe(k)881 1471 y Fd(x)911
1465 y Fg(+)d Fe(s)971 1471 y Fd(tx)1005 1465 y Fe(i)h
Fa(\000)f Fe(n)g Fa(\003)g Fe(w)1164 1471 y Fd(x)262
1557 y Fg(and)k(the)i(lo)q(cal)e(subscript)i(in)e Ff(y')h
Fg(is)772 1648 y Fe(l)785 1631 y Fb(0)784 1658 y Fd(y)816
1648 y Fg(=)e Fe(k)883 1631 y Fb(0)882 1658 y Fd(y)911
1648 y Fg(+)d Fe(s)971 1654 y Fd(ty)1004 1648 y Fe(i)h
Fa(\000)f Fe(n)g Fa(\003)g Fe(w)1163 1654 y Fd(y)262
1739 y Fg(Using)k(the)i(shift)e(homomorphism)d(condition)j(giv)o(es)724
1831 y Fe(w)754 1837 y Fd(x)775 1831 y Fe(l)788 1813
y Fb(0)787 1841 y Fd(y)816 1831 y Fa(\000)d Fe(w)888
1837 y Fd(y)907 1831 y Fe(l)919 1837 y Fd(x)952 1831
y Fg(=)i Fe(w)1026 1837 y Fd(x)1047 1831 y Fe(k)1070
1813 y Fb(0)1069 1841 y Fd(y)1097 1831 y Fa(\000)e Fe(w)1169
1837 y Fd(y)1189 1831 y Fe(k)1211 1837 y Fd(x)262 1922
y Fg(or)671 1972 y Fe(l)684 1955 y Fb(0)683 1982 y Fd(y)715
1972 y Fg(=)i(\()p Fe(w)805 1978 y Fd(y)824 1972 y Fe(=w)875
1978 y Fd(x)896 1972 y Fg(\))p Fe(l)924 1978 y Fd(x)955
1972 y Fg(+)d(\()p Fe(k)1035 1955 y Fb(0)1034 1982 y
Fd(y)1063 1972 y Fa(\000)g Fe(w)1134 1978 y Fd(y)1154
1972 y Fe(k)1176 1978 y Fd(x)1197 1972 y Fe(=w)1248 1978
y Fd(x)1268 1972 y Fg(\))262 2046 y(as)k(the)i(relation)e(b)q(et)o(w)o
(een)j(the)e(lo)q(cal)f(subscripts.)967 2574 y(2)p eop
%%Trailer
end
userdict /end-hook known{end-hook}if
%%EOF


From dbc@npac.syr.edu Mon Feb  9 14:17 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id OAA03083; Mon, 9 Feb 1998 14:17:36 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id OAA19288; Mon, 9 Feb 1998 14:21:01 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802091921.OAA19288@weed.npac.syr.edu>
Subject: Re: your mail
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 9 Feb 1998 14:21:01 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter), lxm@[162.105.181.215],
        zgs@weed.npac.syr.edu (Guansong Zhang)
In-Reply-To: <Pine.HPP.3.91.980209171909.17759A@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Feb 9, 98 05:21:26 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2925
Status: RO


> 
> 
> Hi,
> 
> I am trying to port Adlib-2.00 to HPUX, but I failed to find the correct
> argc and argv AdlibInit needed. How can I decide the name from the Fortran
> runtime library?
> 
> 
> Gengbin Zheng

Hi Gengbin,

I wish I knew a better way of dealing with this problem, but at the moment
you just have to poke around until you find them.

Typically Fortran compilers have a -v flag or similar, which will
show you where the runtime libraries are located on the system.
Then you have to apply `nm' to the library files until you find something
that looks plausible.

Eg under Solaris I do


  % f77 -v test.f
  ### f77: Note: LM_LICENSE_FILE = /usr/local/flexlm/licenses/license.dat
  ### f77: Note: NLSPATH = /opt/SUNWspro/bin/../SC4.0/bin/../lib/locale/C/LC_MESSAGES/%N
  /opt/SUNWspro/bin/../SC4.0/bin/f77pass1 -y-o -ytest.o -y-fbe -y/opt/SUNWspro/bin/../SC4.0/bin/fbe -y-xarch=generic -y-s -ptk "-v " -xcache=generic -I/opt/SUNWspro/SC4.0/include/f77 -y-verbose test.f /tmp/f77pass1.02040.s.0.s test.o /tmp/f77pass1.02040.d.1.s
  test.f:
   MAIN:
  rm /tmp/f77pass1.02040.s.0.s
  rm /tmp/f77pass1.02040.d.1.s
  ### f77: Note: LD_LIBRARY_PATH = /usr/lib/X11:/home/R4D/dbc/HPJava/mpi:/home/R4D/dbc/HPJava/p4:.
  ### f77: Note: LD_RUN_PATH     = /opt/SUNWspro/lib
  ### f77: Note: LD_OPTIONS = (null)
  /usr/ccs/bin/ld -t -o a.out /opt/SUNWspro/SC4.0/lib/crti.o /opt/SUNWspro/SC4.0/lib/crt1.o /opt/SUNWspro/SC4.0/lib/values-xi.o -Y P,/opt/SUNWspro/lib:/opt/SUNWspro/SC4.0/lib:/usr/ccs/lib:/usr/lib test.o /opt/SUNWspro/SC4.0/lib/libM77.a -lF77 -lsunmath -lm -lcx -lc /opt/SUNWspro/SC4.0/lib/crtn.o
  rm test.o


>From this I guess that the libraries are in

  /opt/SUNWspro/SC4.0/lib/

In that directory I try

  % nm libF77.a | more

  [page of output]

  /argc              [enter search pattern "argc" for `more']
  ...skipping
  [5]     |         0|       0|NOTY |GLOB |0    |UNDEF  |__xargc
  [6]     |         0|       0|NOTY |GLOB |0    |UNDEF  |__xargv
  [7]     |         0|       0|NOTY |GLOB |0    |UNDEF  |__xenvp
  [20]    |         0|       0|NOTY |GLOB |0    |UNDEF  |_enable_sigfpe_master
  [9]     |         0|       0|NOTY |GLOB |0    |UNDEF  |f77_no_handlers
  [...]

This leads me to guess that the arguments are in...

  extern "C" {
    extern int __xargc ;
    extern char** __xargv ;
  }

in the Fortran RT.

Let me know what you find for HP.

If you have ideas for a better way of initializing MPI when the library
is written in C but the main program is in Fortran, please also let me
know.  It ought to be possible to copy the MPICH method for
initializing the MPI Fortran interface.  The trouble is that at the
time I was originally developing a Fortran interface to Adlib, the MPICH
method didn't work for some platforms (eg RS6000), which is why we
ended up with the current mechanism.  Maybe recent MPICH versions
have better technology, but I haven't got round to checking.

Bryan



From dbc@npac.syr.edu Thu Feb 12 22:09 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id WAA03746 for <dbc@postoffice.npac.syr.edu>; Thu, 12 Feb 1998 22:09:00 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id WAA01059; Thu, 12 Feb 1998 22:12:22 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802130312.WAA01059@weed.npac.syr.edu>
Subject: Re: pcrc_loc
To: zhenggb@pubms.pku.edu.cn
Date: Thu, 12 Feb 1998 22:12:21 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter), zheng.gb@svr.bimp.pku.edu
In-Reply-To: <Pine.GSO.3.95.980208181242.10449B-100000@pubms.pku.edu.cn> from "zhenggb@pubms.pku.edu.cn" at Feb 8, 98 06:26:21 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1159
Status: RO


I think this version of `pcrc_loc' should do what you want:

int pcrc_loc(int* rng, int* g_i) {
  Range x = *((Range*) ad_ToPointer(*rng)) ;
  int l_i ;

  const int glb = (*g_i - x.g_lb()) / x.g_stride() ;
  ker_glb(x.bas() + x.str() * glb, &l_i) ;
  return l_i ;
}

Let me know if there are any problems.

Did you find the argc, argv names for HP Fortran?

Bryan

> 
> 
>   I have a question on the meaning of pcrc_loc(int *rng, int *g_i)
> defined in pcrcFortran?
>   As I understand, it will return the offset of g_i to the template
> of this range. But I think this function should return the local index of
> g_i in a node program as an inverse function of pcrc_glob().
> 
>   Another question, if I have defined a range with ghostarea, how can I
> get the size of the ghostarea ?
> 
> 
> PS,
>  this is my new temperary e-mail adress, the old e-mail adress:
> zheng.gb@svr.bimp.pku.edu  can not be used due to the holiday.
> 
> 
> Gengbin Zheng
> ---------------------------------  
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:	   zhenggb@pubms.pku.edu.cn
> 
> 
> 


From dbc@npac.syr.edu Thu Feb 12 22:26 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id WAA03917 for <dbc@postoffice.npac.syr.edu>; Thu, 12 Feb 1998 22:26:08 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id WAA01084; Thu, 12 Feb 1998 22:29:40 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802130329.WAA01084@weed.npac.syr.edu>
Subject: Re: pcrc_loc (fwd)
To: zheng.gb@bimp.pku.edu.cn
Date: Thu, 12 Feb 1998 22:29:40 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter), zhenggb@pubms.pku.edu.cn
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2094
Status: RO


Sorry, that was wrong.  Try this

int pcrc_loc(int* rng, int* g_i) {
  Range x = *((Range*) ad_ToPointer(*rng)) ;
  int l_i ;

  const int glb = (*g_i - x.g_lb()) / x.g_stride() ;
  x.ker_glb(glb, &l_i) ;
  return l_i ;
}

Bryan

----- Forwarded message from Bryan Carpenter -----

>From dbc@npac.syr.edu Thu Feb 12 22:09 EST 1998
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802130312.WAA01059@weed.npac.syr.edu>
Subject: Re: pcrc_loc
To: zhenggb@pubms.pku.edu.cn
Date: Thu, 12 Feb 1998 22:12:21 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter), zheng.gb@svr.bimp.pku.edu
In-Reply-To: <Pine.GSO.3.95.980208181242.10449B-100000@pubms.pku.edu.cn> from "zhenggb@pubms.pku.edu.cn" at Feb 8, 98 06:26:21 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1159


I think this version of `pcrc_loc' should do what you want:

int pcrc_loc(int* rng, int* g_i) {
  Range x = *((Range*) ad_ToPointer(*rng)) ;
  int l_i ;

  const int glb = (*g_i - x.g_lb()) / x.g_stride() ;
  ker_glb(x.bas() + x.str() * glb, &l_i) ;
  return l_i ;
}

Let me know if there are any problems.

Did you find the argc, argv names for HP Fortran?

Bryan

> 
> 
>   I have a question on the meaning of pcrc_loc(int *rng, int *g_i)
> defined in pcrcFortran?
>   As I understand, it will return the offset of g_i to the template
> of this range. But I think this function should return the local index of
> g_i in a node program as an inverse function of pcrc_glob().
> 
>   Another question, if I have defined a range with ghostarea, how can I
> get the size of the ghostarea ?
> 
> 
> PS,
>  this is my new temperary e-mail adress, the old e-mail adress:
> zheng.gb@svr.bimp.pku.edu  can not be used due to the holiday.
> 
> 
> Gengbin Zheng
> ---------------------------------  
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:	   zhenggb@pubms.pku.edu.cn
> 
> 
> 


----- End of forwarded message from Bryan Carpenter -----

From dbc@npac.syr.edu Fri Feb 13 10:09 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA09530; Fri, 13 Feb 1998 10:09:20 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA01608; Fri, 13 Feb 1998 10:13:09 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802131513.KAA01608@weed.npac.syr.edu>
Subject: Re: pcrc_loc (fwd)
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Fri, 13 Feb 1998 10:13:08 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter),
        zgs@weed.npac.syr.edu (Guansong Zhang), lxm@[162.105.181.215]
In-Reply-To: <Pine.HPP.3.91.980213204415.8684A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Feb 13, 98 09:03:26 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2144
Status: RO


That sounds like a much better way of doing things (as I mentioned
before, the old method survived mainly for historical reasons---the
MPICH method didn't work on some platforFrom zheng.gb@bimp.pku.edu.cn Sun Feb 15 01:30 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id BAA29153 for <dbc@weed.npac.syr.edu>; Sun, 15 Feb 1998 01:30:51 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA11435; Sun, 15 Feb 1998 14:23:24 +0800
Date: Sun, 15 Feb 1998 14:23:23 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>
Subject: Re: pcrc_loc (fwd)
In-Reply-To: <199802130329.WAA01084@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980215113226.11357A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1181
Status: RO

On Thu, 12 Feb 1998, Bryan Carpenter wrote:

> 
> Sorry, that was wrong.  Try this
> 
> int pcrc_loc(int* rng, int* g_i) {
>   Range x = *((Range*) ad_ToPointer(*rng)) ;
>   int l_i ;
> 
>   const int glb = (*g_i - x.g_lb()) / x.g_stride() ;
>   x.ker_glb(glb, &l_i) ;
>   return l_i ;
> }
> 

Does pcrc_loc consider the ghostarea case?
for example:

REAL A(4,4)
!HPF$ PROCESSORS PROC(4)
!HPF$ DISTRIBUTE (*,BLOCK) ONTO PROC :: A
A(k,k)=1.0

if a's second dimension has ghostarea size 4
and if k=2
then 
on P(2)
pcrc_loc (pcrc_range (pcrc_dad_A,1),k)  return 1
pcrc_loc (pcrc_range (pcrc_dad_A,2),k)  return 0

so pcrc_loc do not consider ghostarea, right?

In my mind, I want to use this formular to caculate the local subscript:
on P(2)
local address of A(2,2) is: 
A(pcrc_loc(pcrc_range (pcrc_dad_A,1),2) * pcrc_stride(pcrc_range 
(pcrc_dad_A,1) + pcrc_loc (pcrc_range(pcrc_dad_A,2),2) * pcrc_stride 
(pcrc_range(pcrc_dad_A,2)) )

now this may be incorrect when ghostArea exists.

Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn




From zheng.gb@bimp.pku.edu.cn Mon Feb 16 09:31 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id JAA13334 for <dbc@npac.syr.edu>; Mon, 16 Feb 1998 09:31:33 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA19421; Mon, 16 Feb 1998 22:24:59 +0800
Date: Mon, 16 Feb 1998 22:24:59 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Subject: remap & write_halo
Message-Id: <Pine.HPP.3.91.980216214943.19336A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1574
Status: ROr


Hi, Bryan

 Today I tested remap and write_halo on ibmrs6000, to my surprise, I 
found that the remap is almost near to or faster than write_halo .
for example:

        program try

        PARAMETER (N=2000)
        integer a(N,N),b(N,N)
!HPF$  DISTRIBUTE (*,BLOCK) :: a,b

        call pcrc_clock(0)
        forall (i=1:N-1) a(1,i) = b(1,i+1)
        call pcrc_clock(1)

        end

(1 machine 4 processes)
SHIFT CASE:

ibmrs1(P0), Rtime: 0.370000, Utime: 0.040000, CUtime: 0.000000, Stime: 
0.0000000
ibmrs1(P3), Rtime: 0.440000, Utime: 0.060000, CUtime: 0.000000, Stime: 
0.0000000
ibmrs1(P2), Rtime: 0.300000, Utime: 0.070000, CUtime: 0.000000, Stime: 
0.0000000
ibmrs1(P1), Rtime: 0.440000, Utime: 0.060000, CUtime: 0.000000, Stime: 
0.0500000

REMAP CASE:

ibmrs1(P0), Rtime: 0.480000, Utime: 0.050000, CUtime: 0.000000, Stime: 
0.0100000
ibmrs1(P3), Rtime: 0.410000, Utime: 0.080000, CUtime: 0.000000, Stime: 
0.0000000
ibmrs1(P1), Rtime: 0.200000, Utime: 0.060000, CUtime: 0.000000, Stime: 
0.0100000
ibmrs1(P2), Rtime: 0.570000, Utime: 0.080000, CUtime: 0.000000, Stime: 
0.0000000

on Linux, the result was even worse. The write_halo is much slower than 
remap.
	
  What do you think how much write_halo should faster than remap? How 
much the memory movement will contribute to the time saving of write_halo?
And if we can do further optimization to write_halo?

Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Mon Feb 16 10:48 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA14672 for <dbc@postoffice.npac.syr.edu>; Mon, 16 Feb 1998 10:48:18 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA04343; Mon, 16 Feb 1998 10:52:09 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802161552.KAA04343@weed.npac.syr.edu>
Subject: Re: pcrc_loc (fwd)
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 16 Feb 1998 10:52:09 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter), lxm@[162.105.181.215]
In-Reply-To: <Pine.HPP.3.91.980215113226.11357A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Feb 15, 98 02:23:23 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2282
Status: RO


Hi Gengbin

`pcrc_loc' will return the local block subscript, ignoring ghost
regions.

In Adlib ghost areas are regarded as a property of memory layout, not
the basic shape/alignment of the array.  Memory layout is dealt
with by the `Stride' objects in the DAD.

If you want the actual displacement in the local array block
(incorporating the ghost offset) you have to pass the result
from `ker_glb' to

  u.disp(l_i)

where `u' is something like `dad.str(r)'---the stride object for
the relevant dimension.  In `pcrc.C' you'll see this computation in
`pcrc_coef'.

There's a good reason for this separation.  It means that you can use
the same local subscript values for arrays with different memory
layouts.  For example, in a distributed loop that combines elements of
aligned arrays with and without ghost regions, you can use the same
values for the local subscript for the various arrays.  Only the
simpler computation in `disp' needs to be different for the different
arrays.

Bryan

> 
> On Thu, 12 Feb 1998, Bryan Carpenter wrote:
> 
> > 
> > Sorry, that was wrong.  Try this
> > 
> > int pcrc_loc(int* rng, int* g_i) {
> >   Range x = *((Range*) ad_ToPointer(*rng)) ;
> >   int l_i ;
> > 
> >   const int glb = (*g_i - x.g_lb()) / x.g_stride() ;
> >   x.ker_glb(glb, &l_i) ;
> >   return l_i ;
> > }
> > 
> 
> Does pcrc_loc consider the ghostarea case?
> for example:
> 
> REAL A(4,4)
> !HPF$ PROCESSORS PROC(4)
> !HPF$ DISTRIBUTE (*,BLOCK) ONTO PROC :: A
> A(k,k)=1.0
> 
> if a's second dimension has ghostarea size 4
> and if k=2
> then 
> on P(2)
> pcrc_loc (pcrc_range (pcrc_dad_A,1),k)  return 1
> pcrc_loc (pcrc_range (pcrc_dad_A,2),k)  return 0
> 
> so pcrc_loc do not consider ghostarea, right?
> 
> In my mind, I want to use this formular to caculate the local subscript:
> on P(2)
> local address of A(2,2) is: 
> A(pcrc_loc(pcrc_range (pcrc_dad_A,1),2) * pcrc_stride(pcrc_range 
> (pcrc_dad_A,1) + pcrc_loc (pcrc_range(pcrc_dad_A,2),2) * pcrc_stride 
> (pcrc_range(pcrc_dad_A,2)) )
> 
> now this may be incorrect when ghostArea exists.
> 
> Gengbin
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 
> 


From zheng.gb@bimp.pku.edu.cn Fri Feb 13 23:26 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id XAA19949 for <dbc@npac.syr.edu>; Fri, 13 Feb 1998 23:26:26 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA10057; Sat, 14 Feb 1998 12:19:58 +0800
Date: Sat, 14 Feb 1998 12:19:58 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Subject: getarg
Message-Id: <Pine.HPP.3.91.980214095639.9849A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1683
Status: RO


Hi,

The fortran code is same as in my last letter, this time it is
farg.f.in , which will be processed by configure to generate farg.f .

      integer function pcrc_iargc()
@F90UNIX@
      pcrc_iargc = @F77IARGC@
      return
      end
c     
      subroutine pcrc_getarg( i, s )
@F90UNIX@
      integer       i
      character*80 s
      @F77GETARG@
      return
      end

in configure.in, set F77GETARG & F77IARGC default as 
F77GETARG="call getarg(i,s)"
F77IARGC="iargc()"
F90UNIX="C"

when the arch is hpux, the F77GETARG will be reset as 
F77GETARG="call igetarg(i,s,80)"
and if cray_3d, F77GETARG will be reset also.

you can find these in configure.2 in MPICH.

The only difference to the MPICH is that I found in fortran code :
pcrc_getarg(), the "charater *(*) s" seems not work, so I declare "s" as 
"character *80 s", made string "s" fixed length.


In pcrc.C, I added :

extern "C" {
  extern int pcrc_iargc();
  extern void pcrc_getarg(int *, char *);
}

static void getArgs(int &argidx, char *argv[])
{
    argidx = 0;
    char *q;
    int argcnt;
    
    argcnt = pcrc_iargc();
    while (argidx <= argcnt)
    {
        q = (char *)malloc(200);
        fflush(stdout);
        pcrc_getarg(&argidx, q);
        argv[argidx] = q;
        q = (char *)index(argv[argidx],' ');
        *q = '\0';
        ++argidx;
    }
}

static void _AdlibInit() {
  int argidx;
  char * argv[200];
  char **argvp = argv;

  getArgs(argidx, argv);

  AdlibInit(argidx, argvp) ;
}

 


Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Mon Feb 16 13:01 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id NAA16900; Mon, 16 Feb 1998 13:01:07 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id NAA04566; Mon, 16 Feb 1998 13:04:53 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802161804.NAA04566@weed.npac.syr.edu>
Subject: Re: remap & write_halo
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 16 Feb 1998 13:04:53 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter), lxm@[162.105.181.215],
        zgs@weed.npac.syr.edu (Guansong Zhang)
In-Reply-To: <Pine.HPP.3.91.980216214943.19336A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Feb 16, 98 10:24:59 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 5559
Status: RO


Hi Gengbin

Something is very wrong!  Timings ought to be on the order of milliseconds,
not seconds.

I'm not sure what code you are emitting for this example.  One obvious
``mistake'' would be to update the whole of the ghost region for `b',
width 2000, when in fact you only need the single word in the ghost
region of b(1, :).  If that happened, of course you would expect
performance worse than remap, which only moves the required data.
However I doubt whether it should be as bad as you are quoting, unless
your network bandwidth is truly awful.

Can you try the C++ example below and tell me what happens.
I've included two versions: the naive ad++ version (for reference)
and a more efficient Adlib version.  You should time the second
one.  `clock' is probably the wrong function to be using here,
but it will do to start with.

You should be able to compiler and run by

  ad++ test.C
  prun 4 a.out

Bryan

> 
> 
> Hi, Bryan
> 
>  Today I tested remap and write_halo on ibmrs6000, to my surprise, I 
> found that the remap is almost near to or faster than write_halo .
> for example:
> 
>         program try
> 
>         PARAMETER (N=2000)
>         integer a(N,N),b(N,N)
> !HPF$  DISTRIBUTE (*,BLOCK) :: a,b
> 
>         call pcrc_clock(0)
>         forall (i=1:N-1) a(1,i) = b(1,i+1)
>         call pcrc_clock(1)
> 
>         end
> 
> (1 machine 4 processes)
> SHIFT CASE:
> 
> ibmrs1(P0), Rtime: 0.370000, Utime: 0.040000, CUtime: 0.000000, Stime: 
> 0.0000000
> ibmrs1(P3), Rtime: 0.440000, Utime: 0.060000, CUtime: 0.000000, Stime: 
> 0.0000000
> ibmrs1(P2), Rtime: 0.300000, Utime: 0.070000, CUtime: 0.000000, Stime: 
> 0.0000000
> ibmrs1(P1), Rtime: 0.440000, Utime: 0.060000, CUtime: 0.000000, Stime: 
> 0.0500000
> 
> REMAP CASE:
> 
> ibmrs1(P0), Rtime: 0.480000, Utime: 0.050000, CUtime: 0.000000, Stime: 
> 0.0100000
> ibmrs1(P3), Rtime: 0.410000, Utime: 0.080000, CUtime: 0.000000, Stime: 
> 0.0000000
> ibmrs1(P1), Rtime: 0.200000, Utime: 0.060000, CUtime: 0.000000, Stime: 
> 0.0100000
> ibmrs1(P2), Rtime: 0.570000, Utime: 0.080000, CUtime: 0.000000, Stime: 
> 0.0000000
> 
> on Linux, the result was even worse. The write_halo is much slower than 
> remap.
> 	
>   What do you think how much write_halo should faster than remap? How 
> much the memory movement will contribute to the time saving of write_halo?
> And if we can do further optimization to write_halo?
> 
> Gengbin
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 

--------------------- naive ad++ -------------------------------------

#include "ad++.h"

const int N = 10 ;
const int NITER = 100 ;

int wlo [] = {0}, whi [] = {1} ;  // ghost widths for `writeHalo'

int main(int argc, char** argv) {
  AdlibInit(argc, argv) ;

  Procs1 p ;
  ON(p) {
    Range x(N) ;
    BlockRange y(N, p.dim(0), LAY_EXTENDED, 0, 1) ;

    Array2<int> a(x, y), b(x, y) ;

    Index i(x), j(y) ;
    OVERALL(i) {
      OVERALL(j) {
	a(i, j) = 0 ;
	b(i, j) = N * i + j ;
      } ALLOVER(j) ;
    } ALLOVER(i) ;

    gprintf("initial b:\n") ;
    aprintf("%7d%*N", b, N) ;

    Location i1(x, 0) ;
    Index j1(y.triplet(0, N - 2)) ;

    Section1<int> c(b.sect(i1, y)) ;

    writeHalo(c, wlo, whi) ;

    AT(i1) {
      OVERALL(j1) {
	a(i1, j1) = c(j1 >> 1) ;
      } ALLOVER(j1) ;
    } TA(i1) ;

    gprintf("final a:\n") ;
    aprintf("%7d%*N", a, N) ;

  } NO(p) ;

  AdlibFinalize() ;
}

-------------------- With loop optimizations ---------------------------

#include "ad++.h"
#include <sys/time.h>

const int N = 2000 ;
const int NITER = 1000 ;

int wlo [] = {0}, whi [] = {1} ;  // ghost widths for `writeHalo'

int main(int argc, char** argv) {
  AdlibInit(argc, argv) ;

  Procs1 p ;
  ON(p) {
    Range x(N) ;
    BlockRange y(N, p.dim(0), LAY_EXTENDED, 0, 1) ;

    Array2<int> a(x, y), b(x, y) ;

    Index i(x), j(y) ;
    OVERALL(i) {
      OVERALL(j) {
        a(i, j) = 0 ;
        b(i, j) = N * i + j ;
      } ALLOVER(j) ;
    } ALLOVER(i) ;

//    gprintf("initial b:\n") ;
//    aprintf("%7d%*N", b, N) ;

    clock() ;

    for(int iter = 0 ; iter < NITER ; iter++) {

      Location i1(x, 0) ;
      Index j1(y.triplet(0, N - 2)) ;

      Section1<int> c(b.sect(i1, y)) ;

      writeHalo(c, wlo, whi) ;

//      AT(i1) {
//        OVERALL(j1) {
//          a(i1, j1) = c(j1 >> 1) ;
//        } ALLOVER(j1) ;
//      } TA(i1) ;

      int* a_dat = a.dat() ;
      Stride a0 = a.str(0), a1 = a.str(1) ;

      int* c_dat = c.dat() ;
      Stride c0 = c.str(0) ;
      const int c0_len = c0.len() ;

      //apgStack.push(&apg) ;
      //apg.restrict(i1.dim) ;
      if(i1.dim.crd() == i1.crd) {
        const int a0_off = a0.offset(i1) ;

        //apgStack.push(&apg) ;
        //apg.restrict(j1.dim) ;
        for(j1.beginLocBlk() ; j1.test() ; j1.nextLocBlk()) {
          const int a1_bas = a1.offset(j1) ;
          const int a1_stp = a1.step(j1) ;

          const int c0_bas = c0.offset(j1) ;
          const int c0_stp = c0.step(j1) ;

          for(int jl = 0 ; jl < j1.count ; jl++) {

            a_dat [a0_off + a1_bas + a1_stp * jl] =
                     c_dat[c0_bas + c0_stp * jl + c0_len * 1] ;
          }
        }
        //apgStack.pop(&apg) ;
      }
      //apgStack.pop(&apg) ;
    }

    clock_t t = clock() ;
    gprintf("elapsed time = %f\n", (float) t / CLOCKS_PER_SEC) ;

//    gprintf("final a:\n") ;
//    aprintf("%7d%*N", a, N) ;

  } NO(p) ;

  AdlibFinalize() ;
}


From dbc@npac.syr.edu Mon Feb 16 13:04 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id NAA16959 for <dbc@postoffice.npac.syr.edu>; Mon, 16 Feb 1998 13:04:25 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id NAA04595; Mon, 16 Feb 1998 13:08:14 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802161808.NAA04595@weed.npac.syr.edu>
Subject: Re: remap & write_halo
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 16 Feb 1998 13:08:14 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980216214943.19336A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Feb 16, 98 10:24:59 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 130
Status: RO


PS 

I forgot you probably don't have the new function `triplet'.  Replace

  y.triplet(0, N - 2)

by

  y.subrng(N - 1, 0)

B.


From zheng.gb@bimp.pku.edu.cn Mon Feb 16 20:42 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id UAA25873 for <dbc@npac.syr.edu>; Mon, 16 Feb 1998 20:42:12 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA20784; Tue, 17 Feb 1998 09:35:31 +0800
Date: Tue, 17 Feb 1998 09:35:31 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>, lxm@arch.cs.pku.edu.cn,
        Guansong Zhang <zgs@weed.npac.syr.edu>
Subject: Re: remap & write_halo
In-Reply-To: <199802161804.NAA04566@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980217090702.20210A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2049
Status: ROr


hi,

The timing on the IBM RS6000 is:( run 3 times)
elapsed time = 1.240000
elapsed time = 1.630000
elapsed time = 1.950000

my equivenlent Fortran code:
shift:
ibmrs1(P3), Rtime: 22.830000, Utime: 1.370000, CUtime: 0.000000, Stime: 
4.300000
ibmrs1(P2), Rtime: 23.120000, Utime: 1.340000, CUtime: 0.000000, Stime: 
4.350000
ibmrs1(P1), Rtime: 23.170000, Utime: 1.160000, CUtime: 0.000000, Stime: 
4.530000
ibmrs1(P0), Rtime: 23.230000, Utime: 1.100000, CUtime: 0.000000, Stime: 
4.630000


remap:
ibmrs1(P3), Rtime: 9.290000, Utime: 2.210000, CUtime: 0.000000, Stime: 
0.0800000
ibmrs1(P2), Rtime: 10.990000, Utime: 2.120000, CUtime: 0.000000, Stime: 
0.740000
ibmrs1(P0), Rtime: 11.110000, Utime: 1.500000, CUtime: 0.000000, Stime: 
1.380000
ibmrs1(P1), Rtime: 11.110000, Utime: 2.190000, CUtime: 0.000000, Stime: 
0.690000

This time I paid attention to the system load, and the time should be 
more reliable.
it is very strange that remap had less time in Real time, but more time 
in User time.

this is the fortran code: (shift)
         call pcrc_coef (pcrc_dad_a,1,1,1,1,1,0,0,pcrc_u00,pcrc_v00)
         call pcrc_coef (pcrc_dad_a,2,1,1999,1,1,0,0,pcrc_u01,pcrc_v01)
         call pcrc_coef (pcrc_dad_b,1,1,1,1,1,0,0,pcrc_u10,pcrc_v10)
         call pcrc_coef (pcrc_dad_b,2,1,1999,1,1,1,1,pcrc_u11,pcrc_v11)
         pcrc_gtl_b(1) = 0
         pcrc_gtu_b(1) = 0
         pcrc_gtl_b(2) = 0
         pcrc_gtu_b(2) = 1
         call pcrc_write_halo (pcrc_dad_b,pcrc_gtl_b,pcrc_gtu_b)
         pcrc_sdx0 = pcrc_v00+pcrc_v01
         pcrc_sdx1 = pcrc_v10+pcrc_v11
         if (pcrc_on (pcrc_group (pcrc_sdd0))) then
             do  i=0,(pcrc_liu_i-pcrc_lil_i)/pcrc_lis_i,1
               a(pcrc_sdx0) = b(pcrc_sdx1)
               pcrc_sdx1 = pcrc_sdx1+pcrc_u11
               pcrc_sdx0 = pcrc_sdx0+pcrc_u01
            enddo
       endif


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From zheng.gb@bimp.pku.edu.cn Tue Feb 17 01:23 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id BAA28739 for <dbc@cairngorm.npac.syr.edu>; Tue, 17 Feb 1998 01:22:56 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA21678; Tue, 17 Feb 1998 14:16:13 +0800
Date: Tue, 17 Feb 1998 14:16:13 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Guansong Zhang <zgs@npac.syr.edu>
Cc: Bryan Carpenter <dbc@cairngorm.npac.syr.edu>
Subject: Re: remap & write_halo
In-Reply-To: <Pine.SGI.3.91.980216213819.380B-100000@cairngorm.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980217135500.21654A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2690
Status: RO

On Mon, 16 Feb 1998, Guansong Zhang wrote:

> 
> I did not follow this thread. But I do care about performance for the 
> moment. What does these data mean?
> 
> Guansong
> 
> On Tue, 17 Feb 1998, Zheng Gengbin wrote:
> 
> > 
> > hi,
> > 
> > The timing on the IBM RS6000 is:( run 3 times)
> > elapsed time = 1.240000
> > elapsed time = 1.630000
> > elapsed time = 1.950000
> > 


 this is the timing of the Ad++ code Bryan gave me. Here c function 
clock() only give user time(CPU time).


> > my equivenlent Fortran code:
> > shift:
> > ibmrs1(P3), Rtime: 22.830000, Utime: 1.370000, CUtime: 0.000000, Stime: 
> > 4.300000
> > ibmrs1(P2), Rtime: 23.120000, Utime: 1.340000, CUtime: 0.000000, Stime: 
> > 4.350000
> > ibmrs1(P1), Rtime: 23.170000, Utime: 1.160000, CUtime: 0.000000, Stime: 
> > 4.530000
> > ibmrs1(P0), Rtime: 23.230000, Utime: 1.100000, CUtime: 0.000000, Stime: 
> > 4.630000
> > 
> > 
> > remap:
> > ibmrs1(P3), Rtime: 9.290000, Utime: 2.210000, CUtime: 0.000000, Stime: 
> > 0.0800000
> > ibmrs1(P2), Rtime: 10.990000, Utime: 2.120000, CUtime: 0.000000, Stime: 
> > 0.740000
> > ibmrs1(P0), Rtime: 11.110000, Utime: 1.500000, CUtime: 0.000000, Stime: 
> > 1.380000
> > ibmrs1(P1), Rtime: 11.110000, Utime: 2.190000, CUtime: 0.000000, Stime: 
> > 0.690000
> > 
> > This time I paid attention to the system load, and the time should be 
> > more reliable.
> > it is very strange that remap had less time in Real time, but more time 
> > in User time.
> > 

Observed from these data, first, the user time of Fortran code is close to 
the time of ad++ code, that means the efficience of the fortran one. 
second, when I compared the remap and write_halo, I found the real time of 
remap is much less than the write_halo on the same condition, while the user 
time of remap is more than the write_halo's. You can find that some time 
is spent in Sysytem time when write_halo. Do you think this is reasonable?
In fact, I expect that both the real time and user time of write_halo are 
much less than those of remap.

The background is that I have done some node generation to perform
runtime communication detection for the UNKNOW communication during 
compiling time, and use the detection result to perform the real 
communication action in runtime. I almost succeed, but you know the time 
spent on the pcrc_detect_communication is quite a lot, I must understand 
how well write_halo compared to remap so  the time spent in 
communication detection during runtime is worthy.

Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Tue Feb 17 10:41 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA04089; Tue, 17 Feb 1998 10:41:46 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA05533; Tue, 17 Feb 1998 10:45:32 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199802171545.KAA05533@weed.npac.syr.edu>
Subject: Re: remap & write_halo
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Tue, 17 Feb 1998 10:45:31 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter),
        zgs@weed.npac.syr.edu (Guansong Zhang), lxm@[162.105.181.215]
In-Reply-To: <Pine.HPP.3.91.980217090702.20210A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Feb 17, 98 09:35:31 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 3784
Status: RO


Hi Gengbin.

First, the C code was for 1000 repeats of `writeHalo' and loop.
Can you confirm same for Fortran?  If so, then at least we are
talking milliseconds rather than seconds, and I'm much happier...

So far as the difference in performance of `remap' and `writeHalo' is
concerned, that doesn't sound so inexplicable to me.  User time may
well be larger for `remap' because it involves extra local copying
and it may well be more expensive to compute a general `remap' schedule
than to compute a `writeHalo' schedule---ie the procedure of computing
the lists of source and destination blocks may be more expensive
(it will depend very much on the details.)

On the other hand, it looks to me as if you are actually performing the
`writeHalo' for the whole of the `b' arrray, wheras presumably in the
`remap' case you just work on the section `b(1,:)'.  So the amount of
communication will be much larger for the writeHalo case.  So the
total run-time may be much larger because of 

In my ad++ example you'll notice I just did:

    int wlo [] = {0}, whi [] = {1} ;  // ghost widths for `writeHalo'

    ...

    Location i1(x, 0) ;
 
    Section1<int> c(b.sect(i1, y)) ;  // c ~= b (1, :)

    writeHalo(c, wlo, whi) ;

wherase I think you are doing something more like

    int wlo [] = {0, 0}, whi [] = {0, 1} ;  // ghost widths for `writeHalo'

    ...

    writeHalo(b, wlo, whi) ;

In your case you are moving 2000 words, where I'm moving 1 word.
It seems quite likely that this extra communication time will show
up in the ellapsed wallclock time but not the user CPU time.

Bryan



> 
> 
> hi,
> 
> The timing on the IBM RS6000 is:( run 3 times)
> elapsed time = 1.240000
> elapsed time = 1.630000
> elapsed time = 1.950000
> 
> my equivenlent Fortran code:
> shift:
> ibmrs1(P3), Rtime: 22.830000, Utime: 1.370000, CUtime: 0.000000, Stime: 
> 4.300000
> ibmrs1(P2), Rtime: 23.120000, Utime: 1.340000, CUtime: 0.000000, Stime: 
> 4.350000
> ibmrs1(P1), Rtime: 23.170000, Utime: 1.160000, CUtime: 0.000000, Stime: 
> 4.530000
> ibmrs1(P0), Rtime: 23.230000, Utime: 1.100000, CUtime: 0.000000, Stime: 
> 4.630000
> 
> 
> remap:
> ibmrs1(P3), Rtime: 9.290000, Utime: 2.210000, CUtime: 0.000000, Stime: 
> 0.0800000
> ibmrs1(P2), Rtime: 10.990000, Utime: 2.120000, CUtime: 0.000000, Stime: 
> 0.740000
> ibmrs1(P0), Rtime: 11.110000, Utime: 1.500000, CUtime: 0.000000, Stime: 
> 1.380000
> ibmrs1(P1), Rtime: 11.110000, Utime: 2.190000, CUtime: 0.000000, Stime: 
> 0.690000
> 
> This time I paid attention to the system load, and the time should be 
> more reliable.
> it is very strange that remap had less time in Real time, but more time 
> in User time.
> 
> this is the fortran code: (shift)
>          call pcrc_coef (pcrc_dad_a,1,1,1,1,1,0,0,pcrc_u00,pcrc_v00)
>          call pcrc_coef (pcrc_dad_a,2,1,1999,1,1,0,0,pcrc_u01,pcrc_v01)
>          call pcrc_coef (pcrc_dad_b,1,1,1,1,1,0,0,pcrc_u10,pcrc_v10)
>          call pcrc_coef (pcrc_dad_b,2,1,1999,1,1,1,1,pcrc_u11,pcrc_v11)
>          pcrc_gtl_b(1) = 0
>          pcrc_gtu_b(1) = 0
>          pcrc_gtl_b(2) = 0
>          pcrc_gtu_b(2) = 1
>          call pcrc_write_halo (pcrc_dad_b,pcrc_gtl_b,pcrc_gtu_b)
>          pcrc_sdx0 = pcrc_v00+pcrc_v01
>          pcrc_sdx1 = pcrc_v10+pcrc_v11
>          if (pcrc_on (pcrc_group (pcrc_sdd0))) then
>              do  i=0,(pcrc_liu_i-pcrc_lil_i)/pcrc_lis_i,1
>                a(pcrc_sdx0) = b(pcrc_sdx1)
>                pcrc_sdx1 = pcrc_sdx1+pcrc_u11
>                pcrc_sdx0 = pcrc_sdx0+pcrc_u01
>             enddo
>        endif
> 
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From zheng.gb@bimp.pku.edu.cn Wed Feb 18 10:05 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA21867 for <dbc@npac.syr.edu>; Wed, 18 Feb 1998 10:05:12 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA00742; Wed, 18 Feb 1998 22:58:20 +0800
Date: Wed, 18 Feb 1998 22:58:19 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>,
        Guansong Zhang <zgs@weed.npac.syr.edu>, lxm@arch.cs.pku.edu.cn
Subject: Re: remap & write_halo
In-Reply-To: <199802171545.KAA05533@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980218224919.738A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1216
Status: RO

> 
> In my ad++ example you'll notice I just did:
> 
>     int wlo [] = {0}, whi [] = {1} ;  // ghost widths for `writeHalo'
> 
>     ...
> 
>     Location i1(x, 0) ;
>  
>     Section1<int> c(b.sect(i1, y)) ;  // c ~= b (1, :)
> 
>     writeHalo(c, wlo, whi) ;
> 
> wherase I think you are doing something more like
> 
>     int wlo [] = {0, 0}, whi [] = {0, 1} ;  // ghost widths for `writeHalo'
> 
>     ...
> 
>     writeHalo(b, wlo, whi) ;
> 
> In your case you are moving 2000 words, where I'm moving 1 word.
> It seems quite likely that this extra communication time will show
> up in the ellapsed wallclock time but not the user CPU time.
> 


  Yes, I see.
  But in real application, if there are more than one write_halos 
corresponding to  same arrays in the rigth-hand-size of forall assignment, I 
have to combine write_halo's into one write_halo. That's why we use the 
whole array when the writehalo. 
  This means we must deal with the reduced dimension array specially to 
reduce communication.


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From zheng.gb@bimp.pku.edu.cn Mon Mar  2 20:32 EST 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id UAA05328; Mon, 2 Mar 1998 20:32:27 -0500 (EST)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA05492; Tue, 3 Mar 1998 09:25:14 +0800
Date: Tue, 3 Mar 1998 09:25:14 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Zhang Guansong <zgs@npac.syr.edu>
Subject: Shadow size
Message-Id: <Pine.HPP.3.91.980303092340.27094A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 366
Status: ROr


Hi, Bryan

 I wonder how I can get the shaow size of every dimension from a DAD in
runtime? 
 This will be used in communication detection function in runtime. 


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Fri Mar  6 22:41 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id WAA14897 for <dbc@postoffice.npac.syr.edu>; Fri, 6 Mar 1998 22:41:09 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id WAA24719; Fri, 6 Mar 1998 22:44:43 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199803070344.WAA24719@weed.npac.syr.edu>
Subject: Re: Shadow size
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Fri, 6 Mar 1998 22:44:42 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980303092340.27094A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Mar 3, 98 09:25:14 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1520
Status: RO


Usual apologies about slow response.

The short answer is that you can't, with the current interface.  It's
something that needs fixing.  It needs some extra inquiry members added to
the `Range' class.  The current `format' inquiry ought to be
accompanied by something like

class Range {
   ...
   Layout layout() const ; // one of LAY_STANDARD, LAY_PACKED, LAY_EXTENDED, ...
   
   int wlo() const ;       // lower ghost width
   int whi() const ;       // upper ghost width
   ...
}

I'll mend this in the next release.  If you're in a hurry maybe you can
add `wlo', `whi' yourself.  Just add corresponding virtual functions to the
`RangeRep' class, defined to return zero on the base class.  Overload
these to return the appropriate values on the `ExtendedBlockRangeRep'
and `ExtendedBlockSubRangeRep'.  Define the members of `Range' itself
in terms of the virtual functions on representation object, as for
other similar inquiries.

Perhaps these inquiries are more natural on the `Stride' objects rather
than the range objects, since those are supposed to carry the details
of the memory layout...

Bryan

> 
> 
> Hi, Bryan
> 
>  I wonder how I can get the shaow size of every dimension from a DAD in
> runtime? 
>  This will be used in communication detection function in runtime. 
> 
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From dbc@npac.syr.edu Mon Jan 26 18:09 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id SAA13594 for <dbc@postoffice.npac.syr.edu>; Mon, 26 Jan 1998 18:09:26 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id SAA04796; Mon, 26 Jan 1998 18:11:18 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801262311.SAA04796@weed.npac.syr.edu>
Subject: Re: your mail
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 26 Jan 1998 18:11:18 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980118112926.20073A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at Jan 18, 98 11:34:52 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1130
Status: RO


Sorry, not to reply sooner.  I somehow forgot your message.  Also
somehow the message got truncated.

You shouldn't need the conditional expression for `numProcs'.  Simply

  dad_src->rngs[d].dim().size()

should do, because `size' returns 1 on a null dimension.

Distribution code is given by the inquiry `Range :: format', which
will return

  DIST_BLOCK, DIST_CYCLIC, DIST_COLLAPSED

for your three cases.  You probably need to set up a little translation
table, because unfortunately they probably aren't 1, 2, 0.  They're currently
defined

enum Format {DIST_PRIMITIVE, DIST_COLLAPSED,
             DIST_BLOCK, DIST_CYCLIC, DIST_STEP} ;

so probably they're 2, 3, 1.  So you could just subtract 1, I suppose.

What else did you need to know?

Bryan

> 
> 
> I am writing a runtime function of detect_communication,
> I am not sure if I got the information on template correctly:
> 
>   pcrcfDAD *dad_src;
>   int d;
> 
>   //number of abstract processors in the dimension
>   dad_y.numProcs = dad_src->rngs[d].dim()?dad_src->rngs[d].dim().size() : 1;
> 
>   //distribution code (BLOCK=1, CYCLIC=2, *=0)
>   switch (dad_
> 


From zheng.gb@bimp.pku.edu.cn Wed May  6 11:24 EDT 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id LAA03463 for <dbc@npac.syr.edu>; Wed, 6 May 1998 11:24:18 -0400 (EDT)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA06333; Wed, 6 May 1998 23:16:19 +0800
Date: Wed, 6 May 1998 23:16:19 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Subject: group root
Message-Id: <Pine.HPP.3.91.980506231019.6303C-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 572
Status: ROr


Hi,

During some application, I think it is better to separate root processor as
I/O node from those computation nodes. This time  root node do not 
participate in the partitioning of the distributed array and computing.
Do you think it is easy to extend DAD , remap and other communication 
functions to support this? Or currently remap have already support this ?

Thanks

Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Wed May  6 11:48 EDT 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id LAA03837 for <dbc@npac.syr.edu>; Wed, 6 May 1998 11:48:56 -0400 (EDT)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id LAA12029; Wed, 6 May 1998 11:53:35 -0400
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199805061553.LAA12029@weed.npac.syr.edu>
Subject: Re: group root
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Wed, 6 May 1998 11:53:35 -0400 (EDT)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980506231019.6303C-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at May 6, 98 11:16:19 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1297
Status: RO


Hi Gengbin.

Good to hear from you.

The Adlib kernel supports this kind of thing.  There is the option
to specify a list of process ids in the `Procs' constructors.
This list can (for example) exclude the root processor.  Then any data
distributed over the created process arrays has no elements on the
root.  Of course you can use `on' constructs to restrict processing
of array elements to the relevant process groups.

You can still `remap' between arrays distributed over the worker
nodes and arrays collapsed on the root (for example).

You probably just need to make a few corresponding changes to the
processor arrangement constructor in the Fortran interface.

Bryan

> 
> 
> Hi,
> 
> During some application, I think it is better to separate root processor as
> I/O node from those computation nodes. This time  root node do not 
> participate in the partitioning of the distributed array and computing.
> Do you think it is easy to extend DAD , remap and other communication 
> functions to support this? Or currently remap have already support this ?
> 
> Thanks
> 
> Gengbin
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From zheng.gb@bimp.pku.edu.cn Sun May 10 11:32 EDT 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id LAA25350 for <dbc@npac.syr.edu>; Sun, 10 May 1998 11:32:46 -0400 (EDT)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA29668; Sun, 10 May 1998 23:24:38 +0800
Date: Sun, 10 May 1998 23:24:38 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>
Subject: Re: group root
In-Reply-To: <199805061553.LAA12029@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980510224248.29395A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1631
Status: RO

On Wed, 6 May 1998, Bryan Carpenter wrote:

> 
> Hi Gengbin.
> 
> Good to hear from you.
> 
> The Adlib kernel supports this kind of thing.  There is the option
> to specify a list of process ids in the `Procs' constructors.
> This list can (for example) exclude the root processor.  Then any data
> distributed over the created process arrays has no elements on the
> root.  Of course you can use `on' constructs to restrict processing
> of array elements to the relevant process groups.
> 
> You can still `remap' between arrays distributed over the worker
> nodes and arrays collapsed on the root (for example).
> 
> You probably just need to make a few corresponding changes to the
> processor arrangement constructor in the Fortran interface.
> 

I have tried several programs to test remap between working node and root 
node. What I found is that if the array in one dimesion ,it is ok, But 
if the array is more than one rank, remap failed.

I tried this program :

        program try
        integer a(10,10)
!HPF$   processors P(1,4)
!HPF$   distribute a(block,block) onto P(1,2:4)

        a=1
        print *,a
        end

Here, 'print *,a' while remap the whole 'a' to root processor, which 
causes such errors:
0 - Could not complete recv in MPI_WAITANY : Message truncated
[0]  Aborting program !
[0] Aborting program!
Process 1: sub_id:1 2 3 
p0_25153:  p4_error: : 14
bm_list_25154:  p4_error: interrupt SIGINT: 2


Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Mon May 11 10:27 EDT 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA06915 for <dbc@npac.syr.edu>; Mon, 11 May 1998 10:27:53 -0400 (EDT)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA16541; Mon, 11 May 1998 10:32:29 -0400
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199805111432.KAA16541@weed.npac.syr.edu>
Subject: Re: group root
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 11 May 1998 10:32:28 -0400 (EDT)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980510224248.29395A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at May 10, 98 11:24:38 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1382
Status: RO


How are you translating that?

What Adlib allows is equivalent to...

  int [] p_targ_processors = {1, 2, 3} ;  // processors other than root, 0.

  int [] p_shape = {1, 3} ;
  Procs p(2, p_shape, p_targ_processors) ;
    // 2d grid `p' distributed over processors in `p_targ_processors'

then declare `a' distributed over `p'.  You should then be able to
remap `a' to a temporary created on the root in the usual way.

Bryan

> 
> I have tried several programs to test remap between working node and root 
> node. What I found is that if the array in one dimesion ,it is ok, But 
> if the array is more than one rank, remap failed.
> 
> I tried this program :
> 
>         program try
>         integer a(10,10)
> !HPF$   processors P(1,4)
> !HPF$   distribute a(block,block) onto P(1,2:4)
> 
>         a=1
>         print *,a
>         end
> 
> Here, 'print *,a' while remap the whole 'a' to root processor, which 
> causes such errors:
> 0 - Could not complete recv in MPI_WAITANY : Message truncated
> [0]  Aborting program !
> [0] Aborting program!
> Process 1: sub_id:1 2 3 
> p0_25153:  p4_error: : 14
> bm_list_25154:  p4_error: interrupt SIGINT: 2
> 
> 
> Gengbin
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From zheng.gb@bimp.pku.edu.cn Mon May 11 11:14 EDT 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id LAA07691 for <dbc@npac.syr.edu>; Mon, 11 May 1998 11:14:48 -0400 (EDT)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA06244; Mon, 11 May 1998 23:06:42 +0800
Date: Mon, 11 May 1998 23:06:42 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>
Subject: Re: group root
In-Reply-To: <199805111432.KAA16541@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980511223620.5859A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1599
Status: ROr

On Mon, 11 May 1998, Bryan Carpenter wrote:

> 
> How are you translating that?
> 
> What Adlib allows is equivalent to...
> 
>   int [] p_targ_processors = {1, 2, 3} ;  // processors other than root, 0.
> 
>   int [] p_shape = {1, 3} ;
>   Procs p(2, p_shape, p_targ_processors) ;
>     // 2d grid `p' distributed over processors in `p_targ_processors'
> 
> then declare `a' distributed over `p'.  You should then be able to
> remap `a' to a temporary created on the root in the usual way.
> 

Yes, I think I have correctly translated , the Fortran node program is:

! CREAT subgroup, new runtime function pcrc_sub_group_grid
      pcrc_l0(1) = 1
      pcrc_u0(1) = 1
      pcrc_s0(1) = 1
      pcrc_l0(2) = 2
      pcrc_u0(2) = 4
      pcrc_s0(2) = 1
      pcrc_subgrp_TMP000 = pcrc_sub_group_grid (2,pcrc_l0,pcrc_u0,pcrc_s&
     &0,pcrc_grp_P)

! CREAT template which distribute on the sub_group
      pcrc_rng_TMP000(1) = pcrc_new_range_distribute (1,10,pcrc_block,pc&
     &rc_subgrp_TMP000,1)
      pcrc_rng_TMP000(2) = pcrc_new_range_distribute (1,10,pcrc_block,pc&
     &rc_subgrp_TMP000,2)

! CREAT dad of 'a'
      pcrc_dad_a = pcrc_new_array_data (a,pcrc_integer,pcrc_size_integer&
     &,2,pcrc_grp_P,COLUMN_MAJOR)
      call pcrc_set_array_align (pcrc_dad_a,1,1,10,1,0,0,0,pcrc_rng_TMP0&
     &00(1))
      call pcrc_set_array_align (pcrc_dad_a,2,1,10,1,0,0,0,pcrc_rng_TMP0&
     &00(2))


Gengbin
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Mon May 11 12:27 EDT 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id MAA09089 for <dbc@npac.syr.edu>; Mon, 11 May 1998 12:27:20 -0400 (EDT)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id MAA16704; Mon, 11 May 1998 12:32:05 -0400
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199805111632.MAA16704@weed.npac.syr.edu>
Subject: Re: group root
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Mon, 11 May 1998 12:32:05 -0400 (EDT)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980511223620.5859A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at May 11, 98 11:06:42 pm
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1871
Status: RO


OK, but how is `pcrc_sub_group_grid' defined?

I'm a bit confused because Adlib doesn't have any idea of forming a
subgroup with interval subscripts.

Bryan

> 
> On Mon, 11 May 1998, Bryan Carpenter wrote:
> 
> > 
> > How are you translating that?
> > 
> > What Adlib allows is equivalent to...
> > 
> >   int [] p_targ_processors = {1, 2, 3} ;  // processors other than root, 0.
> > 
> >   int [] p_shape = {1, 3} ;
> >   Procs p(2, p_shape, p_targ_processors) ;
> >     // 2d grid `p' distributed over processors in `p_targ_processors'
> > 
> > then declare `a' distributed over `p'.  You should then be able to
> > remap `a' to a temporary created on the root in the usual way.
> > 
> 
> Yes, I think I have correctly translated , the Fortran node program is:
> 
> ! CREAT subgroup, new runtime function pcrc_sub_group_grid
>       pcrc_l0(1) = 1
>       pcrc_u0(1) = 1
>       pcrc_s0(1) = 1
>       pcrc_l0(2) = 2
>       pcrc_u0(2) = 4
>       pcrc_s0(2) = 1
>       pcrc_subgrp_TMP000 = pcrc_sub_group_grid (2,pcrc_l0,pcrc_u0,pcrc_s&
>      &0,pcrc_grp_P)
> 
> ! CREAT template which distribute on the sub_group
>       pcrc_rng_TMP000(1) = pcrc_new_range_distribute (1,10,pcrc_block,pc&
>      &rc_subgrp_TMP000,1)
>       pcrc_rng_TMP000(2) = pcrc_new_range_distribute (1,10,pcrc_block,pc&
>      &rc_subgrp_TMP000,2)
> 
> ! CREAT dad of 'a'
>       pcrc_dad_a = pcrc_new_array_data (a,pcrc_integer,pcrc_size_integer&
>      &,2,pcrc_grp_P,COLUMN_MAJOR)
>       call pcrc_set_array_align (pcrc_dad_a,1,1,10,1,0,0,0,pcrc_rng_TMP0&
>      &00(1))
>       call pcrc_set_array_align (pcrc_dad_a,2,1,10,1,0,0,0,pcrc_rng_TMP0&
>      &00(2))
> 
> 
> Gengbin
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


From zheng.gb@bimp.pku.edu.cn Mon May 11 21:41 EDT 1998
Received: from svr.bimp.pku.edu.cn (svr.bimp.pku.edu.cn [162.105.174.2]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id VAA16626 for <dbc@weed.npac.syr.edu>; Mon, 11 May 1998 21:41:28 -0400 (EDT)
Received: by svr.bimp.pku.edu.cn
	(1.38.193.4/16.2) id AA08080; Tue, 12 May 1998 09:33:01 +0800
Date: Tue, 12 May 1998 09:33:01 +0800 (EAT)
From: Zheng Gengbin <zheng.gb@bimp.pku.edu.cn>
To: Bryan Carpenter <dbc@npac.syr.edu>
Cc: Bryan Carpenter <dbc@weed.npac.syr.edu>
Subject: Re: group root
In-Reply-To: <199805111632.MAA16704@weed.npac.syr.edu>
Message-Id: <Pine.HPP.3.91.980512090101.7263A-100000@svr.bimp.pku.edu.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1776
Status: ROr

On Mon, 11 May 1998, Bryan Carpenter wrote:

> 
> OK, but how is `pcrc_sub_group_grid' defined?
> 
> I'm a bit confused because Adlib doesn't have any idea of forming a
> subgroup with interval subscripts.
> 

Now the program runs ok. I make a mistake in node program, when creating
dad_a, I use the whole group 'P' instead of using subgroup.

the subgroup function is defined as (in pcrcFortran) :
int pcrc_sub_group_grid(int* rank, int* l, int* u, int* s, int* grp_grid);

The strides are needed because the 'extended-dist-target' defined in HPF 2.0
is 
	processor-name[( section-subscript-list )]
The section-subscripts is defined as : l:u:s.
So , in general case we have to consider interval subscripts.

To implement this function, we first calculate the sub_ids from the [l,u,s]
and the shape of the parent grp_grid, then construct Procs with rank, shape
and sub_ids.


I have an idea to overlap communication with computation , suppose we have 8 
nodes, P0(I/O node) will remap the collapsed data to P1-P7.
Then the time sequence is P0=>P1=>P2 ... =>P7.
So after some time of calculation , the data on P1-P7 will remap to P0,
time sequence is :
P7=>P6=>P5=> ... =>P1=>P0
, if we can reverse this time sequence as:
P1=>P2=>P3=> ... =>P7=>P0
, then we can overlap the computation with the communication. Since the P1
will first get its portion of data and start computing , P2 next ... ,
P1 is first ready to send its data to P0. In the old sequence, P1 must 
wait for P7 to finish.

Do you think this is easy to support in Adlib? Or simply by re-Span the proc
tree?


Gengbin Zheng
---------------------------------
Dept. of Computer Science and Technology
Peking University

home page: http://pact0.cs.pku.edu.cn/users/zhenggb
E-mail:    zheng.gb@svr.bimp.pku.edu.cn



From dbc@npac.syr.edu Tue May 12 10:50 EDT 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id KAA22748 for <dbc@npac.syr.edu>; Tue, 12 May 1998 10:50:01 -0400 (EDT)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id KAA17505; Tue, 12 May 1998 10:53:34 -0400
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199805121453.KAA17505@weed.npac.syr.edu>
Subject: Re: group root
To: zheng.gb@bimp.pku.edu.cn (Zheng Gengbin)
Date: Tue, 12 May 1998 10:53:33 -0400 (EDT)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
In-Reply-To: <Pine.HPP.3.91.980512090101.7263A-100000@svr.bimp.pku.edu.cn> from "Zheng Gengbin" at May 12, 98 09:33:01 am
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2500
Status: RO

> 
> [...]
> 
> the subgroup function is defined as (in pcrcFortran) :
> int pcrc_sub_group_grid(int* rank, int* l, int* u, int* s, int* grp_grid);
> 
> The strides are needed because the 'extended-dist-target' defined in HPF 2.0
> is 
> 	processor-name[( section-subscript-list )]
> The section-subscripts is defined as : l:u:s.
> So , in general case we have to consider interval subscripts.
> 
> To implement this function, we first calculate the sub_ids from the [l,u,s]
> and the shape of the parent grp_grid, then construct Procs with rank, shape
> and sub_ids.
> 

OK.  That should work.

> 
> I have an idea to overlap communication with computation , suppose we have 8 
> nodes, P0(I/O node) will remap the collapsed data to P1-P7.
> Then the time sequence is P0=>P1=>P2 ... =>P7.
> So after some time of calculation , the data on P1-P7 will remap to P0,
> time sequence is :
> P7=>P6=>P5=> ... =>P1=>P0
> , if we can reverse this time sequence as:
> P1=>P2=>P3=> ... =>P7=>P0
> , then we can overlap the computation with the communication. Since the P1
> will first get its portion of data and start computing , P2 next ... ,
> P1 is first ready to send its data to P0. In the old sequence, P1 must 
> wait for P7 to finish.
> 
> Do you think this is easy to support in Adlib? Or simply by re-Span the proc
> tree?
> 

The current version of Remap (and BlockMessSchedule's in
general) sends messages in hop order directly to their destination...

   P0 -> P1     (hop = 1)
   P0 -> P2     (hop = 2)
   P0 -> P3     (hop = 3)
   ...
   P0 -> P7     (hop = 7)

Because `hop' is defined with cyclic wraparound, on the reverse trip
the ordering should be

   P7 -> P0     (hop = 1)
   P6 -> P0     (hop = 2)
   P5 -> P0     (hop = 3)
   ...
   P1 -> P0     (hop = 7)

At the moment this ordering is supposed to be invisible to the
programmer.  Messages have to be sorted as part of construction of the
communication schedule, to avoid deadlock (and, potentially at least,
to improve efficiency).  I suppose making the message order part of the
spec might give dedicated users the opportunity to achieve more
overlapping in their code, but I'd be worried that it would remove
opportunities to optimize the schedules internally (without changing
that external spec).

That said, it should be easy enough to change the `gather' member of
`BlockMessSchedule' to allow the option of sending messages in reversed
hop order.  But I'm not sure what would be a good interface at the user
level.

Bryan


From dbc@npac.syr.edu Wed Jan 14 13:36 EST 1998
Received: from weed.npac.syr.edu (weed.npac.syr.edu [128.230.117.30]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with SMTP id NAA20688 for <dbc@postoffice.npac.syr.edu>; Wed, 14 Jan 1998 13:36:11 -0500 (EST)
Received: (from dbc@localhost) by weed.npac.syr.edu (940816.SGI.8.6.9/8.6.6) id NAA29190; Wed, 14 Jan 1998 13:38:58 -0500
From: Bryan Carpenter <dbc@npac.syr.edu>
Message-Id: <199801141838.NAA29190@weed.npac.syr.edu>
Subject: Re: your mail (fwd)
To: zheng.gb@bimp.pku.edu.cn
Date: Wed, 14 Jan 1998 13:38:58 -0500 (EST)
Cc: dbc@weed.npac.syr.edu (Bryan Carpenter)
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 694
Status: RO


Unfortunately the pcrcFortran interface in the version on the Web
doesn't work, because of some name-shifts to the kernel classes.  I'll
make a new version with a fixed Fortran interface available ASAP.

Bryan

----- Forwarded message from Bryan Carpenter -----


It's now available at

http://www.npac.syr.edu/projects/pcrc/adlib.html

Bryan

> 
> Hi,
> 
>  How can I get your latest version of Adlib ?
> 
> 
> Gengbin Zheng
> ---------------------------------
> Dept. of Computer Science and Technology
> Peking University
> 
> home page: http://pact0.cs.pku.edu.cn/users/zhenggb
> E-mail:    zheng.gb@svr.bimp.pku.edu.cn
> 
> 
> 


----- End of forwarded message from Bryan Carpenter -----

