April 2016 - discuss - mailman3.cels.anl.gov

Thank you for your help
by Dmitriy Lyubimov 19 Apr '16

19 Apr '16

Hello, I am new to MPI. I have a couple of questions I hope someone could help me with -- i tried to scan archives but have not immediately found the answers. (1) I know there is a multicast based implementation for infiniband in a derivative MVAPICH peojwxr from Ohio state that apparently allows to avoid packet duplication for multiple addressees when implementing broadcasts and scatters, in a reliable communication manner even for larger messages (as large as perhaps 16...200Mb) Is there any similar technique used in MPICH for broadcasts and gathers? Would there be any networking benefit in using MPICH as opposed to carefully organized point-to-point broadcast scheme such as perhaps chained peer-to-peer or butterfly mixing? (2) Another question is possibility of integration of the worker processes with another resource manager (other than Hydra, i guess) -- perhaps yarn or mesos. Can i bring the worker process first somehow and then enroll it into a communicator, assuming at certain point i know all process locations in the network? In other words, can i replace whatever mpirun or mpiexec does, with a custom code that would enroll all workers into the communicators and assigns the ranks? (3) network multinenancy: can i set up several world communicators on the same network independently at different point of times? or it has to be only one world communicator at a time? Thank you very much for your help. -Dmitriy _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Is it allowed to attach automatic array for remote access with MPI_Win_attach?
by Jeff Hammond 19 Apr '16

19 Apr '16

