How to build a fortram array descriptor for ifort ?

[WeiLiPenguin]

I notice there is extension/opencoarrys.f90

 ! Proposed Fortran 2015 co_sum parallel collective sum reduction
  subroutine co_sum_integer(a,result_image,stat,errmsg)
    integer(c_int), intent(inout), volatile, target :: a(*)
    integer(c_int), intent(in), optional :: result_image
    integer(c_int), intent(out), optional:: stat 
    character(kind=c_char,len=*), intent(out), optional :: errmsg

    !gfc_descriptor struct array5_integer(kind=4) parm.7;
    type(gfc_descriptor_t) :: a_descriptor

    error stop "Build a_descriptor"

     ! C example:
     !parm_7%dtype = 269;
     !parm_7%dim(0).lbound = 1;
     !parm_7%dim(0).ubound = 1;
     !parm_7%dim(0).stride = 1;
     !parm_7%dim(1).lbound = 1;
     !parm_7%dim(1).ubound = 1;
     !parm_7%dim(1).stride = 1;
     !...
     !parm_7%data = (void *) &a[0];
     !parm_7%offset = -9;

and src/libcaf-gfortran-descriptor.h

typedef struct descriptor_dimension
{
  ptrdiff_t _stride;
  ptrdiff_t lower_bound;
  ptrdiff_t _ubound;
}
descriptor_dimension;

typedef struct gfc_descriptor_t {
  void *base_addr;
  size_t offset;
  ptrdiff_t dtype;
  descriptor_dimension dim[];
} gfc_descriptor_t;

form Intel the ifort array descriptor and with this old un-update Intel Fortran array descriptor (Taken from Chasm), which seem not right as this link

/*
 * Intel Fortran array descriptor
 * (Taken from Chasm) by mcxx
 */
#if 0
typedef struct dope_vec_Intel_ {
  char*   base_addr;          /* base address of the array      */
  long    elem_size;          /* size of a single element           */
  long    offset;         /* base_addr + offset is array start  */
  unsigned int    assoc     :  1; /* 1 = has been associated        */
  unsigned int    ptr_alloc :  1; /* 1 = has been allocated     */
  unsigned int    p_or_a    :  2; /* 1 = pointer, 2 = allocatable   */
  unsigned int    non_contig:  1; /* 0 = is contiguous          */
  unsigned int    reserved_1: 11;
  unsigned int    reserved_2: 16;
#ifdef CHASM_ARCH_64
  unsigned int    reserved64: 16;
#endif
  long rank;                      /* number of dimensions       */
  long reserved_3;
  struct {
    long extent;       /* number of elements for a given dimension  */
    long stride_mult;  /* distance between successive elements (bytes)  */
    long lower_bound;  /* first array index for a given dimension   */
  } dim[7];
} dope_vec_Intel;
#endif

Is it enough information to build a ifort array descriptor for opencoarrays?

It is too difficult to me, because my zero knowledge about C.

I like both opencoarrays and ifort too much!

[sourceryinstitute]

Thanks for your interest in this module. Your question about compiling with ifort is precisely what inspired this module so I’m glad the module is of interest to you. Alessandro and I will be talking on Tuesday and will work on building the descriptor then if neither of us does it before then.

Damian

P.S. I have been struggling with how to address you. Would you prefer Wei Li, Li Wei, or just Wei or Li?

On Jun 6, 2015, at 10:15 AM, WeiLi notifications@github.com wrote:

I notice there is extension/opencoarrys.f90 https://github.com/sourceryinstitute/opencoarrays/blob/master/src/extensions/opencoarrays.f90 ! Proposed Fortran 2015 co_sum parallel collective sum reduction subroutine co_sum_integer(a,result_image,stat,errmsg) integer(cint), intent(inout), volatile, target :: a() integer(c_int), intent(in), optional :: result_image integer(c_int), intent(out), optional:: stat character(kind=cchar,len=), intent(out), optional :: errmsg

!gfc_descriptor struct array5_integer(kind=4) parm.7;
type(gfc_descriptor_t) :: a_descriptor

error stop "Build a_descriptor"

 ! C example:
 !parm_7%dtype = 269;
 !parm_7%dim(0).lbound = 1;
 !parm_7%dim(0).ubound = 1;
 !parm_7%dim(0).stride = 1;
 !parm_7%dim(1).lbound = 1;
 !parm_7%dim(1).ubound = 1;
 !parm_7%dim(1).stride = 1;
 !...
 !parm_7%data = (void *) &a[0];
 !parm_7%offset = -9;

and src/libcaf-gfortran-descriptor.h https://github.com/sourceryinstitute/opencoarrays/blob/master/src/libcaf-gfortran-descriptor.h typedef struct descriptor_dimension { ptrdiff_t _stride; ptrdiff_t lower_bound; ptrdiff_t _ubound; } descriptor_dimension;

typedef struct gfc_descriptor_t { void _base_addr; size_t offset; ptrdiff_t dtype; descriptor_dimension dim[]; } gfc_descriptort; form Intel the ifort array descriptor https://software.intel.com/en-us/node/510871 and with this old un-update Intel Fortran array descriptor (Taken from Chasm), which seem not right as this link https://software.intel.com/en-us/node/510871 /

