- devel - mailman3.cels.anl.gov

Re: [mpich-devel] Deadlock when using MPIX_Grequest interface
by Latham, Robert J. 28 Feb '17

28 Feb '17

On Tue, 2017-02-28 at 17:59 +0000, Giuseppe Congiu wrote: > Hello, > > I am trying to integrate an asynchronous API in ROMIO but I am > experiencing some problems, probably caused by the improper use of > the MPIX_Grequest interface. I'm excited to see someone using the MPIX_Grequest interface. We used the MPIX_Grequest interface to implement non-blocking collective I/O, and had some bad interactions between libc's aio and the grequest callbacks. I don't know if you are running into something similar. > Short description of the integrated functions: > I have a ROMIO implementation with extended MPI-IO hints that can be > used to divert written data, during collective I/O, to a local file > system (typically running on a SSD). The full description of the > modification can be found at this link: > https://github.com/gcongiu/E10/tree/beegfs-devel Do you have any desire or plans to submit these changes into upstream ROMIO? There have been quite a few changes since 3.1.4, particularly for dealing with large transfers. I don't think you're hitting an overflow path here, but it's something I cannot rule out. > The BeeGFS ROMIO driver uses the cache API internally provided by > BeeGFS to move data around, while the custom ROMIO implementation > provides support for any other file system (in the "common" layer). > > Description of the problem: > I am currently having problems making the BeeGFS driver work > properly. More specifically I am noticing that when the size of the > shared file is large (32GB in my configuration) and I am writing > multiple files one after the other (using a custom coll_perf > benchmark) the i-th file (for i > 0 with 0 <= i < 4) gets stuck. > > BeeGFS provides a deeper_cache_flush_range() function to flush data > in the cache to the global file. This is non blocking and will submit > a range (offset, length) for a certain filename to a cache deamon > that transfers the data. Multiple ranges can be submitted one after > the other. > > Completion can be checked using deeper_cache_flush_wait() using the > filename as input. Since the MPI_Grequest model requires the external > thread to make progress by invoking MPI_Grequest_complete() I have > opted for the MPIX_Grequest interface which allows me to make > progress (MPI_Grequest_complete) inside MPI while invoking the > MPI_Wait() function. The original intent of the MPIX_Grequest extensions is that something else (in this case the AIO library) was making progress in the background and all we needed was a way to check if things were done or not. I suspect the callbacks could do some work, but blocking callbacks haven't seen a lot of testing (in 10+ years the extensions themselves haven't seen a lot of activity, either) > > deeper_cache_flush_range() does not require the application to keep > any handler for the submitted request. The only thing the application > needs is the name of the file to pass to deeper_cache_flush_wait(). > > Follows a code snippet for the corresponding non blocking > implementation in ROMIO: > > /* arguments for callback function */ > struct callback { > ADIO_File fd_; > ADIOI_Sync_req_t req_; > }; > > /* > * ADIOI_BEEGFS_Sync_thread_start - start synchronisation of req > */ > int ADIOI_BEEGFS_Sync_thread_start(ADIOI_Sync_thread_t t) { > ADIOI_Atomic_queue_t q = t->sub_; > ADIOI_Sync_req_t r; > int retval, count, fflags, error_code, i; > ADIO_Offset offset, len; > MPI_Count datatype_size; > MPI_Datatype datatype; > ADIO_Request *req; > char myname[] = "ADIOI_BEEGFS_SYNC_THREAD_START"; > > r = ADIOI_Atomic_queue_front(q); > ADIOI_Atomic_queue_pop(q); > > ADIOI_Sync_req_get_key(r, ADIOI_SYNC_ALL, &offset, > &datatype, &count, &req, &error_code, &fflags); > > MPI_Type_size_x(datatype, &datatype_size); > len = (ADIO_Offset)datatype_size * (ADIO_Offset)count; > > retval = deeper_cache_flush_range(t->fd_->filename, > (off_t)offset, (size_t)len, fflags); > > if (retval == DEEPER_RETVAL_SUCCESS && ADIOI_BEEGFS_greq_class == > 1) { > MPIX_Grequest_class_create(ADIOI_BEEGFS_Sync_req_query, > ADIOI_BEEGFS_Sync_req_free, > MPIU_Greq_cancel_fn, > ADIOI_BEEGFS_Sync_req_poll, > ADIOI_BEEGFS_Sync_req_wait, > &ADIOI_BEEGFS_greq_class); > } else { > /* --BEGIN ERROR HANDLING-- */ > return MPIO_Err_create_code(MPI_SUCCESS, > MPIR_ERR_RECOVERABLE, > "ADIOI_BEEGFS_Cache_sync_req", > __LINE__, MPI_ERR_IO, "**io %s", > strerror(errno)); > /* --END ERROR HANDLING-- */ > } > > /* init args for the callback functions */ > struct callback *args = (struct callback > *)ADIOI_Malloc(sizeof(struct callback)); > args->fd_ = t->fd_; > args->req_ = r; > > MPIX_Grequest_class_allocate(ADIOI_BEEGFS_greq_class, args, req); > > return MPI_SUCCESS; > } > > /* > * ADIOI_BEEGFS_Sync_req_poll - > */ > int ADIOI_BEEGFS_Sync_req_poll(void *extra_state, MPI_Status *status) > { > struct callback *cb = (struct callback *)extra_state; > ADIOI_Sync_req_t r = (ADIOI_Sync_req_t)cb->req_; > ADIO_File fd = (ADIO_File)cb->fd_; > char *filename = fd->filename; > int count, cache_flush_flags, error_code; > MPI_Datatype datatype; > ADIO_Offset offset; > MPI_Aint lb, extent; > ADIO_Offset len; > ADIO_Request *req; > > ADIOI_Sync_req_get_key(r, ADIOI_SYNC_ALL, &offset, > &datatype, &count, &req, &error_code, &cache_flush_flags); > > int retval = deeper_cache_flush_wait(filename, > cache_flush_flags); > > MPI_Type_get_extent(datatype, &lb, &extent); > len = (ADIO_Offset)extent * (ADIO_Offset)count; > > if (fd->hints->e10_cache_coherent == ADIOI_HINT_ENABLE) > ADIOI_UNLOCK(fd, offset, SEEK_SET, len); > > /* mark generilized request as completed */ > MPI_Grequest_complete(*req); > > if (retval != DEEPER_RETVAL_SUCCESS) > goto fn_exit_error; > > MPI_Status_set_cancelled(status, 0); > MPI_Status_set_elements(status, datatype, count); > status->MPI_SOURCE = MPI_UNDEFINED; > status->MPI_TAG = MPI_UNDEFINED; > > ADIOI_Free(cb); > > return MPI_SUCCESS; > > fn_exit_error: > ADIOI_Free(cb); > > return MPIO_Err_create_code(MPI_SUCCESS, > MPIR_ERR_RECOVERABLE, > "ADIOI_BEEGFS_Sync_req_poll", > __LINE__, MPI_ERR_IO, "**io %s", > strerror(errno)); > } > > /* > * ADIOI_BEEGFS_Sync_req_wait - > */ > int ADIOI_BEEGFS_Sync_req_wait(int count, void **array_of_states, > double timeout, MPI_Status *status) { > return ADIOI_BEEGFS_Sync_req_poll(*array_of_states, status); > } > > /* > * ADIOI_BEEGFS_Sync_req_query - > */ > int ADIOI_BEEGFS_Sync_req_query(void *extra_state, MPI_Status > *status) { > return MPI_SUCCESS; > } > > /* > * ADIOI_BEEGFS_Sync_req_free - > */ > int ADIOI_BEEGFS_Sync_req_free(void *extra_state) { > return MPI_SUCCESS; > } > > /* > * ADIOI_BEEGFS_Sync_req_cancel - > */ > int ADIOI_BEEGFS_Sync_req_cancel(void *extra_state, int complete) { > return MPI_SUCCESS; > } > > I have had a look at the implementation for MPI_File_iwrite() in > ad_iwrite.c but this uses POSIX AIO, thus I am not sure I am doing > things properly here. the poll_fn() should be non-blocking. think MPI_Test more than unix poll/select/epoll. it's going to get called in a tight loop. Can you provide a stack trace for some of the stuck processes? > Additionally the problem does not show for small files (e.g. 1GB), > which makes it not easy to debug. > > BTW, I am using weak scaling thus every process always writes the > same amount of data (64MB), I just change the number of procs in the > test. > > To test the modification with coll_perf I am using a configuration > with 512 procs (64 nodes, 8procs/node) and 16 procs (8 nodes, > 2procs/node). > > The 16 procs configuration writes 4 files of 1GB (16 x 64MB), the 512 > procs configuration writes 4 files of 32GB (512 x 64MB). > > Can someone spot any problem in my code? Might take a few rounds but I'm sure we'll figure it out! ==rob > > Thanks, > > -- > Giuseppe Congiu · Research Engineer II > Seagate Technology, LLC > office: +44 (0)23 9249 6082 · mobile: > www.seagate.com > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Deadlock when using MPIX_Grequest interface
by Giuseppe Congiu 28 Feb '17