When you use dynamic windows, you must use the virtual address of the remote memory as the offset, That means you must attach a buffer and then get the address with MPI_GET_ADDRESS. Then you must share that address with any processes that target that memory, perhaps using MPI_SEND/MPI_RECV or MPI_ALLGATHER of an address-sized integer (MPI_AINT is the MPI type corresponding to the MPI_Aint C type). It appears you are not doing this. This issue should affect you whether you use automatic arrays or heap data... It does not appear to be a problem here, but if you use automatic arrays with RMA, you must guarentee that they remain in scope throughout the duration of when they will be accessed remotely. I think you are doing this sufficiently with a barrier. However, at the point at which you are calling barrier to ensure they stay in scope, you lose all of the benefits of fine-grain synchronization from PSCW. You might as well just use MPI_Win_fence. There is a sentence in the MPI spec that says that, strictly speaking, using memory not allocated by MPI_Alloc_mem (or MPI_Win_allocate(_shared), of course) in RMA is not portable, but I don't know any implementation that actually behaves this way. MPICH has an active-message implementation of RMA, which does not care what storage class is involved, up to performance differences (interprocess shared memory is faster in some cases). This is a fairly complicated topic and it is possible that I have been a bit crude in summarizing the MPI standard, so I apologize to any MPI Forum experts who can find fault in what I've written :-) Jeff On Tue, Apr 19, 2016 at 5:51 AM, Maciej Szpindler <m.szpindler(a)icm.edu.pl> wrote: > This is simplified version of my routine. It may look odd but I am > trying to migrate from send/recv scheme to one sided pscw and that > is the reason for buffers etc. As long as dynamic windows are not used, > it works fine (I believe). When I switch to dynamic windows it fails > with segmentation fault. I would appreciate any comment and suggestion > how to improve this. > > SUBROUTINE swap_simple_rma(field, row_length, rows, levels, halo_size) > > USE mpi > > IMPLICIT NONE > > INTEGER, INTENT(IN) :: row_length > INTEGER, INTENT(IN) :: rows > INTEGER, INTENT(IN) :: levels > INTEGER, INTENT(IN) :: halo_size > REAL(KIND=8), INTENT(INOUT) :: field(1:row_length, 1:rows, levels) > REAL(KIND=8) :: send_buffer(halo_size, rows, levels) > REAL(KIND=8) :: recv_buffer(halo_size, rows, levels) > INTEGER :: buffer_size > INTEGER :: i,j,k > INTEGER(kind=MPI_INTEGER_KIND) :: ierror > INTEGER(kind=MPI_INTEGER_KIND) :: my_rank, comm_size > Integer(kind=MPI_INTEGER_KIND) :: win, win_info > Integer(kind=MPI_INTEGER_KIND) :: my_group, origin_group, target_group > Integer(kind=MPI_INTEGER_KIND), DIMENSION(1) :: target_rank, origin_rank > Integer(kind=MPI_ADDRESS_KIND) :: win_size, disp > > CALL MPI_Comm_Rank(MPI_COMM_WORLD, my_rank, ierror) > CALL MPI_Comm_Size(MPI_COMM_WORLD, comm_size, ierror) > > buffer_size = halo_size * rows * levels > > CALL MPI_Info_create(win_info, ierror) > CALL MPI_Info_set(win_info, "no_locks", "true", ierror) > > CALL MPI_Comm_group(MPI_COMM_WORLD, my_group, ierror) > > If (my_rank /= comm_size - 1) Then > origin_rank = my_rank + 1 > CALL MPI_Group_incl(my_group, 1, origin_rank, origin_group, ierror) > win_size = 8*buffer_size > Else > origin_group = MPI_GROUP_EMPTY > win_size = 0 > End If > > CALL MPI_Win_create_dynamic(win_info, MPI_COMM_WORLD, win, ierror) > !! CALL MPI_Win_create(recv_buffer, win_size, & > !! 8, win_info, MPI_COMM_WORLD, win, ierror) > CALL MPI_Win_attach(win, recv_buffer, win_size, ierror) > > CALL MPI_Barrier(MPI_COMM_WORLD, ierror) > > CALL MPI_Win_post(origin_group, MPI_MODE_NOSTORE, win, ierror) > > ! Prepare buffer > DO k=1,levels > DO j=1,rows > DO i=1,halo_size > send_buffer(i,j,k)=field(i,j,k) > END DO ! I > END DO ! J > END DO ! K > > If (my_rank /= 0 ) Then > target_rank = my_rank - 1 > CALL MPI_Group_incl(my_group, 1, target_rank, target_group, ierror) > Else > target_group = MPI_GROUP_EMPTY > End If > > CALL MPI_Win_start(target_group, 0, win, ierror) > > disp = 0 > > If (my_rank /= 0) Then > CALL MPI_Put(send_buffer, buffer_size, MPI_REAL8, & > my_rank - 1, disp, buffer_size, MPI_REAL8, win, ierror) > End If > CALL MPI_Win_complete(win, ierror) > > CALL MPI_Barrier(MPI_COMM_WORLD, ierror) > write (0,*) 'Put OK' > CALL MPI_Barrier(MPI_COMM_WORLD, ierror) > > CALL MPI_Win_wait(win, ierror) > > ! Read from buffer > If (my_rank /= comm_size -1 ) Then > DO k=1,levels > DO j=1,rows > DO i=1,halo_size > field(row_length+i,j,k) = recv_buffer(i,j,k) > END DO > END DO > END DO > End if > > CALL MPI_Win_detach(win, recv_buffer, ierror) > CALL MPI_Win_free(win, ierror) > > END SUBROUTINE swap_simple_rma > > Best Regards, > Maciej > > W dniu 14.04.2016 o 19:21, Thakur, Rajeev pisze: > > After the Win_attach, did you add a barrier or some other form of >> synchronization? The put shouldn’t happen before Win_attach returns. >> >> Rajeev >> >> On Apr 14, 2016, at 10:56 AM, Maciej Szpindler <m.szpindler(a)icm.edu.pl> >>> wrote: >>> >>> Dear All, >>> >>> I am trying to use dynamic RMA windows in fortran. In my case I would >>> like to attach automatic array to dynamic window. The question is if >>> it is correct and allowed in MPICH. I feel that it is not working, at >>> least in cray-mpich/7.3.2. >>> >>> I have a subroutine that use RMA windows: >>> >>> SUBROUTINE foo(x, y, z , ...) >>> >>> USE mpi >>> ... >>> >>> INTEGER, INTENT(IN) :: x, y, z >>> REAL(KIND=8) :: buffer(x, y, z) >>> INTEGER(kind=MPI_INTEGER_KIND) :: win_info, win, comm >>> INTEGER(kind=MPI_INTEGER_KIND) :: buff_size >>> ... >>> >>> buff_size = x*y*z*8 >>> >>> CALL MPI_Info_create(win_info, ierror) >>> CALL MPI_Info_set(win_info, "no_locks", "true", ierror) >>> >>> CALL MPI_Win_create_dynamic(win_info, comm, win, ierror) >>> >>> CALL MPI_Win_attach(win, buffer, buff_size, ierror) >>> >>> ... >>> >>> This produces segmentation fault when MPI_Put is called on a window, >>> while exactly the same routine code with static MPI_Win_create on >>> buffer instead of create_dynamic+attach works fine. As far as I >>> understand buffer is in this case "simply contiguous" in a sense of >>> the MPI Standard. Any help would be appreciated! >>> >>> Best Regards, >>> Maciej >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Is it allowed to attach automatic array for remote access with MPI_Win_attach?
by Maciej Szpindler 19 Apr '16

