June 2018 - discuss - mailman3.cels.anl.gov

osu_latency test: why 8KB takes less time than 4KB and 2KB takes less time than 1KB?
by Abu Naser 20 Jun '18

20 Jun '18

Good day to all, I had run point to point osu_latency test in two nodes for 200 times. Followings are the average time in microsecond for various size of the messages - 1KB 84.8514 us 2KB 73.52535 us 4KB 272.55275 us 8KB 234.86385 us 16KB 288.88 us 32KB 523.3725 us 64KB 910.4025 us

1 0

Re: [mpich-discuss] Help with debugging
by Jeff Hammond 19 Jun '18

19 Jun '18

You can rule out MPICH shm bugs if the code runs fine with Open-MPI or by disabling shm in MPICH, eg by using ch3:sock. The fact that small messages work suggest rendezvous deadlock is the issue, which is often but not always an application error. It’s impossible to reason about the precise nature of the bug without source code. Jeff Sent from my iPhone > On Jun 19, 2018, at 5:52 PM, Kochunas, Brendan <bkochuna(a)umich.edu> wrote: > > We've been dealing with a particularly nasty bug in our code and are having trouble debugging it. > > We are using RHEL7 with default GNU compiler colleciton (4.8.5) and yum package for mpich (mpich-3.2-x86_64) > > The rest of this email describes briefly: > > * Our communication pattern > * what we observe > * what we've tested (and think we know) > > Description of communication pattern: > This is point-to-point communication using MPI_Isend, MPI_Irecv, and MPI_Waitall. Its effectively a structured cartesian grid and we send multiple messages per face that are probably large (message sizes are a few KB). > > What we observe: > The problem we run into is that when we get to the MPI_Waitall we receive something like: > > Fatal error in PMPI_Waitall: Other MPI error, error stack: > PMPI_Waitall(323)...............: MPI_Waitall(count=1152, req_array=0x13493b90, status_array=0x1) failed > MPIR_Waitall_impl(166)..........: > MPIDI_CH3I_Progress(422)........: > MPID_nem_handle_pkt(642)........: > pkt_CTS_handler(321)............: > MPID_nem_lmt_shm_start_send(270): > MPID_nem_delete_shm_region(923).: > MPIU_SHMW_Seg_detach(707).......: unable to remove shared memory - unlink No such file or directory > > Our test case is 9 processors (a 3x3 grid) > > We have tested several things that allow us to avoid the problem (but not reliably) if: > * we send multiple messages (about 50x) that are smaller, instead of one large message. > * Adding debug print statements near the MPI_Waitall > * Removing compiler optimizations > * Running under valgrind (e.g. mpirun -np <n> valgrind <exe>) > > * We have also observed this error on multiple machines (Cray XK7, workstations with Intel Xeon's, SGI ICE-X with MVAPICH) > > The output from valgrind is: > > ==210233== Invalid read of size 8 > ==210233== at 0xB3B7060: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1022) > ==210233== by 0xE7F8FBB: MPID_nem_mpich_sendv_header (mpid_nem_inline.h:363) > ==210233== by 0xE7F8FBB: MPIDI_CH3I_Shm_send_progress (ch3_progress.c:207) > ==210233== by 0xE7FBD93: MPIDI_CH3I_Progress (ch3_progress.c:583) > ==210233== by 0xE7276B4: MPIR_Waitall_impl (waitall.c:164) > ==210233== by 0xE727BB5: PMPI_Waitall (waitall.c:378) > ==210233== by 0xDFE4DFD: mpi_waitall (waitallf.c:275) > ==210233== by 0x49FF27F: __updatebc_MOD_finish_updatebc_base (UpdateBC.f90:361) > ==210233== Address 0x142ec268 is 152 bytes inside a block of size 216 free'd > ==210233== at 0xB3B3CBD: free (vg_replace_malloc.c:530) > ==210233== by 0xE83FB41: MPL_trfree (in /home/bkochuna/sw/lib/libmpi.so.12.1.0) > ==210233== by 0xE7837D8: MPIU_trfree (trmem.c:37) > ==210233== by 0xE80DC08: MPIU_SHMW_Hnd_free (mpiu_shm_wrappers.h:247) > ==210233== by 0xE80DC08: MPIU_SHMW_Hnd_finalize (mpiu_shm_wrappers.h:443) > ==210233== by 0xE80DC08: MPID_nem_delete_shm_region (mpid_nem_lmt_shm.c:963) > ==210233== by 0xE80DC08: MPID_nem_lmt_shm_start_send (mpid_nem_lmt_shm.c:270) > ==210233== by 0xE8097E0: pkt_CTS_handler (mpid_nem_lmt.c:352) > ==210233== by 0xE7FB3C5: MPID_nem_handle_pkt (ch3_progress.c:760) > ==210233== by 0xE7FBF8D: MPIDI_CH3I_Progress (ch3_progress.c:570) > ==210233== by 0xE7276B4: MPIR_Waitall_impl (waitall.c:164) > ==210233== by 0xE727BB5: PMPI_Waitall (waitall.c:378) > ==210233== by 0xDFE4DFD: mpi_waitall (waitallf.c:275) > ==210233== by 0x49FF27F: __updatebc_MOD_finish_updatebc_base (UpdateBC.f90:361) > ==210233== Block was alloc'd at > ==210233== at 0xB3B2BC3: malloc (vg_replace_malloc.c:299) > ==210233== by 0xE83F38F: MPL_trmalloc (in /home/bkochuna/sw/lib/libmpi.so.12.1.0) > ==210233== by 0xE783526: MPIU_trmalloc (trmem.c:29) > ==210233== by 0xE80CF74: MPIU_SHMW_Ghnd_alloc (mpiu_shm_wrappers.h:188) > ==210233== by 0xE80CF74: MPIU_SHMW_Seg_create_attach_templ (mpiu_shm_wrappers.h:622) > ==210233== by 0xE80CF74: MPIU_SHMW_Seg_create_and_attach (mpiu_shm_wrappers.h:894) > ==210233== by 0xE80CF74: MPID_nem_allocate_shm_region (mpid_nem_lmt_shm.c:885) > ==210233== by 0xE80CF74: MPID_nem_lmt_shm_start_recv (mpid_nem_lmt_shm.c:180) > ==210233== by 0xE8094AF: do_cts (mpid_nem_lmt.c:560) > ==210233== by 0xE809EBE: pkt_RTS_handler (mpid_nem_lmt.c:276) > ==210233== by 0xE7FB3C5: MPID_nem_handle_pkt (ch3_progress.c:760) > ==210233== by 0xE7FBF8D: MPIDI_CH3I_Progress (ch3_progress.c:570) > ==210233== by 0xE7276B4: MPIR_Waitall_impl (waitall.c:164) > ==210233== by 0xE727BB5: PMPI_Waitall (waitall.c:378) > ==210233== by 0xDFE4DFD: mpi_waitall (waitallf.c:275) > ==210233== by 0x49FF27F: __updatebc_MOD_finish_updatebc_base (UpdateBC.f90:361) > > So my main questions to the list are: > * are there any known issues with mpich-3.2 and the shared memory communication within nemesis that might affect non-blocking communication? > * Does this look more like an issue in our code or within MPICH? > * If it looks like an issue in our code what is the best way to debug this... seems like our current efforts of basic print statements change the behavior and prevent us from identifying it. I suspect there may be some memory overwrite beyond some array bounds, but compiling in debug with -fbounds-check does not expose the problem (and due to the nature of the MPI interfaces, I would not expect this to help). We've stared at the code for the calls to MPI_Isend and MPI_Irecv and everything looks correct (e.g. we don't touch the buffers, the sizes match up, etc.) > * Are there limits to the number of simultaneous messages? (we are below the maximum number of MPI requests) or message sizes (I don't believe there is a limit here beyond integer overflow) > * We've tried changing from MPI_Waitall to individual MPI_Waits and MPI_Tests, but the problem still happens with the individual waits. > > Any insights are welcome. > > Thanks, > -Brendan > > _______________________________________________ > 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

Help with debugging
by Kochunas, Brendan 19 Jun '18

19 Jun '18

We've been dealing with a particularly nasty bug in our code and are having trouble debugging it. We are using RHEL7 with default GNU compiler colleciton (4.8.5) and yum package for mpich (mpich-3.2-x86_64) The rest of this email describes briefly: * Our communication pattern * what we observe * what we've tested (and think we know) Description of communication pattern: This is point-to-point communication using MPI_Isend, MPI_Irecv, and MPI_Waitall. Its effectively a structured cartesian grid and we send multiple messages per face that are probably large (message sizes are a few KB). What we observe: The problem we run into is that when we get to the MPI_Waitall we receive something like: Fatal error in PMPI_Waitall: Other MPI error, error stack: PMPI_Waitall(323)...............: MPI_Waitall(count=1152, req_array=0x13493b90, status_array=0x1) failed MPIR_Waitall_impl(166)..........: MPIDI_CH3I_Progress(422)........: MPID_nem_handle_pkt(642)........: pkt_CTS_handler(321)............: MPID_nem_lmt_shm_start_send(270): MPID_nem_delete_shm_region(923).: MPIU_SHMW_Seg_detach(707).......: unable to remove shared memory - unlink No such file or directory Our test case is 9 processors (a 3x3 grid) We have tested several things that allow us to avoid the problem (but not reliably) if: * we send multiple messages (about 50x) that are smaller, instead of one large message. * Adding debug print statements near the MPI_Waitall * Removing compiler optimizations * Running under valgrind (e.g. mpirun -np <n> valgrind <exe>) * We have also observed this error on multiple machines (Cray XK7, workstations with Intel Xeon's, SGI ICE-X with MVAPICH) The output from valgrind is: ==210233== Invalid read of size 8 ==210233== at 0xB3B7060: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1022) ==210233== by 0xE7F8FBB: MPID_nem_mpich_sendv_header (mpid_nem_inline.h:363) ==210233== by 0xE7F8FBB: MPIDI_CH3I_Shm_send_progress (ch3_progress.c:207) ==210233== by 0xE7FBD93: MPIDI_CH3I_Progress (ch3_progress.c:583) ==210233== by 0xE7276B4: MPIR_Waitall_impl (waitall.c:164) ==210233== by 0xE727BB5: PMPI_Waitall (waitall.c:378) ==210233== by 0xDFE4DFD: mpi_waitall (waitallf.c:275) ==210233== by 0x49FF27F: __updatebc_MOD_finish_updatebc_base (UpdateBC.f90:361) ==210233== Address 0x142ec268 is 152 bytes inside a block of size 216 free'd ==210233== at 0xB3B3CBD: free (vg_replace_malloc.c:530) ==210233== by 0xE83FB41: MPL_trfree (in /home/bkochuna/sw/lib/libmpi.so.12.1.0) ==210233== by 0xE7837D8: MPIU_trfree (trmem.c:37) ==210233== by 0xE80DC08: MPIU_SHMW_Hnd_free (mpiu_shm_wrappers.h:247) ==210233== by 0xE80DC08: MPIU_SHMW_Hnd_finalize (mpiu_shm_wrappers.h:443) ==210233== by 0xE80DC08: MPID_nem_delete_shm_region (mpid_nem_lmt_shm.c:963) ==210233== by 0xE80DC08: MPID_nem_lmt_shm_start_send (mpid_nem_lmt_shm.c:270) ==210233== by 0xE8097E0: pkt_CTS_handler (mpid_nem_lmt.c:352) ==210233== by 0xE7FB3C5: MPID_nem_handle_pkt (ch3_progress.c:760) ==210233== by 0xE7FBF8D: MPIDI_CH3I_Progress (ch3_progress.c:570) ==210233== by 0xE7276B4: MPIR_Waitall_impl (waitall.c:164) ==210233== by 0xE727BB5: PMPI_Waitall (waitall.c:378) ==210233== by 0xDFE4DFD: mpi_waitall (waitallf.c:275) ==210233== by 0x49FF27F: __updatebc_MOD_finish_updatebc_base (UpdateBC.f90:361) ==210233== Block was alloc'd at ==210233== at 0xB3B2BC3: malloc (vg_replace_malloc.c:299) ==210233== by 0xE83F38F: MPL_trmalloc (in /home/bkochuna/sw/lib/libmpi.so.12.1.0) ==210233== by 0xE783526: MPIU_trmalloc (trmem.c:29) ==210233== by 0xE80CF74: MPIU_SHMW_Ghnd_alloc (mpiu_shm_wrappers.h:188) ==210233== by 0xE80CF74: MPIU_SHMW_Seg_create_attach_templ (mpiu_shm_wrappers.h:622) ==210233== by 0xE80CF74: MPIU_SHMW_Seg_create_and_attach (mpiu_shm_wrappers.h:894) ==210233== by 0xE80CF74: MPID_nem_allocate_shm_region (mpid_nem_lmt_shm.c:885) ==210233== by 0xE80CF74: MPID_nem_lmt_shm_start_recv (mpid_nem_lmt_shm.c:180) ==210233== by 0xE8094AF: do_cts (mpid_nem_lmt.c:560) ==210233== by 0xE809EBE: pkt_RTS_handler (mpid_nem_lmt.c:276) ==210233== by 0xE7FB3C5: MPID_nem_handle_pkt (ch3_progress.c:760) ==210233== by 0xE7FBF8D: MPIDI_CH3I_Progress (ch3_progress.c:570) ==210233== by 0xE7276B4: MPIR_Waitall_impl (waitall.c:164) ==210233== by 0xE727BB5: PMPI_Waitall (waitall.c:378) ==210233== by 0xDFE4DFD: mpi_waitall (waitallf.c:275) ==210233== by 0x49FF27F: __updatebc_MOD_finish_updatebc_base (UpdateBC.f90:361) So my main questions to the list are: * are there any known issues with mpich-3.2 and the shared memory communication within nemesis that might affect non-blocking communication? * Does this look more like an issue in our code or within MPICH? * If it looks like an issue in our code what is the best way to debug this... seems like our current efforts of basic print statements change the behavior and prevent us from identifying it. I suspect there may be some memory overwrite beyond some array bounds, but compiling in debug with -fbounds-check does not expose the problem (and due to the nature of the MPI interfaces, I would not expect this to help). We've stared at the code for the calls to MPI_Isend and MPI_Irecv and everything looks correct (e.g. we don't touch the buffers, the sizes match up, etc.) * Are there limits to the number of simultaneous messages? (we are below the maximum number of MPI requests) or message sizes (I don't believe there is a limit here beyond integer overflow) * We've tried changing from MPI_Waitall to individual MPI_Waits and MPI_Tests, but the problem still happens with the individual waits. Any insights are welcome. Thanks, -Brendan _______________________________________________ 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] MPICH-3.2.1 crashes on MPI_BARRIER call - no idea from anyone so far
by Min Si 19 Jun '18

19 Jun '18

Hi Bill, I just tried the program with MPICH-3.2.1/gfortran/ssh, it works fine. I guess it is an issue related to the low level network connection. We might need more information from you to figure out the problem. Could you please first check: - Make sure `mpiexec` is the one installed with MPICH-3.2.1, but not the old one installed with MPICH-1.2.7 - Send us the output of `mpichversion` And try: mpiexec -f machines -launcher rsh –n 3 hostname Min On 2018/06/19 16:28, Bill Petrick wrote: > Hi all, > > For the past 9 years I've been running MPICH-1.2.7 with the g95 > fortran compiler. I just upgraded to MPICH-3.2.1 with a gfortran > compiler. My first tests running on 2 nodes were fine. When I ran the > program on 3 or more nodes it crashes at the first MPI_BARRIER call. > As a test I ran the following "helloworld" program. It runs on all > nodes just fine until I add the MPI_BARRIER statement. With the > MPI_BARRIER statement it also runs fine on 2 nodes but crashes when > run on 3 or more nodes. I execute with the following statement. > > mpiexec -f machines -launcher rsh –n 2 ./helloworld > > This program runs fine on all nodes without the MPI_BARRIER call but > crashes on more than two nodes with the BARRIER call. > ____________________________________________________ > program main > use mpi > integer ( kind = 4 ) error > integer ( kind = 4 ) id > integer ( kind = 4 ) p > real ( kind = 8 ) wtime > ! Initialize MPI. > call MPI_Init ( error ) > ! Get the number of processes. > call MPI_Comm_size ( MPI_COMM_WORLD, p, error ) > ! Get the individual process ID. > call MPI_Comm_rank ( MPI_COMM_WORLD, id, error ) > call MPI_BARRIER(MPI_COMM_WORLD,error) > ! > ! Print a message. > ! > .................etc__________________________________________ > > However when I run it on 3 or more nodes it crashes at MPI_BARRIER > with the following error message > __________________________________________________________________________ > > iic@node0:/clusterfiles$ mpiexec -f machines -launcher rsh -n 3 > ./helloworld > Fatal error in PMPI_Barrier: Unknown error class, error stack: > PMPI_Barrier(425)......: MPI_Barrier(MPI_COMM_WORLD) failed > MPIR_Barrier_impl(332).: Failure during collective > MPIR_Barrier_impl(327).: > MPIR_Barrier(292)......: > MPIR_Barrier_intra(180): Failure during collective > Fatal error in PMPI_Barrier: Unknown error class, error stack: > PMPI_Barrier(425)...............: MPI_Barrier(MPI_COMM_WORLD) failed > MPIR_Barrier_impl(332)..........: Failure during collective > MPIR_Barrier_impl(327)..........: > MPIR_Barrier(292)...............: > MPIR_Barrier_intra(169).........: > MPID_nem_tcp_connpoll(1845).....: Communication error with rank 2: > Connection refused > MPIR_Barrier_intra(169).........: > MPIDI_CH3U_Recvq_FDU_or_AEP(629): Communication error with rank 2 > iic@node0:/clusterfiles$ > ______________________________________________________ > > > /etc/hosts is consistent across all nodes. > /usr/bin/rsh exists on all nodes > the "machines" file is the same on all nodes. > > Anyone have any ideas about what could be wrong? Thanks, Bill > > _______________________________________________ > 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

MPICH-3.2.1 crashes on MPI_BARRIER call - no idea from anyone so far
by Bill Petrick 19 Jun '18

19 Jun '18

Hi all, For the past 9 years I've been running MPICH-1.2.7 with the g95 fortran compiler. I just upgraded to MPICH-3.2.1 with a gfortran compiler. My first tests running on 2 nodes were fine. When I ran the program on 3 or more nodes it crashes at the first MPI_BARRIER call. As a test I ran the following "helloworld" program. It runs on all nodes just fine until I add the MPI_BARRIER statement. With the MPI_BARRIER statement it also runs fine on 2 nodes but crashes when run on 3 or more nodes. I execute with the following statement. mpiexec -f machines -launcher rsh –n 2 ./helloworld This program runs fine on all nodes without the MPI_BARRIER call but crashes on more than two nodes with the BARRIER call. ____________________________________________________ program main use mpi integer ( kind = 4 ) error integer ( kind = 4 ) id integer ( kind = 4 ) p real ( kind = 8 ) wtime ! Initialize MPI. call MPI_Init ( error ) ! Get the number of processes. call MPI_Comm_size ( MPI_COMM_WORLD, p, error ) ! Get the individual process ID. call MPI_Comm_rank ( MPI_COMM_WORLD, id, error ) call MPI_BARRIER(MPI_COMM_WORLD,error) ! ! Print a message. ! .................etc__________________________________________ However when I run it on 3 or more nodes it crashes at MPI_BARRIER with the following error message __________________________________________________________________________ iic@node0:/clusterfiles$ mpiexec -f machines -launcher rsh -n 3 ./helloworld Fatal error in PMPI_Barrier: Unknown error class, error stack: PMPI_Barrier(425)......: MPI_Barrier(MPI_COMM_WORLD) failed MPIR_Barrier_impl(332).: Failure during collective MPIR_Barrier_impl(327).: MPIR_Barrier(292)......: MPIR_Barrier_intra(180): Failure during collective Fatal error in PMPI_Barrier: Unknown error class, error stack: PMPI_Barrier(425)...............: MPI_Barrier(MPI_COMM_WORLD) failed MPIR_Barrier_impl(332)..........: Failure during collective MPIR_Barrier_impl(327)..........: MPIR_Barrier(292)...............: MPIR_Barrier_intra(169).........: MPID_nem_tcp_connpoll(1845).....: Communication error with rank 2: Connection refused MPIR_Barrier_intra(169).........: MPIDI_CH3U_Recvq_FDU_or_AEP(629): Communication error with rank 2 iic@node0:/clusterfiles$ ______________________________________________________ /etc/hosts is consistent across all nodes. /usr/bin/rsh exists on all nodes the "machines" file is the same on all nodes. Anyone have any ideas about what could be wrong? Thanks, Bill _______________________________________________ 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] MPICH 3.2.1 build error with icc+ifort: undefined reference to `_Static_assert'
by Gus Correa 14 Jun '18

14 Jun '18

Hi Jeff No, I haven't tried to compile with GCC 8. The computer has gcc 7.3.1 from Fedora 26. I also doubt the code is really Fortran 90 compliant. It has Cray pointers, included files (chains of them), and things the like. This is a small project to get a postdoc here up and running with his research, and the solution you provided is fine. Many thanks, Gus On 06/14/2018 04:04 PM, Jeff Hammond wrote: > It’s shocking that a compliant Fortran 90 code doesn’t compile with GCC > 8. Have you reported the bugs to GCC bugzilla? > > Jeff > > On Thu, Jun 14, 2018 at 12:56 PM Gus Correa <gus(a)ldeo.columbia.edu > <mailto:[email protected]>> wrote: > > Hi Jeff > > This is actually to compile a Fortran90 program, > which uses MPI and another library (netCDF) through > Fortran modules (use MPI, use netcdf). > The code doesn't compile under gfortran, only with ifort. > Optimization and efficiency is not the top priority, > if we can get the code to compile and run that is fine. > > Since Fortran modules are compiler-dependent, I need to > build MPICH (and netCDF) with the Intel compilers. > I have done this for a variety of compilers and compiler > versions for our clusters (before Infiniband with MPICH, > then with Open MPI), > but this turn it is for a single workstation, > hence MPICH is a good fit. > > That Fortran90 modules are compiler-dependent really sucks, > and is the negation of software inter-operability > and portability. > It may serve well the compiler vendors, > but for users it is just a pain. > > Anyway, your suggestion to tweak with that include file worked, > and I could build MPICH 3.2.1 with the archaic Intel 2012. > > Many thanks! > Gus Correa > > > On 06/13/2018 11:34 PM, Jeff Hammond wrote: > > I don’t know for sure, but I’d guess that GCC 8 or Clang 6 optimizes > > better than ICC 12 and the likelihood goes up the newer the > hardware. > > Intel people contribute to the OSS compilers, particularly when > it comes > > to architecture-specific optimizations. > > > > Jeff > > > > On Wed, Jun 13, 2018 at 5:02 PM Jeff Hammond > <jeff.science(a)gmail.com <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > On Wed, Jun 13, 2018 at 4:44 PM, Gus Correa > <gus(a)ldeo.columbia.edu <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > > > > > On 06/13/2018 07:36 PM, Jeff Hammond wrote: > > > > Why don't you just use a newer ICC? September 28, > 2012 was > > a long time ago... > > > > > Jeff > > > > The cost of a new license. :( > > > > > > Do any of the options on > > https://software.intel.com/en-us/qualify-for-free-software work > for you? > > > > It is temporary, but you can get Intel 19 beta for free > > > (https://software.intel.com/en-us/articles/intel-parallel-studio-xe-2019-beta) > > > > What code are you developing? > > > > Jeff > > > > > > On Wed, Jun 13, 2018 at 4:32 PM, Gus Correa > > <gus(a)ldeo.columbia.edu <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > > > > Thank you Jeff and Min! > > > > Would you know if MPICH 3.2 has the same issue? > > I would rather use an older version instead, as > long as > > it builds. > > > > Many thanks, > > Gus Correa > > > > On 06/13/2018 06:34 PM, Min Si wrote: > > > > I was just creating the issue on MPICH > github when > > Jeff replied. > > > > Please use this issue to keep track: > > https://github.com/pmodels/mpich/issues/3178 > > <https://github.com/pmodels/mpich/issues/3178> > > > > Min > > On 2018/06/13 15:19, Jeff Hammond wrote: > > > > _Static_assert comes from C11. > > > > src/include/mpir_assert.h does a direct test > > for C11 support > > based upon the GCC version, which is unsafe > > since ICC (and > > other non-GCC compilers) define these > macros. > > > > /* GCC 4.6 added support for _Static_assert: > > * http://gcc.gnu.org/gcc-4.6/changes.html > > <http://gcc.gnu.org/gcc-4.6/changes.html> */ > > #if (__GNUC__ > 4 || (__GNUC__ == 4 && > > __GNUC_MINOR__ >= 6)) > > && !defined __cplusplus > > #define HAVE_C11__STATIC_ASSERT 1 > > #endif > > > > MPICH needs to test for _Static_assert > properly > > using > > configure. You should file a GitHub > issue to > > track this. > > > > Jeff > > > > On Wed, Jun 13, 2018 at 2:33 PM, Gus Correa > > <gus(a)ldeo.columbia.edu > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>>> wrote: > > > > Hi MPICH experts > > > > I am trying to build MPICH 3.2.1 > with Intel > > compilers (icc, ifort). > > C++ is disabled. > > > > The configuration step goes well, > > but make fails, > > after a lot of stuff is compiled, > > with the error below (undefined > reference to > > `_Static_assert'). > > > > FYI, the OS is Linux Fedora Core 26: > > > > Linux 4.15.17-200.fc26.x86_64 #1 > SMP Thu > > Apr 12 > > 18:28:26 UTC 2018 > > x86_64 x86_64 GNU/Linux > > > > The Intel compiler version is 12.1.6: > > ifort (IFORT) 12.1.6 20120928 > > icc (ICC) 12.1.6 20120928 > > > > The Intel compiler environment is > set the > > standard way > > recommended by Intel: > > > > source > /path/to/intel/bin/compilervars.sh > > intel64 > > > > > > Any help is appreciated. > > Gus Correa > > > > ****** make errror message > > ************************************* > > make[2]: Entering directory > > > > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > > CCLD src/env/mpivars > > > > lib/.libs/libmpi.a(lib_libmpi_la-ch3_progress.o): In > > function > > `MPIDI_CH3I_Shm_send_progress': > > > > > ../src/mpid/ch3/channels/nemesis/src/ch3_progress.c:(.text+0x1ea2): > > undefined > > reference to `_Static_assert' > > > > > lib/.libs/libmpi.a(lib_libmpi_la-ch3i_eagernoncontig.o): In > > function `MPIDI_CH3I_SendNoncontig': > > > > > ../src/mpid/ch3/channels/nemesis/src/ch3i_eagernoncontig.c:(.text+0x1d3): > > undefined reference to `_Static_assert' > > make[2]: *** [Makefile:19701: > > src/env/mpivars] Error 1 > > make[2]: Leaving directory > > > > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > > make[1]: *** [Makefile:38608: > > all-recursive] Error 1 > > make[1]: Leaving directory > > > > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > > make: *** [Makefile:10337: all] Error 2 > > > > > ******************************************************************* > > > > > > _______________________________________________ > > discuss mailing list > discuss(a)mpich.org <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> > > To manage subscription options or > unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > <https://lists.mpich.org/mailman/listinfo/discuss > > > <https://lists.mpich.org/mailman/listinfo/discuss>> > > > > > > > > > > -- Jeff Hammond > > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>> > > http://jeffhammond.github.io/ > > > > > > > _______________________________________________ > > discuss mailing listdiscuss(a)mpich.org > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > To manage subscription options or > unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > http://jeffhammond.github.io/ > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > http://jeffhammond.github.io/ > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > http://jeffhammond.github.io/ > > _______________________________________________ > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > 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] MPICH 3.2.1 build error with icc+ifort: undefined reference to `_Static_assert'
by Jeff Hammond 14 Jun '18

14 Jun '18

It’s shocking that a compliant Fortran 90 code doesn’t compile with GCC 8. Have you reported the bugs to GCC bugzilla? Jeff On Thu, Jun 14, 2018 at 12:56 PM Gus Correa <gus(a)ldeo.columbia.edu> wrote: > Hi Jeff > > This is actually to compile a Fortran90 program, > which uses MPI and another library (netCDF) through > Fortran modules (use MPI, use netcdf). > The code doesn't compile under gfortran, only with ifort. > Optimization and efficiency is not the top priority, > if we can get the code to compile and run that is fine. > > Since Fortran modules are compiler-dependent, I need to > build MPICH (and netCDF) with the Intel compilers. > I have done this for a variety of compilers and compiler > versions for our clusters (before Infiniband with MPICH, > then with Open MPI), > but this turn it is for a single workstation, > hence MPICH is a good fit. > > That Fortran90 modules are compiler-dependent really sucks, > and is the negation of software inter-operability > and portability. > It may serve well the compiler vendors, > but for users it is just a pain. > > Anyway, your suggestion to tweak with that include file worked, > and I could build MPICH 3.2.1 with the archaic Intel 2012. > > Many thanks! > Gus Correa > > > On 06/13/2018 11:34 PM, Jeff Hammond wrote: > > I don’t know for sure, but I’d guess that GCC 8 or Clang 6 optimizes > > better than ICC 12 and the likelihood goes up the newer the hardware. > > Intel people contribute to the OSS compilers, particularly when it comes > > to architecture-specific optimizations. > > > > Jeff > > > > On Wed, Jun 13, 2018 at 5:02 PM Jeff Hammond <jeff.science(a)gmail.com > > <mailto:[email protected]>> wrote: > > > > On Wed, Jun 13, 2018 at 4:44 PM, Gus Correa <gus(a)ldeo.columbia.edu > > <mailto:[email protected]>> wrote: > > > > > > > > On 06/13/2018 07:36 PM, Jeff Hammond wrote: > > > > Why don't you just use a newer ICC? September 28, 2012 was > > a long time ago... > > > > > Jeff > > > > The cost of a new license. :( > > > > > > Do any of the options on > > https://software.intel.com/en-us/qualify-for-free-software work for > you? > > > > It is temporary, but you can get Intel 19 beta for free > > ( > https://software.intel.com/en-us/articles/intel-parallel-studio-xe-2019-beta > ). > > > > What code are you developing? > > > > Jeff > > > > > > On Wed, Jun 13, 2018 at 4:32 PM, Gus Correa > > <gus(a)ldeo.columbia.edu <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>>> wrote: > > > > Thank you Jeff and Min! > > > > Would you know if MPICH 3.2 has the same issue? > > I would rather use an older version instead, as long as > > it builds. > > > > Many thanks, > > Gus Correa > > > > On 06/13/2018 06:34 PM, Min Si wrote: > > > > I was just creating the issue on MPICH github when > > Jeff replied. > > > > Please use this issue to keep track: > > https://github.com/pmodels/mpich/issues/3178 > > <https://github.com/pmodels/mpich/issues/3178> > > > > Min > > On 2018/06/13 15:19, Jeff Hammond wrote: > > > > _Static_assert comes from C11. > > > > src/include/mpir_assert.h does a direct test > > for C11 support > > based upon the GCC version, which is unsafe > > since ICC (and > > other non-GCC compilers) define these macros. > > > > /* GCC 4.6 added support for _Static_assert: > > * http://gcc.gnu.org/gcc-4.6/changes.html > > <http://gcc.gnu.org/gcc-4.6/changes.html> */ > > #if (__GNUC__ > 4 || (__GNUC__ == 4 && > > __GNUC_MINOR__ >= 6)) > > && !defined __cplusplus > > #define HAVE_C11__STATIC_ASSERT 1 > > #endif > > > > MPICH needs to test for _Static_assert properly > > using > > configure. You should file a GitHub issue to > > track this. > > > > Jeff > > > > On Wed, Jun 13, 2018 at 2:33 PM, Gus Correa > > <gus(a)ldeo.columbia.edu > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > <mailto:[email protected] > > <mailto:[email protected]> > > > > <mailto:[email protected] > > <mailto:[email protected]>>>> wrote: > > > > Hi MPICH experts > > > > I am trying to build MPICH 3.2.1 with Intel > > compilers (icc, ifort). > > C++ is disabled. > > > > The configuration step goes well, > > but make fails, > > after a lot of stuff is compiled, > > with the error below (undefined reference > to > > `_Static_assert'). > > > > FYI, the OS is Linux Fedora Core 26: > > > > Linux 4.15.17-200.fc26.x86_64 #1 SMP Thu > > Apr 12 > > 18:28:26 UTC 2018 > > x86_64 x86_64 GNU/Linux > > > > The Intel compiler version is 12.1.6: > > ifort (IFORT) 12.1.6 20120928 > > icc (ICC) 12.1.6 20120928 > > > > The Intel compiler environment is set the > > standard way > > recommended by Intel: > > > > source /path/to/intel/bin/compilervars.sh > > intel64 > > > > > > Any help is appreciated. > > Gus Correa > > > > ****** make errror message > > ************************************* > > make[2]: Entering directory > > > > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > > CCLD src/env/mpivars > > > > lib/.libs/libmpi.a(lib_libmpi_la-ch3_progress.o): In > > function > > `MPIDI_CH3I_Shm_send_progress': > > > > > ../src/mpid/ch3/channels/nemesis/src/ch3_progress.c:(.text+0x1ea2): > > undefined > > reference to `_Static_assert' > > > > lib/.libs/libmpi.a(lib_libmpi_la-ch3i_eagernoncontig.o): In > > function `MPIDI_CH3I_SendNoncontig': > > > > > ../src/mpid/ch3/channels/nemesis/src/ch3i_eagernoncontig.c:(.text+0x1d3): > > undefined reference to `_Static_assert' > > make[2]: *** [Makefile:19701: > > src/env/mpivars] Error 1 > > make[2]: Leaving directory > > > > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > > make[1]: *** [Makefile:38608: > > all-recursive] Error 1 > > make[1]: Leaving directory > > > > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > > make: *** [Makefile:10337: all] Error 2 > > > > > ******************************************************************* > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>> <mailto:[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>>> > > To manage subscription options or > unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > < > https://lists.mpich.org/mailman/listinfo/discuss> > > > > <https://lists.mpich.org/mailman/listinfo/discuss > > < > https://lists.mpich.org/mailman/listinfo/discuss>> > > > > > > > > > > -- Jeff Hammond > > jeff.science(a)gmail.com <mailto:[email protected]> > > <mailto:[email protected] <mailto: > jeff.science(a)gmail.com>> > > <mailto:[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] <mailto: > jeff.science(a)gmail.com>>> > > http://jeffhammond.github.io/ > > > > > > _______________________________________________ > > discuss mailing listdiscuss(a)mpich.org > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > < > https://lists.mpich.org/mailman/listinfo/discuss> > > > > > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com <mailto:[email protected]> > > <mailto:[email protected] <mailto: > jeff.science(a)gmail.com>> > > http://jeffhammond.github.io/ > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > <mailto:[email protected]> > > 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/ > > > > -- > > 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 > -- 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] MPICH 3.2.1 build error with icc+ifort: undefined reference to `_Static_assert'
by Gus Correa 14 Jun '18

14 Jun '18

Hi Jeff This is actually to compile a Fortran90 program, which uses MPI and another library (netCDF) through Fortran modules (use MPI, use netcdf). The code doesn't compile under gfortran, only with ifort. Optimization and efficiency is not the top priority, if we can get the code to compile and run that is fine. Since Fortran modules are compiler-dependent, I need to build MPICH (and netCDF) with the Intel compilers. I have done this for a variety of compilers and compiler versions for our clusters (before Infiniband with MPICH, then with Open MPI), but this turn it is for a single workstation, hence MPICH is a good fit. That Fortran90 modules are compiler-dependent really sucks, and is the negation of software inter-operability and portability. It may serve well the compiler vendors, but for users it is just a pain. Anyway, your suggestion to tweak with that include file worked, and I could build MPICH 3.2.1 with the archaic Intel 2012. Many thanks! Gus Correa On 06/13/2018 11:34 PM, Jeff Hammond wrote: > I don’t know for sure, but I’d guess that GCC 8 or Clang 6 optimizes > better than ICC 12 and the likelihood goes up the newer the hardware. > Intel people contribute to the OSS compilers, particularly when it comes > to architecture-specific optimizations. > > Jeff > > On Wed, Jun 13, 2018 at 5:02 PM Jeff Hammond <jeff.science(a)gmail.com > <mailto:[email protected]>> wrote: > > On Wed, Jun 13, 2018 at 4:44 PM, Gus Correa <gus(a)ldeo.columbia.edu > <mailto:[email protected]>> wrote: > > > > On 06/13/2018 07:36 PM, Jeff Hammond wrote: > > Why don't you just use a newer ICC? September 28, 2012 was > a long time ago... > > > Jeff > > The cost of a new license. :( > > > Do any of the options on > https://software.intel.com/en-us/qualify-for-free-software work for you? > > It is temporary, but you can get Intel 19 beta for free > (https://software.intel.com/en-us/articles/intel-parallel-studio-xe-2019-beta) > > What code are you developing? > > Jeff > > > On Wed, Jun 13, 2018 at 4:32 PM, Gus Correa > <gus(a)ldeo.columbia.edu <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > Thank you Jeff and Min! > > Would you know if MPICH 3.2 has the same issue? > I would rather use an older version instead, as long as > it builds. > > Many thanks, > Gus Correa > > On 06/13/2018 06:34 PM, Min Si wrote: > > I was just creating the issue on MPICH github when > Jeff replied. > > Please use this issue to keep track: > https://github.com/pmodels/mpich/issues/3178 > <https://github.com/pmodels/mpich/issues/3178> > > Min > On 2018/06/13 15:19, Jeff Hammond wrote: > > _Static_assert comes from C11. > > src/include/mpir_assert.h does a direct test > for C11 support > based upon the GCC version, which is unsafe > since ICC (and > other non-GCC compilers) define these macros. > > /* GCC 4.6 added support for _Static_assert: > * http://gcc.gnu.org/gcc-4.6/changes.html > <http://gcc.gnu.org/gcc-4.6/changes.html> */ > #if (__GNUC__ > 4 || (__GNUC__ == 4 && > __GNUC_MINOR__ >= 6)) > && !defined __cplusplus > #define HAVE_C11__STATIC_ASSERT 1 > #endif > > MPICH needs to test for _Static_assert properly > using > configure. You should file a GitHub issue to > track this. > > Jeff > > On Wed, Jun 13, 2018 at 2:33 PM, Gus Correa > <gus(a)ldeo.columbia.edu > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > > Hi MPICH experts > > I am trying to build MPICH 3.2.1 with Intel > compilers (icc, ifort). > C++ is disabled. > > The configuration step goes well, > but make fails, > after a lot of stuff is compiled, > with the error below (undefined reference to > `_Static_assert'). > > FYI, the OS is Linux Fedora Core 26: > > Linux 4.15.17-200.fc26.x86_64 #1 SMP Thu > Apr 12 > 18:28:26 UTC 2018 > x86_64 x86_64 GNU/Linux > > The Intel compiler version is 12.1.6: > ifort (IFORT) 12.1.6 20120928 > icc (ICC) 12.1.6 20120928 > > The Intel compiler environment is set the > standard way > recommended by Intel: > > source /path/to/intel/bin/compilervars.sh > intel64 > > > Any help is appreciated. > Gus Correa > > ****** make errror message > ************************************* > make[2]: Entering directory > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > CCLD src/env/mpivars > > lib/.libs/libmpi.a(lib_libmpi_la-ch3_progress.o): In > function > `MPIDI_CH3I_Shm_send_progress': > > ../src/mpid/ch3/channels/nemesis/src/ch3_progress.c:(.text+0x1ea2): > undefined > reference to `_Static_assert' > > lib/.libs/libmpi.a(lib_libmpi_la-ch3i_eagernoncontig.o): In > function `MPIDI_CH3I_SendNoncontig': > > ../src/mpid/ch3/channels/nemesis/src/ch3i_eagernoncontig.c:(.text+0x1d3): > undefined reference to `_Static_assert' > make[2]: *** [Makefile:19701: > src/env/mpivars] Error 1 > make[2]: Leaving directory > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > make[1]: *** [Makefile:38608: > all-recursive] Error 1 > make[1]: Leaving directory > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > make: *** [Makefile:10337: all] Error 2 > > ******************************************************************* > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss> > > <https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss>> > > > > > -- Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > http://jeffhammond.github.io/ > > > _______________________________________________ > discuss mailing listdiscuss(a)mpich.org > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > http://jeffhammond.github.io/ > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > 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/ > > -- > 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

1 0

Re: [mpich-discuss] MPI_File_read_shared on NFS seems to be slow on multi-node
by Latham, Robert J. 14 Jun '18

14 Jun '18

On Wed, 2017-12-20 at 17:33 +0530, Aboorva Devarajan wrote: > MPI_File_read_shared / MPI_File_write_shared on NFS seems to be very > slow when running on multi-node environment compared to a single node > run. originally detected with the mpich test case (writeshf90) > > Here is a minimal reproducer with MPI_File_read_shared, > https://gist.github.com/AboorvaDevarajan/db4797e02ac71f60384a8254ae28 > 62c8 We don't have a very good opimization for the shared file operations. On a single node, the fcntl() locks are easier to manage. When multiple nodes are involved, the fcntl() locks will be more expensive. Years ago we wrote about an RMA-based data structure (and then MPI-3 made that data structure overkill). Are shared files important to your workload? ==rob > [aboorvad@c712f6n06 io]$ cat hostfile_mpich > c712f6n06:2 > c712f6n07:2 > [aboorvad@c712f6n06 io]$ time mpirun -np 4 --hostfile hostfile_mpich > ./read_shared > real 0m14.709s > user 0m27.703s > sys 0m1.438s > > [aboorvad@c712f6n06 io]$ time mpirun -np 4 ./read_shared > > real 0m0.247s > user 0m0.153s > sys 0m0.616s > > Is it an expected behaviour? If yes, why? > > > Thanks. > _______________________________________________ > 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] MPICH 3.2.1 build error with icc+ifort: undefined reference to `_Static_assert'
by Gus Correa 13 Jun '18

13 Jun '18

Thank you, Jeff! Your suggestion made the whole difference. I tried #define HAVE_C11__STATIC_ASSERT 0 but the error persisted. The remainder of the preprocessor directives seem to check if the macro HAVE_C11__STATIC_ASSERT is defined, not if it is non-zero. Hence, I had to #undef HAVE_C11__STATIC_ASSERT after it is defined. With that the code compiled with my outdated 2012 ifort and icc. Many thanks to you and Min for the help. Gus Correa On 06/13/2018 07:37 PM, Jeff Hammond wrote: > You can also just #define HAVE_C11__STATIC_ASSERT 0 in the > aforementioned header file to override the bad preprocessor test. > > On Wed, Jun 13, 2018 at 4:36 PM, Jeff Hammond <jeff.science(a)gmail.com > <mailto:[email protected]>> wrote: > > Why don't you just use a newer ICC? September 28, 2012 was a long > time ago... > > Jeff > > On Wed, Jun 13, 2018 at 4:32 PM, Gus Correa <gus(a)ldeo.columbia.edu > <mailto:[email protected]>> wrote: > > Thank you Jeff and Min! > > Would you know if MPICH 3.2 has the same issue? > I would rather use an older version instead, as long as it builds. > > Many thanks, > Gus Correa > > On 06/13/2018 06:34 PM, Min Si wrote: > > I was just creating the issue on MPICH github when Jeff replied. > > Please use this issue to keep track: > https://github.com/pmodels/mpich/issues/3178 > <https://github.com/pmodels/mpich/issues/3178> > > Min > On 2018/06/13 15:19, Jeff Hammond wrote: > > _Static_assert comes from C11. > > src/include/mpir_assert.h does a direct test for C11 > support based upon the GCC version, which is unsafe > since ICC (and other non-GCC compilers) define these macros. > > /* GCC 4.6 added support for _Static_assert: > * http://gcc.gnu.org/gcc-4.6/changes.html > <http://gcc.gnu.org/gcc-4.6/changes.html> */ > #if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= > 6)) && !defined __cplusplus > #define HAVE_C11__STATIC_ASSERT 1 > #endif > > MPICH needs to test for _Static_assert properly using > configure. You should file a GitHub issue to track this. > > Jeff > > On Wed, Jun 13, 2018 at 2:33 PM, Gus Correa > <gus(a)ldeo.columbia.edu <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > Hi MPICH experts > > I am trying to build MPICH 3.2.1 with Intel > compilers (icc, ifort). > C++ is disabled. > > The configuration step goes well, > but make fails, > after a lot of stuff is compiled, > with the error below (undefined reference to > `_Static_assert'). > > FYI, the OS is Linux Fedora Core 26: > > Linux 4.15.17-200.fc26.x86_64 #1 SMP Thu Apr 12 > 18:28:26 UTC 2018 > x86_64 x86_64 GNU/Linux > > The Intel compiler version is 12.1.6: > ifort (IFORT) 12.1.6 20120928 > icc (ICC) 12.1.6 20120928 > > The Intel compiler environment is set the standard way > recommended by Intel: > > source /path/to/intel/bin/compilervars.sh intel64 > > > Any help is appreciated. > Gus Correa > > ****** make errror message > ************************************* > make[2]: Entering directory > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > CCLD src/env/mpivars > lib/.libs/libmpi.a(lib_libmpi_la-ch3_progress.o): > In function > `MPIDI_CH3I_Shm_send_progress': > > ../src/mpid/ch3/channels/nemesis/src/ch3_progress.c:(.text+0x1ea2): > undefined > reference to `_Static_assert' > > lib/.libs/libmpi.a(lib_libmpi_la-ch3i_eagernoncontig.o): In > function `MPIDI_CH3I_SendNoncontig': > > ../src/mpid/ch3/channels/nemesis/src/ch3i_eagernoncontig.c:(.text+0x1d3): > undefined reference to `_Static_assert' > make[2]: *** [Makefile:19701: src/env/mpivars] Error 1 > make[2]: Leaving directory > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > make[1]: *** [Makefile:38608: all-recursive] Error 1 > make[1]: Leaving directory > > '/home/sw/mpich/inst/3.2.1/mpich-3.2.1/build_intel-2011.13.367' > make: *** [Makefile:10337: all] Error 2 > > ******************************************************************* > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss> > <https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss>> > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > http://jeffhammond.github.io/ > > > _______________________________________________ > discuss mailing listdiscuss(a)mpich.org > <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > > > -- > 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