28 Feb '17

Hello, I am trying to integrate an asynchronous API in ROMIO but I am experiencing some problems, probably caused by the improper use of the MPIX_Grequest interface. Short description of the integrated functions: I have a ROMIO implementation with extended MPI-IO hints that can be used to divert written data, during collective I/O, to a local file system (typically running on a SSD). The full description of the modification can be found at this link: https://github.com/gcongiu/E10/tree/beegfs-devel The BeeGFS ROMIO driver uses the cache API internally provided by BeeGFS to move data around, while the custom ROMIO implementation provides support for any other file system (in the "common" layer). Description of the problem: I am currently having problems making the BeeGFS driver work properly. More specifically I am noticing that when the size of the shared file is large (32GB in my configuration) and I am writing multiple files one after the other (using a custom coll_perf benchmark) the i-th file (for i > 0 with 0 <= i < 4) gets stuck. BeeGFS provides a deeper_cache_flush_range() function to flush data in the cache to the global file. This is non blocking and will submit a range (offset, length) for a certain filename to a cache deamon that transfers the data. Multiple ranges can be submitted one after the other. Completion can be checked using deeper_cache_flush_wait() using the filename as input. Since the MPI_Grequest model requires the external thread to make progress by invoking MPI_Grequest_complete() I have opted for the MPIX_Grequest interface which allows me to make progress (MPI_Grequest_complete) inside MPI while invoking the MPI_Wait() function. deeper_cache_flush_range() does not require the application to keep any handler for the submitted request. The only thing the application needs is the name of the file to pass to deeper_cache_flush_wait(). Follows a code snippet for the corresponding non blocking implementation in ROMIO: /* arguments for callback function */ struct callback { ADIO_File fd_; ADIOI_Sync_req_t req_; }; /* * ADIOI_BEEGFS_Sync_thread_start - start synchronisation of req */ int ADIOI_BEEGFS_Sync_thread_start(ADIOI_Sync_thread_t t) { ADIOI_Atomic_queue_t q = t->sub_; ADIOI_Sync_req_t r; int retval, count, fflags, error_code, i; ADIO_Offset offset, len; MPI_Count datatype_size; MPI_Datatype datatype; ADIO_Request *req; char myname[] = "ADIOI_BEEGFS_SYNC_THREAD_START"; r = ADIOI_Atomic_queue_front(q); ADIOI_Atomic_queue_pop(q); ADIOI_Sync_req_get_key(r, ADIOI_SYNC_ALL, &offset, &datatype, &count, &req, &error_code, &fflags); MPI_Type_size_x(datatype, &datatype_size); len = (ADIO_Offset)datatype_size * (ADIO_Offset)count; retval = deeper_cache_flush_range(t->fd_->filename, (off_t)offset, (size_t)len, fflags); if (retval == DEEPER_RETVAL_SUCCESS && ADIOI_BEEGFS_greq_class == 1) { MPIX_Grequest_class_create(ADIOI_BEEGFS_Sync_req_query, ADIOI_BEEGFS_Sync_req_free, MPIU_Greq_cancel_fn, ADIOI_BEEGFS_Sync_req_poll, ADIOI_BEEGFS_Sync_req_wait, &ADIOI_BEEGFS_greq_class); } else { /* --BEGIN ERROR HANDLING-- */ return MPIO_Err_create_code(MPI_SUCCESS, MPIR_ERR_RECOVERABLE, "ADIOI_BEEGFS_Cache_sync_req", __LINE__, MPI_ERR_IO, "**io %s", strerror(errno)); /* --END ERROR HANDLING-- */ } /* init args for the callback functions */ struct callback *args = (struct callback *)ADIOI_Malloc(sizeof(struct callback)); args->fd_ = t->fd_; args->req_ = r; MPIX_Grequest_class_allocate(ADIOI_BEEGFS_greq_class, args, req); return MPI_SUCCESS; } /* * ADIOI_BEEGFS_Sync_req_poll - */ int ADIOI_BEEGFS_Sync_req_poll(void *extra_state, MPI_Status *status) { struct callback *cb = (struct callback *)extra_state; ADIOI_Sync_req_t r = (ADIOI_Sync_req_t)cb->req_; ADIO_File fd = (ADIO_File)cb->fd_; char *filename = fd->filename; int count, cache_flush_flags, error_code; MPI_Datatype datatype; ADIO_Offset offset; MPI_Aint lb, extent; ADIO_Offset len; ADIO_Request *req; ADIOI_Sync_req_get_key(r, ADIOI_SYNC_ALL, &offset, &datatype, &count, &req, &error_code, &cache_flush_flags); int retval = deeper_cache_flush_wait(filename, cache_flush_flags); MPI_Type_get_extent(datatype, &lb, &extent); len = (ADIO_Offset)extent * (ADIO_Offset)count; if (fd->hints->e10_cache_coherent == ADIOI_HINT_ENABLE) ADIOI_UNLOCK(fd, offset, SEEK_SET, len); /* mark generilized request as completed */ MPI_Grequest_complete(*req); if (retval != DEEPER_RETVAL_SUCCESS) goto fn_exit_error; MPI_Status_set_cancelled(status, 0); MPI_Status_set_elements(status, datatype, count); status->MPI_SOURCE = MPI_UNDEFINED; status->MPI_TAG = MPI_UNDEFINED; ADIOI_Free(cb); return MPI_SUCCESS; fn_exit_error: ADIOI_Free(cb); return MPIO_Err_create_code(MPI_SUCCESS, MPIR_ERR_RECOVERABLE, "ADIOI_BEEGFS_Sync_req_poll", __LINE__, MPI_ERR_IO, "**io %s", strerror(errno)); } /* * ADIOI_BEEGFS_Sync_req_wait - */ int ADIOI_BEEGFS_Sync_req_wait(int count, void **array_of_states, double timeout, MPI_Status *status) { return ADIOI_BEEGFS_Sync_req_poll(*array_of_states, status); } /* * ADIOI_BEEGFS_Sync_req_query - */ int ADIOI_BEEGFS_Sync_req_query(void *extra_state, MPI_Status *status) { return MPI_SUCCESS; } /* * ADIOI_BEEGFS_Sync_req_free - */ int ADIOI_BEEGFS_Sync_req_free(void *extra_state) { return MPI_SUCCESS; } /* * ADIOI_BEEGFS_Sync_req_cancel - */ int ADIOI_BEEGFS_Sync_req_cancel(void *extra_state, int complete) { return MPI_SUCCESS; } I have had a look at the implementation for MPI_File_iwrite() in ad_iwrite.c but this uses POSIX AIO, thus I am not sure I am doing things properly here. Additionally the problem does not show for small files (e.g. 1GB), which makes it not easy to debug. BTW, I am using weak scaling thus every process always writes the same amount of data (64MB), I just change the number of procs in the test. To test the modification with coll_perf I am using a configuration with 512 procs (64 nodes, 8procs/node) and 16 procs (8 nodes, 2procs/node). The 16 procs configuration writes 4 files of 1GB (16 x 64MB), the 512 procs configuration writes 4 files of 32GB (512 x 64MB). Can someone spot any problem in my code? Thanks, -- Giuseppe Congiu *·* Research Engineer II Seagate Technology, LLC office: +44 (0)23 9249 6082 *·* mobile: www.seagate.com