19 Apr '16

This is simplified version of my routine. It may look odd but I am trying to migrate from send/recv scheme to one sided pscw and that is the reason for buffers etc. As long as dynamic windows are not used, it works fine (I believe). When I switch to dynamic windows it fails with segmentation fault. I would appreciate any comment and suggestion how to improve this. SUBROUTINE swap_simple_rma(field, row_length, rows, levels, halo_size) USE mpi IMPLICIT NONE INTEGER, INTENT(IN) :: row_length INTEGER, INTENT(IN) :: rows INTEGER, INTENT(IN) :: levels INTEGER, INTENT(IN) :: halo_size REAL(KIND=8), INTENT(INOUT) :: field(1:row_length, 1:rows, levels) REAL(KIND=8) :: send_buffer(halo_size, rows, levels) REAL(KIND=8) :: recv_buffer(halo_size, rows, levels) INTEGER :: buffer_size INTEGER :: i,j,k INTEGER(kind=MPI_INTEGER_KIND) :: ierror INTEGER(kind=MPI_INTEGER_KIND) :: my_rank, comm_size Integer(kind=MPI_INTEGER_KIND) :: win, win_info Integer(kind=MPI_INTEGER_KIND) :: my_group, origin_group, target_group Integer(kind=MPI_INTEGER_KIND), DIMENSION(1) :: target_rank, origin_rank Integer(kind=MPI_ADDRESS_KIND) :: win_size, disp CALL MPI_Comm_Rank(MPI_COMM_WORLD, my_rank, ierror) CALL MPI_Comm_Size(MPI_COMM_WORLD, comm_size, ierror) buffer_size = halo_size * rows * levels CALL MPI_Info_create(win_info, ierror) CALL MPI_Info_set(win_info, "no_locks", "true", ierror) CALL MPI_Comm_group(MPI_COMM_WORLD, my_group, ierror) If (my_rank /= comm_size - 1) Then origin_rank = my_rank + 1 CALL MPI_Group_incl(my_group, 1, origin_rank, origin_group, ierror) win_size = 8*buffer_size Else origin_group = MPI_GROUP_EMPTY win_size = 0 End If CALL MPI_Win_create_dynamic(win_info, MPI_COMM_WORLD, win, ierror) !! CALL MPI_Win_create(recv_buffer, win_size, & !! 8, win_info, MPI_COMM_WORLD, win, ierror) CALL MPI_Win_attach(win, recv_buffer, win_size, ierror) CALL MPI_Barrier(MPI_COMM_WORLD, ierror) CALL MPI_Win_post(origin_group, MPI_MODE_NOSTORE, win, ierror) ! Prepare buffer DO k=1,levels DO j=1,rows DO i=1,halo_size send_buffer(i,j,k)=field(i,j,k) END DO ! I END DO ! J END DO ! K If (my_rank /= 0 ) Then target_rank = my_rank - 1 CALL MPI_Group_incl(my_group, 1, target_rank, target_group, ierror) Else target_group = MPI_GROUP_EMPTY End If CALL MPI_Win_start(target_group, 0, win, ierror) disp = 0 If (my_rank /= 0) Then CALL MPI_Put(send_buffer, buffer_size, MPI_REAL8, & my_rank - 1, disp, buffer_size, MPI_REAL8, win, ierror) End If CALL MPI_Win_complete(win, ierror) CALL MPI_Barrier(MPI_COMM_WORLD, ierror) write (0,*) 'Put OK' CALL MPI_Barrier(MPI_COMM_WORLD, ierror) CALL MPI_Win_wait(win, ierror) ! Read from buffer If (my_rank /= comm_size -1 ) Then DO k=1,levels DO j=1,rows DO i=1,halo_size field(row_length+i,j,k) = recv_buffer(i,j,k) END DO END DO END DO End if CALL MPI_Win_detach(win, recv_buffer, ierror) CALL MPI_Win_free(win, ierror) END SUBROUTINE swap_simple_rma Best Regards, Maciej W dniu 14.04.2016 o 19:21, Thakur, Rajeev pisze: > After the Win_attach, did you add a barrier or some other form of synchronization? The put shouldn’t happen before Win_attach returns. > > Rajeev > >> On Apr 14, 2016, at 10:56 AM, Maciej Szpindler <m.szpindler(a)icm.edu.pl> wrote: >> >> Dear All, >> >> I am trying to use dynamic RMA windows in fortran. In my case I would >> like to attach automatic array to dynamic window. The question is if >> it is correct and allowed in MPICH. I feel that it is not working, at >> least in cray-mpich/7.3.2. >> >> I have a subroutine that use RMA windows: >> >> SUBROUTINE foo(x, y, z , ...) >> >> USE mpi >> ... >> >> INTEGER, INTENT(IN) :: x, y, z >> REAL(KIND=8) :: buffer(x, y, z) >> INTEGER(kind=MPI_INTEGER_KIND) :: win_info, win, comm >> INTEGER(kind=MPI_INTEGER_KIND) :: buff_size >> ... >> >> buff_size = x*y*z*8 >> >> CALL MPI_Info_create(win_info, ierror) >> CALL MPI_Info_set(win_info, "no_locks", "true", ierror) >> >> CALL MPI_Win_create_dynamic(win_info, comm, win, ierror) >> >> CALL MPI_Win_attach(win, buffer, buff_size, ierror) >> >> ... >> >> This produces segmentation fault when MPI_Put is called on a window, >> while exactly the same routine code with static MPI_Win_create on >> buffer instead of create_dynamic+attach works fine. As far as I >> understand buffer is in this case "simply contiguous" in a sense of >> the MPI Standard. Any help would be appreciated! >> >> Best Regards, >> Maciej >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