• Intel Fortran array descriptor
• (Taken from Chasm) _/

  if 0

  typedef struct dope_vecIntel { char_ baseaddr; /* base address of the array / long elemsize; / size of a single element / long offset; / baseaddr + offset is array start / unsigned int assoc : 1; / 1 = has been associated / unsigned int ptralloc : 1; / 1 = has been allocated _/ unsigned int p_ora : 2; / 1 = pointer, 2 = allocatable _/ unsigned int noncontig: 1; / 0 = is contiguous _/ unsigned int reserved_1: 11; unsigned int reserved_2: 16;

  ifdef CHASM_ARCH_64

  unsigned int reserved64: 16;

  endif

  long rank; / number of dimensions / long reserved3; struct { long extent; / number of elements for a given dimension _/ long stridemult; / distance between successive elements (bytes) _/ long lowerbound; / first array index for a given dimension */ } dim[7]; } dope_vec_Intel;

  endif

  Is it enough information to build a ifort array descriptor for opencoarrays?

It is too difficult to me, because my zero knowledge about C.

I like both opencoarrays and ifort too much!

— Reply to this email directly or view it on GitHub https://github.com/sourceryinstitute/opencoarrays/issues/4.

[WeiLiPenguin]

Hi, Damian

I name is Wei Li, Li is the last name. Nice to meet you!

Wei

:)

[sourceryinstitute]

Hi Wei Li,

We are now able to build the required descriptors. We do so in the current version of src/extensions/opencoarrays.F90 in the repository. Before proceeding, I just sent a related email to the OpenCoarrays Google Group mailing list to solicit feedback on whether it seems like a sufficiently compelling idea to invest further time in this. I like the idea but have some reservations about the expected performance as explained in the email. Hopefully you subscribe to that mailing list. Please let us know your feedback via the mailing list.

Damian

[sourceryinstitute]

Hi Wei,

Just to update you, we now build the descriptors correctly at least for integer scalars. We are working on building them correctly for other cases and hope to have it working soon.

Damian

[WeiLiPenguin]

Hi Damian

Learn a lot from your extension code. I found in my case, I only need the co_sum, and co_broadcast to instead of mpi calls. For now, I just write a very simple module contains the smallest functions to keep the interface same with gcc5.1 for these co_sum and co_broadcast I uesed. now I could make my program ugly support both gcc5.1+opencoarrays and ifort+mpi without changing too much code. I am still interesting about the "array descriptor" with ifort.
(For now seems Cray still not update their gcc environment to support 5.1 version.)

Thanks for everything you made!

Wei

[sourceryinstitute]

Hi Wei,

If you could provide some details on your application and the subset of coarray Fortran (CAF) features it employs, that would be really useful to us. Given that you are using the extensions, I’m wondering if that means that the CAF intrinsics (e.g., this_image() and num_images()), image control statements (e.g., sync images, sync all, error stop), and collectives (co_sum and co_broadcast) are sufficient to cover your algorithmic needs. If so, yours would be the third use case we’ve encountered where the aforementioned capabilities suffice and we’re collecting use cases to mention in a paper about the extensions.

What we don’t current provide in the extensions are support for square bracket CAF notation. I’m wondering whether you either don’t need the square brackets in you application because the above features are sufficient or alternatively whether you’re using Intel’s CAF support to handle the square brackets and simply using OpenCoarrays to extend Intel’s capabilities by providing collectives.

Lastly, I’m wondering if it would be of interest to you for us to expose “put” and “get” procedures in the extensions for use in the scenarios where one might otherwise use square brackets. We’re considering it. One nice thing is that our “put” and “get” would wrap MPI 3.0 one-sided communication, which for some applications on some platforms, will outperform the two-sided MPI communication that most application developers currently write. And our wrappers hide a lot of the complexiitites of using the one-sided communication so they lead to much simpler code than if a user were to embed the MPI one-sided communication calls directly in the source.

If you prefer to share the above information offline, feel free to email me at damian@sourceryinstitute.org or we can set up a time to talk via Skype.

Damian

[rouson]

Hi Wei,

I just added provisional support for co_broacast of character(kind=c_char) scalar variables via the opencoarrays module accessible with "use opencoarrays". For your purposes, is it sufficient to be able to broadcast scalar character variables? If you need character arrays, let me know.

You can access this capability by cloning my fork of OpenCoarrays:

git clone https://github.com/rouson/opencoarrays

Because the compiler does not yet support this feature directly, I had to use an approach that adds some additional runtime overhead (including the creation of a temporary extra copy of the data) as compared to broadcasting non-character data, but I doubt this overhead will be significant as compared the communication costs.

I have also created a pull request on the main sourceryinstitute/opencoarrays site, which I will ask Alessandro to review before we merge it into the master branch.

If you have a chance to try this feature out, please let us know how it goes. If it works, then I presume OpenCoarrays will be covering all of your CAF needs and you won't be using any of the native Intel CAF support. Thanks for submitting a very interesting use case to us! It has inspired a lot of thinking on our part regarding broader possibilities for OpenCoarrays than we originally envisioned.

Damian

[rouson]

@zbeekman. I received an email saying this was closed on July 21. Then I just received saying it was assigned to me. This thread started with a report of a problem with co_sum. I'm not aware of any problems with co_sum currently. Is there something new?

[zbeekman]

sorry, no, I just wanted to "assign" closed issues to you and Alessandro, if it looks like you were the ones who took the lead solving them... I hope I'm not adding to the confusion; I just thought it could help us stay organized.

On Sun, Dec 13, 2015 at 2:00 PM Damian Rouson notifications@github.com wrote:

@zbeekman https://github.com/zbeekman. I received an email saying this was closed on July 21. Then I just received saying it was assigned to me. This thread started with a report of a problem with co_sum. I'm not aware of any problems with co_sum currently. Is there something new?

— Reply to this email directly or view it on GitHub https://github.com/sourceryinstitute/opencoarrays/issues/4#issuecomment-164287867 .

[rouson]

No problem. I j just saw your explanation on another issue. Thanks for your help!