1 0

how do I use mpich in ARM
by 崔宁 10 Feb '17

10 Feb '17

hi,support: I want use mpich in ARM, present,how do I use mpich in ARM? thanks cui

1 0

MPICH on WSL
by Jeff Hammond 16 Jan '17

16 Jan '17

I was unable to make progress with WSL (Windows Subsystem for Linux) because of firewall issues and the lame networking stack (see https://github.com/Microsoft/BashOnWindows/issues for a sampling) but someone else said they could apt-get MPICH 3.2 without issue. I'd love to verify but I do not have a computer with enough space for a Win10 VM that isn't behind a firewall. Hopefully someone else can verify and document for MPICH FAQ. Jeff Sent from my iPhone Begin forwarded message: > FYI, opencoarrays build and pass all tests on my WSL. This is true for both the master trunk (bb1b8ee) and the 1.8.2 release. I don't use install.sh, I install all dependencies via apt-get and do cmake .. && make && ctest. > I noticed Damian's issue here and a few folks on comp.lang.fortran reporting that they get gcc-4.x in WSL out of the box. I am wondering whether there are multiple branches of WSL because I had gcc-5.4.0 out of the box since I enabled WSL for the first time. It may be important that I am on their Windows Insider Preview update cycle (current build is 14986.rs_prerelease.161202-1928). > > The versions of dependencies (all obtained via apt-get install) are: > > automake-1.15 > bison-3.0.4 > flex-2.6.0 > cmake-3.5.1 > make-4.1 > gcc-5.4.0 > mpich-3.2 > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub >

1 0

Re: [mpich-devel] Developing MPI program without mpirun
by Bland, Wesley 21 Nov '16

21 Nov '16

If you want to make notes on that issue, you'll need to go to the new GitHub link (same number, different URL): https://github.com/pmodels/mpich/issues/1074. On Nov 20, 2016, at 8:23 PM, Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: See https://trac.mpich.org/projects/mpich/ticket/1074 and http://lists.mpich.org/pipermail/devel/2016-July/000717.html. Best, Jeff Sent from my iPhone On Nov 20, 2016, at 5:55 PM, Rui Liu <liur(a)comp.nus.edu.sg<mailto:[email protected]>> wrote: Hi folks, I am working on a simple client/server program but I don’t want to use mpirun/mpiexec to start the program (In nature, I just want to adopt MPI API into my own project but cannot start it using mpirun). I mostly followed the singleton mode of MPI, using APIs like MPI_Open_port, MPI_Comm_connect, and MPI_Comm_accept. But it doesn’t work. The error info is presented as following, [mpiexec@ciidaa-a01] match_arg (utils/args/args.c:159): unrecognized argument pmi_args [mpiexec@ciidaa-a01] HYDU_parse_array (utils/args/args.c:174): argument matching returned error [mpiexec@ciidaa-a01] parse_args (ui/mpich/utils.c:1596): error parsing input array [mpiexec@ciidaa-a01] HYD_uii_mpx_get_parameters (ui/mpich/utils.c:1648): unable to parse user arguments [mpiexec@ciidaa-a01] main (ui/mpich/mpiexec.c:153): error parsing parameters Anyone knows how to achieve that? I attach my server and client key source code for your reference. server side: char myport[MPI_MAX_PORT_NAME]; MPI_Open_port(MPI_INFO_NULL, myport); cout << myport << endl; (assume myport is tag#0$description#ciidaa-a01$port#52985$ifname#10.10.10.1$, it always return string like this) MPI_Comm_accept(myport, MPI_INFO_NULL, 0, MPI_COMM_WORLD, &client); MPI_Recv(&number, 1, MPI_INT, MPI_ANY_SOURCE, MPI_ANY_TAG, client, &status); client side: char name[] = "tag#0$description#ciidaa-a01$port#52985$ifname#10.10.10.1$"; MPI_Comm_connect(name, MPI_INFO_NULL, 0, MPI_COMM_WORLD, &server); int number = -1 ; MPI_Send(&number, 1, MPI_INT, 0, 0, server); Best, Rui _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] Developing MPI program without mpirun
by Jeff Hammond 20 Nov '16

20 Nov '16

See https://trac.mpich.org/projects/mpich/ticket/1074 and http://lists.mpich.org/pipermail/devel/2016-July/000717.html. Best, Jeff Sent from my iPhone > On Nov 20, 2016, at 5:55 PM, Rui Liu <liur(a)comp.nus.edu.sg> wrote: > > Hi folks, > > I am working on a simple client/server program but I don’t want to use mpirun/mpiexec to start the program (In nature, I just want to adopt MPI API into my own project but cannot start it using mpirun). I mostly followed the singleton mode of MPI, using APIs like MPI_Open_port, MPI_Comm_connect, and MPI_Comm_accept. But it doesn’t work. The error info is presented as following, > > [mpiexec@ciidaa-a01] match_arg (utils/args/args.c:159): unrecognized argument pmi_args > [mpiexec@ciidaa-a01] HYDU_parse_array (utils/args/args.c:174): argument matching returned error > [mpiexec@ciidaa-a01] parse_args (ui/mpich/utils.c:1596): error parsing input array > [mpiexec@ciidaa-a01] HYD_uii_mpx_get_parameters (ui/mpich/utils.c:1648): unable to parse user arguments > [mpiexec@ciidaa-a01] main (ui/mpich/mpiexec.c:153): error parsing parameters > > Anyone knows how to achieve that? I attach my server and client key source code for your reference. > > server side: > > char myport[MPI_MAX_PORT_NAME]; > MPI_Open_port(MPI_INFO_NULL, myport); > cout << myport << endl; (assume myport is tag#0$description#ciidaa-a01$port#52985$ifname#10.10.10.1$, it always return string like this) > MPI_Comm_accept(myport, MPI_INFO_NULL, 0, MPI_COMM_WORLD, &client); > MPI_Recv(&number, 1, MPI_INT, MPI_ANY_SOURCE, MPI_ANY_TAG, client, &status); > > > client side: > > char name[] = "tag#0$description#ciidaa-a01$port#52985$ifname#10.10.10.1$"; > MPI_Comm_connect(name, MPI_INFO_NULL, 0, MPI_COMM_WORLD, &server); > int number = -1 ; > MPI_Send(&number, 1, MPI_INT, 0, 0, server); > > > Best, > Rui > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Developing MPI program without mpirun
by Rui Liu 20 Nov '16

20 Nov '16

Hi folks, I am working on a simple client/server program but I don’t want to use mpirun/mpiexec to start the program (In nature, I just want to adopt MPI API into my own project but cannot start it using mpirun). I mostly followed the singleton mode of MPI, using APIs like MPI_Open_port, MPI_Comm_connect, and MPI_Comm_accept. But it doesn’t work. The error info is presented as following, [mpiexec@ciidaa-a01] match_arg (utils/args/args.c:159): unrecognized argument pmi_args [mpiexec@ciidaa-a01] HYDU_parse_array (utils/args/args.c:174): argument matching returned error [mpiexec@ciidaa-a01] parse_args (ui/mpich/utils.c:1596): error parsing input array [mpiexec@ciidaa-a01] HYD_uii_mpx_get_parameters (ui/mpich/utils.c:1648): unable to parse user arguments [mpiexec@ciidaa-a01] main (ui/mpich/mpiexec.c:153): error parsing parameters Anyone knows how to achieve that? I attach my server and client key source code for your reference. server side: char myport[MPI_MAX_PORT_NAME]; MPI_Open_port(MPI_INFO_NULL, myport); cout << myport << endl; (assume myport is tag#0$description#ciidaa-a01$port#52985$ifname#10.10.10.1$, it always return string like this) MPI_Comm_accept(myport, MPI_INFO_NULL, 0, MPI_COMM_WORLD, &client); MPI_Recv(&number, 1, MPI_INT, MPI_ANY_SOURCE, MPI_ANY_TAG, client, &status); client side: char name[] = "tag#0$description#ciidaa-a01$port#52985$ifname#10.10.10.1$"; MPI_Comm_connect(name, MPI_INFO_NULL, 0, MPI_COMM_WORLD, &server); int number = -1 ; MPI_Send(&number, 1, MPI_INT, 0, 0, server); Best, Rui

1 0

Meet Us at SC '16
by Kenneth Raffenetti 10 Nov '16

10 Nov '16

The link below shows events where the MPICH team will be present at SC '16. https://www.mpich.org/2016/10/25/meet-us-at-sc-16/ Come and say hi!

1 0

move to GitHub
by Kenneth Raffenetti 17 Oct '16

17 Oct '16

Hi folks, MPICH has moved to GitHub! http://github.com/pmodels/mpich Come check us out at the new location. We have imported all existing tickets from our old bug tracker as GitHub issues. New bugs (and pull requests) can be submitted directly to GitHub repo. The old MPICH git repositories at git.mpich.org are still available, and will be kept in sync with the official master branch. This may change in the future as we evaluate their utility. Please contact me if you have any questions at this time. Our developer wiki (http://wiki.mpich.org) will be updating over the coming weeks with new information, so feel free to point out any mistakes, omissions, etc. Thanks and enjoy! Ken

1 0

symbol visibility
by Kenneth Raffenetti 07 Sep '16

07 Sep '16

Hi folks, We are considering adding support for symbol visibility into MPICH. This is a standard shared library best-practice that reduces the exposed API, and leads to better performance by reducing the number of PLT branches for internal function calls. More on symbol visibility can be found here: https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Sh…. I wanted to get the patches in front of a wider audience so folks are aware of what we are doing and can comment. You can find the current implementation here: http://git.mpich.org/mpich-dev.git/shortlog/refs/heads/visibility. Thanks to Intel for pointing out the need for this, and an initial version of the patch. We believe this will have no impact on the MPICH ABI, and will test thoroughly once the patches land in master. Let us know what you think. Ken

1 0