collective read slower than non-collective read
by 冰 19 Apr '16

19 Apr '16

Hi, I run programs in one computer, In my tests here, the MPI_File_read_all have been slower than MPI_File_read, could you send me a simple routine that collective read is faster than non-collective read? _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Have constants available in shared library
by Balaji, Pavan 14 Apr '16

14 Apr '16

Erik, I'm curious why you need this to be done in the MPI library (MPICH or Open MPI). Is creating your own library, that essentially does exactly the same thing (JULIA_MPI_INT_g = MPI_INT), and linking that as well, not an option? -- Pavan > On Apr 14, 2016, at 1:44 PM, Erik Schnetter <schnetter(a)gmail.com> wrote: > > Rajeev > > Apologies; I sent an identical request to the OpenMPI developers as > well. I meant the MPICH library here. > > In Julia, it is straightforward to call a function in a shared > library, but it is not possible to access constants that are defined > in a C header file, as this would require parsing C code. It would > thus be convenient to access these constant in a different manner, > e.g. by looking at the value of a global variable or constant. > > -erik > > On Thu, Apr 14, 2016 at 1:50 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: >>> Could you add similar constants to the OpenMPI shared library? >> >> This list is for MPICH. Open MPI has a different mailing list. >> >> In MPICH, these constants are defined in the mpi.h header file. >> >> Rajeev >> >> >>> On Apr 14, 2016, at 9:04 AM, Erik Schnetter <schnetter(a)gmail.com> wrote: >>> >>> I am one of the maintainers of the MPI wrapper package for Julia >>> <https://github.com/JuliaParallel/MPI.jl>. This package provides Julia >>> language bindings for MPI, essentially wrapping various MPI functions, >>> comparable to what mpi4py <http://pythonhosted.org/mpi4py/> does for >>> Python. >>> >>> It is in Julia straightforward to call C functions in a shared >>> library. The MPI API is standardized, so that part is straightforward. >>> What is not standardized are the values of various constants, such as >>> e.g. MPI_INT, MPI_MAX, or MPI_ANY_TAG. >>> >>> We currently use a cmake function that builds and runs a small >>> executable that outputs the (implementation-specific) values of these >>> constants, and auto-generates Julia code that defines these constants. >>> We do this when the Julia MPI package is installed or updated. This >>> works fine, but I think there could be a better way. >>> >>> The HDF5 library <https://www.hdfgroup.org/HDF5/> puts global >>> constants into the data section of their library, with names derived >>> from the preprocessor constants (with a _g suffix, I believe). This >>> makes it straightforward to access the values of these constants at >>> run time. For example, there exists a constant H5T_NATIVE_INT_g. >>> >>> Could you add similar constants to the OpenMPI shared library? This >>> would simplify wrapping the library. >>> >>> Thanks, >>> -erik >>> >>> -- >>> Erik Schnetter <schnetter(a)gmail.com> >>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Erik Schnetter <schnetter(a)gmail.com> > http://www.perimeterinstitute.ca/personal/eschnetter/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Have constants available in shared library
by Kenneth Raffenetti 14 Apr '16

