[OMPI devel] RFC: libopen-rte --> libompi-rte
WHAT: Rename libopen-rte to be libompi-rte (and probably other supporting text) WHY: ORTE is really quite specific to OMPI. We decided long ago that ORTE would not split off from OMPI, and it has been specifically tailored for OMPI. Indeed, Ralph has recently been expanding "ORTE" to "OMPI Run Time Environment". So let's name the library what it really is. WHERE: See attached patch; basically, a bunch of Makefile.am's WHEN: Before v1.3 TIMEOUT: Teleconference, Tues 11 Nov 2008 -- The change is fairly minor, and 98% of OMPI users won't notice. Only those who are not using wrapper compilers properly will notice the change (and they should be using the wrapper compilers; we strongly recommended that everyone either directly use the wrapper compilers to compile/link their apps, or use the wrappers to get the required flags [including library names] to compile/link their apps). I don't know if Sun has any policies about library name changes between versions, or if it'll create problems since CT8 has already been released. As a history note, we changed this library name in v1.2 from "liborte" to "libopen-rte". This would be another change. -- Jeff Squyres Cisco Systems libompi-rte.patch Description: Binary data
[OMPI devel] Progress of the asynchronous messages
I am new user of Open MPI, I've used MPICH before.
I've tried on the user list but they couldn't help me.
There is performance bug with the following scenario:
proc_B: MPI_Isend(...,proc_A,..,&request)
do{
sleep(1);
MPI_Test(..,&flag,&request);
count++
}while(!flag);
proc_A: MPI_Recv(...,proc_B);
For message size 8MB, proc_B calls MPI_Test 88 times. It means that
point to point communication costs 88 seconds.
Btw, bandwidth isn't the problem (interconnection network: InfiniBand)
Obviously, there is the problem with progress of the asynchronous
messages. In order to overlap communication and computation I don't want to use
MPI_Wait. Probably, the message is being decomposed into chucks and the
size of chuck is probably defined by environment variable.
How can I advance the message more aggressively or can I control size of chunk?
Thank you very much
Vladimir
Re: [OMPI devel] RFC: libopen-rte --> libompi-rte
On Thu, 6 Nov 2008, Jeff Squyres wrote: WHAT: Rename libopen-rte to be libompi-rte (and probably other supporting text) WHY: ORTE is really quite specific to OMPI. We decided long ago that ORTE would not split off from OMPI, and it has been specifically tailored for OMPI. Indeed, Ralph has recently been expanding "ORTE" to "OMPI Run Time Environment". So let's name the library what it really is. Does it really hurt anything to leave the name as is? I know you love wrapper compilers, but there are a significant number of people who can't use them for one reason or another (like my case, krufty Makefiles I don't have control over). It seems like there's almost no upside, and a significant downside for others. Brian
Re: [OMPI devel] RFC: libopen-rte --> libompi-rte
On Nov 6, 2008, at 1:13 PM, Brian W. Barrett wrote: WHY: ORTE is really quite specific to OMPI. We decided long ago that ORTE would not split off from OMPI, and it has been specifically tailored for OMPI. Indeed, Ralph has recently been expanding "ORTE" to "OMPI Run Time Environment". So let's name the library what it really is. Does it really hurt anything to leave the name as is? I know you love wrapper compilers, but there are a significant number of people who can't use them for one reason or another (like my case, krufty Makefiles I don't have control over). It seems like there's almost no upside, and a significant downside for others. I understand that some people can't use wrappers, but we added the -- showme options just for these kinds of scenarios. I had thought that that was sufficient -- are you saying that it's not? -- Jeff Squyres Cisco Systems
Re: [OMPI devel] RFC: libopen-rte --> libompi-rte
Hello, * Jeff Squyres wrote on Thu, Nov 06, 2008 at 07:49:23PM CET: > On Nov 6, 2008, at 1:13 PM, Brian W. Barrett wrote: > >>> WHY: ORTE is really quite specific to OMPI. We decided long ago >>> that ORTE would not split off from OMPI, and it has been >>> specifically tailored for OMPI. Indeed, Ralph has recently been >>> expanding "ORTE" to "OMPI Run Time Environment". So let's name the >>> library what it really is. >> >> Does it really hurt anything to leave the name as is? > I understand that some people can't use wrappers, but we added the -- > showme options just for these kinds of scenarios. I had thought that > that was sufficient -- are you saying that it's not? Changing the library name is an incompatible change for all programs and libraries that are linked against it; i.e., it requires relinking. Hmm, OpenMPI seems not to use versioning for its shared libraries. Do you just declare each release API+ABI-incompatible to each other release? Cheers, Ralf
Re: [OMPI devel] RFC: libopen-rte --> libompi-rte
On Nov 6, 2008, at 2:42 PM, Ralf Wildenhues wrote: Changing the library name is an incompatible change for all programs and libraries that are linked against it; i.e., it requires relinking. Agreed. Hmm, OpenMPI seems not to use versioning for its shared libraries. That was on the to-do list for this release, but it just didn't happen. :-\ Do you just declare each release API+ABI-incompatible to each other release? MPI API is compatible across releases; it hasn't changed. We have never [yet] claimed ABI compatible across releases -- we may still do this someday. -- Jeff Squyres Cisco Systems
Re: [OMPI devel] RFC: libopen-rte --> libompi-rte
* Jeff Squyres wrote on Thu, Nov 06, 2008 at 08:48:44PM CET: > On Nov 6, 2008, at 2:42 PM, Ralf Wildenhues wrote: > >> Hmm, OpenMPI seems not to use versioning for its shared libraries. > > That was on the to-do list for this release, but it just didn't happen. > :-\ Oh well. When you start doing it, please coordinate with distributors; it's not likely, but some of them may have actually packaged OpenMPI with versioning, including (one then hopes!) adjusting versions as needed between releases. You might want to start out with numbers upward of that then. (I've seen Debian do this before. AFAIK they haven't for OpenMPI, though.) >> Do you just declare each release API+ABI-incompatible to each other >> release? > > MPI API is compatible across releases; it hasn't changed. We have never > [yet] claimed ABI compatible across releases -- we may still do this > someday. FWIW, this task looks quite a bit easier to me than, say, defining an ABI valid for several MPI implementations. Cheers, Ralf
Re: [OMPI devel] Progress of the asynchronous messages
For the web archives: this same question was posted and answered on
the users list. See this thread:
http://www.open-mpi.org/community/lists/users/2008/11/7222.php
On Nov 6, 2008, at 1:00 PM, vladimir marjanovic wrote:
I am new user of Open MPI, I've used MPICH before.
I've tried on the user list but they couldn't help me.
There is performance bug with the following scenario:
proc_B: MPI_Isend(...,proc_A,..,&request)
do{
sleep(1);
MPI_Test(..,&flag,&request);
count++
}while(!flag);
proc_A: MPI_Recv(...,proc_B);
For message size 8MB, proc_B calls MPI_Test 88 times. It means
that point to point communication costs 88 seconds.
Btw, bandwidth isn't the problem (interconnection network:
InfiniBand)
Obviously, there is the problem with progress of the asynchronous
messages. In order to overlap communication and computation I
don't want to use MPI_Wait. Probably, the message is being
decomposed into chucks and the size of chuck is probably defined by
environment variable.
How can I advance the message more aggressively or can I control
size of chunk?
Thank you very much
Vladimir
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
Re: [OMPI devel] RFC: libopen-rte --> libompi-rte
FWIW: Terry told me in IM that he hates this RFC as well (more details coming later). On Nov 6, 2008, at 2:58 PM, Ralf Wildenhues wrote: Hmm, OpenMPI seems not to use versioning for its shared libraries. That was on the to-do list for this release, but it just didn't happen. :-\ Oh well. When you start doing it, please coordinate with distributors; it's not likely, but some of them may have actually packaged OpenMPI with versioning, including (one then hopes!) adjusting versions as needed between releases. You might want to start out with numbers upward of that then. Will do; thanks for the tip. MPI API is compatible across releases; it hasn't changed. We have never [yet] claimed ABI compatible across releases -- we may still do this someday. FWIW, this task looks quite a bit easier to me than, say, defining an ABI valid for several MPI implementations. Yes; our biggest issue is the fact that gcc complains when the size of structs change, even though those structs are never exposed to MPI applications. Specifically: 1. MPI_Comm is defined as "typedef struct ompi_communicator_t *MPI_Comm" 2. If we change the size of the ompi_communicator_t struct between two different versions of libmpi, gcc warns when user MPI applications are linked against a new libmpi Everything seems to work since MPI_Comm is only ever used as an opaque handle by the MPI application. But we haven't looked deeply [yet] to see if there are more hidden dragons than this, and if not, if there is a way to suppress the warning. -- Jeff Squyres Cisco Systems