14 Apr '16

There will be sufficient warning when the MPICH ABI changes, so Jeff's approach should work. The MPICH constant values will also be valid for derivatives listed here: http://www.mpich.org/abi/ Ken On 04/14/2016 02:31 PM, Jeff Hammond wrote: > Erik: > > MPICH ABI is standardized so just parse the header once and forget about it. > > Jeff > > On Thursday, April 14, 2016, Erik Schnetter <schnetter(a)gmail.com > <mailto:[email protected]>> wrote: > > Rajeev > > Apologies; I sent an identical request to the OpenMPI developers as > well. I meant the MPICH library here. > > In Julia, it is straightforward to call a function in a shared > library, but it is not possible to access constants that are defined > in a C header file, as this would require parsing C code. It would > thus be convenient to access these constant in a different manner, > e.g. by looking at the value of a global variable or constant. > > -erik > > On Thu, Apr 14, 2016 at 1:50 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov > <javascript:;>> wrote: > >> Could you add similar constants to the OpenMPI shared library? > > > > This list is for MPICH. Open MPI has a different mailing list. > > > > In MPICH, these constants are defined in the mpi.h header file. > > > > Rajeev > > > > > >> On Apr 14, 2016, at 9:04 AM, Erik Schnetter <schnetter(a)gmail.com > <javascript:;>> wrote: > >> > >> I am one of the maintainers of the MPI wrapper package for Julia > >> <https://github.com/JuliaParallel/MPI.jl>. This package provides > Julia > >> language bindings for MPI, essentially wrapping various MPI > functions, > >> comparable to what mpi4py <http://pythonhosted.org/mpi4py/> does for > >> Python. > >> > >> It is in Julia straightforward to call C functions in a shared > >> library. The MPI API is standardized, so that part is > straightforward. > >> What is not standardized are the values of various constants, > such as > >> e.g. MPI_INT, MPI_MAX, or MPI_ANY_TAG. > >> > >> We currently use a cmake function that builds and runs a small > >> executable that outputs the (implementation-specific) values of > these > >> constants, and auto-generates Julia code that defines these > constants. > >> We do this when the Julia MPI package is installed or updated. This > >> works fine, but I think there could be a better way. > >> > >> The HDF5 library <https://www.hdfgroup.org/HDF5/> puts global > >> constants into the data section of their library, with names derived > >> from the preprocessor constants (with a _g suffix, I believe). This > >> makes it straightforward to access the values of these constants at > >> run time. For example, there exists a constant H5T_NATIVE_INT_g. > >> > >> Could you add similar constants to the OpenMPI shared library? This > >> would simplify wrapping the library. > >> > >> Thanks, > >> -erik > >> > >> -- > >> Erik Schnetter <schnetter(a)gmail.com <javascript:;>> > >> http://www.perimeterinstitute.ca/personal/eschnetter/ > >> _______________________________________________ > >> discuss mailing list discuss(a)mpich.org <javascript:;> > >> To manage subscription options or unsubscribe: > >> https://lists.mpich.org/mailman/listinfo/discuss > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org <javascript:;> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Erik Schnetter <schnetter(a)gmail.com <javascript:;>> > http://www.perimeterinstitute.ca/personal/eschnetter/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org <javascript:;> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Have constants available in shared library
by Jeff Hammond 14 Apr '16

14 Apr '16

Erik: MPICH ABI is standardized so just parse the header once and forget about it. Jeff On Thursday, April 14, 2016, Erik Schnetter <schnetter(a)gmail.com> wrote: > Rajeev > > Apologies; I sent an identical request to the OpenMPI developers as > well. I meant the MPICH library here. > > In Julia, it is straightforward to call a function in a shared > library, but it is not possible to access constants that are defined > in a C header file, as this would require parsing C code. It would > thus be convenient to access these constant in a different manner, > e.g. by looking at the value of a global variable or constant. > > -erik > > On Thu, Apr 14, 2016 at 1:50 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov > <javascript:;>> wrote: > >> Could you add similar constants to the OpenMPI shared library? > > > > This list is for MPICH. Open MPI has a different mailing list. > > > > In MPICH, these constants are defined in the mpi.h header file. > > > > Rajeev > > > > > >> On Apr 14, 2016, at 9:04 AM, Erik Schnetter <schnetter(a)gmail.com > <javascript:;>> wrote: > >> > >> I am one of the maintainers of the MPI wrapper package for Julia > >> <https://github.com/JuliaParallel/MPI.jl>. This package provides Julia > >> language bindings for MPI, essentially wrapping various MPI functions, > >> comparable to what mpi4py <http://pythonhosted.org/mpi4py/> does for > >> Python. > >> > >> It is in Julia straightforward to call C functions in a shared > >> library. The MPI API is standardized, so that part is straightforward. > >> What is not standardized are the values of various constants, such as > >> e.g. MPI_INT, MPI_MAX, or MPI_ANY_TAG. > >> > >> We currently use a cmake function that builds and runs a small > >> executable that outputs the (implementation-specific) values of these > >> constants, and auto-generates Julia code that defines these constants. > >> We do this when the Julia MPI package is installed or updated. This > >> works fine, but I think there could be a better way. > >> > >> The HDF5 library <https://www.hdfgroup.org/HDF5/> puts global > >> constants into the data section of their library, with names derived > >> from the preprocessor constants (with a _g suffix, I believe). This > >> makes it straightforward to access the values of these constants at > >> run time. For example, there exists a constant H5T_NATIVE_INT_g. > >> > >> Could you add similar constants to the OpenMPI shared library? This > >> would simplify wrapping the library. > >> > >> Thanks, > >> -erik > >> > >> -- > >> Erik Schnetter <schnetter(a)gmail.com <javascript:;>> > >> http://www.perimeterinstitute.ca/personal/eschnetter/ > >> _______________________________________________ > >> discuss mailing list discuss(a)mpich.org <javascript:;> > >> To manage subscription options or unsubscribe: > >> https://lists.mpich.org/mailman/listinfo/discuss > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org <javascript:;> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Erik Schnetter <schnetter(a)gmail.com <javascript:;>> > http://www.perimeterinstitute.ca/personal/eschnetter/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org <javascript:;> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Have constants available in shared library
by Erik Schnetter 14 Apr '16

14 Apr '16

Rajeev Apologies; I sent an identical request to the OpenMPI developers as well. I meant the MPICH library here. In Julia, it is straightforward to call a function in a shared library, but it is not possible to access constants that are defined in a C header file, as this would require parsing C code. It would thus be convenient to access these constant in a different manner, e.g. by looking at the value of a global variable or constant. -erik On Thu, Apr 14, 2016 at 1:50 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: >> Could you add similar constants to the OpenMPI shared library? > > This list is for MPICH. Open MPI has a different mailing list. > > In MPICH, these constants are defined in the mpi.h header file. > > Rajeev > > >> On Apr 14, 2016, at 9:04 AM, Erik Schnetter <schnetter(a)gmail.com> wrote: >> >> I am one of the maintainers of the MPI wrapper package for Julia >> <https://github.com/JuliaParallel/MPI.jl>. This package provides Julia >> language bindings for MPI, essentially wrapping various MPI functions, >> comparable to what mpi4py <http://pythonhosted.org/mpi4py/> does for >> Python. >> >> It is in Julia straightforward to call C functions in a shared >> library. The MPI API is standardized, so that part is straightforward. >> What is not standardized are the values of various constants, such as >> e.g. MPI_INT, MPI_MAX, or MPI_ANY_TAG. >> >> We currently use a cmake function that builds and runs a small >> executable that outputs the (implementation-specific) values of these >> constants, and auto-generates Julia code that defines these constants. >> We do this when the Julia MPI package is installed or updated. This >> works fine, but I think there could be a better way. >> >> The HDF5 library <https://www.hdfgroup.org/HDF5/> puts global >> constants into the data section of their library, with names derived >> from the preprocessor constants (with a _g suffix, I believe). This >> makes it straightforward to access the values of these constants at >> run time. For example, there exists a constant H5T_NATIVE_INT_g. >> >> Could you add similar constants to the OpenMPI shared library? This >> would simplify wrapping the library. >> >> Thanks, >> -erik >> >> -- >> Erik Schnetter <schnetter(a)gmail.com> >> http://www.perimeterinstitute.ca/personal/eschnetter/ >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Have constants available in shared library
by Thakur, Rajeev 14 Apr '16

14 Apr '16

> Could you add similar constants to the OpenMPI shared library? This list is for MPICH. Open MPI has a different mailing list. In MPICH, these constants are defined in the mpi.h header file. Rajeev > On Apr 14, 2016, at 9:04 AM, Erik Schnetter <schnetter(a)gmail.com> wrote: > > I am one of the maintainers of the MPI wrapper package for Julia > <https://github.com/JuliaParallel/MPI.jl>. This package provides Julia > language bindings for MPI, essentially wrapping various MPI functions, > comparable to what mpi4py <http://pythonhosted.org/mpi4py/> does for > Python. > > It is in Julia straightforward to call C functions in a shared > library. The MPI API is standardized, so that part is straightforward. > What is not standardized are the values of various constants, such as > e.g. MPI_INT, MPI_MAX, or MPI_ANY_TAG. > > We currently use a cmake function that builds and runs a small > executable that outputs the (implementation-specific) values of these > constants, and auto-generates Julia code that defines these constants. > We do this when the Julia MPI package is installed or updated. This > works fine, but I think there could be a better way. > > The HDF5 library <https://www.hdfgroup.org/HDF5/> puts global > constants into the data section of their library, with names derived > from the preprocessor constants (with a _g suffix, I believe). This > makes it straightforward to access the values of these constants at > run time. For example, there exists a constant H5T_NATIVE_INT_g. > > Could you add similar constants to the OpenMPI shared library? This > would simplify wrapping the library. > > Thanks, > -erik > > -- > Erik Schnetter <schnetter(a)gmail.com> > http://www.perimeterinstitute.ca/personal/eschnetter/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Is it allowed to attach automatic array for remote access with MPI_Win_attach?
by Thakur, Rajeev 14 Apr '16

14 Apr '16

After the Win_attach, did you add a barrier or some other form of synchronization? The put shouldn’t happen before Win_attach returns. Rajeev > On Apr 14, 2016, at 10:56 AM, Maciej Szpindler <m.szpindler(a)icm.edu.pl> wrote: > > Dear All, > > I am trying to use dynamic RMA windows in fortran. In my case I would > like to attach automatic array to dynamic window. The question is if > it is correct and allowed in MPICH. I feel that it is not working, at > least in cray-mpich/7.3.2. > > I have a subroutine that use RMA windows: > > SUBROUTINE foo(x, y, z , ...) > > USE mpi > ... > > INTEGER, INTENT(IN) :: x, y, z > REAL(KIND=8) :: buffer(x, y, z) > INTEGER(kind=MPI_INTEGER_KIND) :: win_info, win, comm > INTEGER(kind=MPI_INTEGER_KIND) :: buff_size > ... > > buff_size = x*y*z*8 > > CALL MPI_Info_create(win_info, ierror) > CALL MPI_Info_set(win_info, "no_locks", "true", ierror) > > CALL MPI_Win_create_dynamic(win_info, comm, win, ierror) > > CALL MPI_Win_attach(win, buffer, buff_size, ierror) > > ... > > This produces segmentation fault when MPI_Put is called on a window, > while exactly the same routine code with static MPI_Win_create on > buffer instead of create_dynamic+attach works fine. As far as I > understand buffer is in this case "simply contiguous" in a sense of > the MPI Standard. Any help would be appreciated! > > Best Regards, > Maciej > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0