Re: [O-MPI devel] why do we need the backward dependencies ?
Hi George, Andrew, * Andrew Friedley wrote on Thu, Sep 22, 2005 at 09:09:11PM CEST: > I'm going to take a stab at this, though Jeff should be the definitive > authority on how this all works. Yes. FWIW, I believe you summarized it quite well. > On Sep 22, 2005, at 12:56 PM, George Bosilca wrote: > > > > Now we get this message for all .so file we generate: > > libtool: install: warning: relinking `*.la' The warning message itself is mostly harmless. If you encounter any troubles with the relinking step, don't hesitate to report them. Libtool does the relinking so the rpaths point correctly to the installed libraries. Cheers, Ralf
Re: [O-MPI devel] why do we need the backward dependencies ?
Andrew, * Ralf Wildenhues wrote on Fri, Sep 23, 2005 at 10:42:34AM CEST: > * Andrew Friedley wrote on Thu, Sep 22, 2005 at 09:09:11PM CEST: > > On Sep 22, 2005, at 12:56 PM, George Bosilca wrote: > > > > > > Now we get this message for all .so file we generate: > > > libtool: install: warning: relinking `*.la' I think I found a small error in the patch, see proposed fix below. Cheers, Ralf Index: opal/mca/memory/malloc_interpose/Makefile.am === --- opal/mca/memory/malloc_interpose/Makefile.am(revision 7493) +++ opal/mca/memory/malloc_interpose/Makefile.am(working copy) @@ -22,6 +22,5 @@ libmca_memory_malloc_interpose_la_SOURCES = \ memory_malloc_interpose.c libmca_memory_malloc_interpose_la_LIBADD = \ - $(memory_malloc_interpose_LIBS) \ - $(top_ompi_builddir)/opal/libopal.la + $(memory_malloc_interpose_LIBS)
[O-MPI devel] mca selection
Short version:
--
I'd like to have a single, top-level MCA param for each framework that
controls the "include" and "exclude" behavior of components. Something
like:
mpirun --mca btl self,mvapi ...
would "include" self, mvapi (this actually already works for dynamic
compiles). And:
mpirun --mca btl !tcp
would "exclude" tcp. This would be for all frameworks, at the
mca_base_components_open() level, not during framework-specific
selection. Hence, excluded / not-included components wouldn't even be
opened (i.e., faster startup and smaller memory footprint).
Longer version:
---
Long, long ago, before Tim knew that I put in the MCA
params into mca_base_components_open(), he added btl_base_include and
btl_base_exclude to handle this kind of thing. I think that this
should be handled at the MCA level itself -- there should be no need to
have this kind of exclusion and inclusion at each framework.
More specifically, the frameworks can call mca_base_components_open()
just as they do now, and if the MCA parameter for that framework was
specified, mca_base_components_open() will obey it and pass back a
customized list of components back to the caller. The
btl_base_[include|exclude] parameters (and others similar to it) can
then be removed.
Given that I already am on the hook to fix the static compile issue for
1.0, adding this functionality would be pretty trivial. Therefore, I'd
like to do it for 1.0. It would also give us a nice, uniform way of
including components across all frameworks.
It's also shorter to type on the command line. :-)
Comments?
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
Re: [O-MPI devel] why do we need the backward dependencies ?
On Sep 23, 2005, at 6:18 AM, Ralf Wildenhues wrote:
I think I found a small error in the patch, see proposed fix below.
Yep, this showed up in the nightlies as well.
The issue here is that this component is *always* built statically, and
is therefore part of libopal itself (and therefore can't link to it,
because it doesn't exist yet).
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
Re: [O-MPI devel] --with-mvapi/--with-btl-mvapi???
Fixed.
Sorry -- didn't know that this was still a problem.
On Sep 21, 2005, at 4:47 PM, Tim S. Woodall wrote:
Note that the recent change to the configure script(s) to use
--with-mvapi
instead of --with-btl-mvapi are not complete. I've recently had to use
both
to compile mvapi. This is causing a great deal of pain for external
users.
Can someone please look at this?
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
[O-MPI devel] using MPI_Alloc_mem
Tim --
Doesn't this violate the "nothing should call MPI functions" rule?
I also ask because there's a bunch of places where we alloc temporary
buffers in the collectives -- should we be using whatever the back-end
to MPI_Alloc_mem is instead of malloc()?
(this would apply to both the basic and tuned collective components)
Begin forwarded message:
From: twood...@osl.iu.edu
Date: September 22, 2005 12:43:19 PM EDT
To: svn-f...@open-mpi.org
Subject: [O-MPI svn-full] svn:open-mpi r7487 - trunk/ompi/mpi/c
Reply-To: de...@open-mpi.org
Author: twoodall
Date: 2005-09-22 11:43:17 -0500 (Thu, 22 Sep 2005)
New Revision: 7487
Modified:
trunk/ompi/mpi/c/sendrecv_replace.c
Log:
use MPI_Alloc_mem/MPI_Free_mem for internally allocated buffers
Modified: trunk/ompi/mpi/c/sendrecv_replace.c
===
--- trunk/ompi/mpi/c/sendrecv_replace.c 2005-09-22 16:41:34 UTC (rev
7486)
+++ trunk/ompi/mpi/c/sendrecv_replace.c 2005-09-22 16:43:17 UTC (rev
7487)
@@ -86,8 +86,8 @@
/* setup a buffer for recv */
ompi_convertor_get_packed_size( &convertor, &packed_size );
if( packed_size > sizeof(recv_data) ) {
-iov.iov_base = (caddr_t)malloc(packed_size);
-if(iov.iov_base == NULL) {
+rc = MPI_Alloc_mem(packed_size, MPI_INFO_NULL,
&iov.iov_base);
+if(OMPI_SUCCESS != rc) {
OMPI_ERRHANDLER_RETURN(OMPI_ERR_OUT_OF_RESOURCE,
comm, MPI_ERR_BUFFER, FUNC_NAME);
}
} else {
@@ -117,7 +117,7 @@
/* release resources */
if(packed_size > sizeof(recv_data)) {
-free(iov.iov_base);
+MPI_Free_mem(iov.iov_base);
}
OBJ_DESTRUCT(&convertor);
return MPI_SUCCESS;
___
svn-full mailing list
svn-f...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
Re: [O-MPI devel] mpif.h problems
On Sep 21, 2005, at 3:37 PM, David R. (Chip) Kent IV wrote:
I managed to find a number of problems with the mpif.h when I tried it
on
a big application. It looks like a lot of key constants are not
defined
in this file. So far, MPI_SEEK_SET, MPI_MODE_CREATE, MPI_MODE_WRONLY
have broken the build. I've added them to mpif.h as I find them so
that
I can get the build to go, but I assume there are many more values
still
missing.
(sorry I didn't reply earlier; was traveling with limited connectivity
when you sent this)
Yoinks. Looks like we forgot to add the MPI-2 IO constants into
mpif.h; thanks for finding this.
I'll go add them and take a swipe through the file to see if I can find
any others that we're missing. Did you find any others that are
missing?
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
Re: [O-MPI devel] mca selection
This will benefit to several components: BTL/PTL, PML, having a common set of functions will be really useful. I just have a request. If we specify something like "--mca btl self,mvapi" I think it can be useful to get them in the specified order. For some components (like the BTL) it doesn't make any difference as we will use their internal priorities to order them.For others we can use the order as an indication of the user kind priority. Thanks, george. Jeff Squyres wrote: Short version: -- I'd like to have a single, top-level MCA param for each framework that controls the "include" and "exclude" behavior of components. Something like: mpirun --mca btl self,mvapi ... would "include" self, mvapi (this actually already works for dynamic compiles). And: mpirun --mca btl !tcp would "exclude" tcp. This would be for all frameworks, at the mca_base_components_open() level, not during framework-specific selection. Hence, excluded / not-included components wouldn't even be opened (i.e., faster startup and smaller memory footprint). Longer version: --- Long, long ago, before Tim knew that I put in the MCA params into mca_base_components_open(), he added btl_base_include and btl_base_exclude to handle this kind of thing. I think that this should be handled at the MCA level itself -- there should be no need to have this kind of exclusion and inclusion at each framework. More specifically, the frameworks can call mca_base_components_open() just as they do now, and if the MCA parameter for that framework was specified, mca_base_components_open() will obey it and pass back a customized list of components back to the caller. The btl_base_[include|exclude] parameters (and others similar to it) can then be removed. Given that I already am on the hook to fix the static compile issue for 1.0, adding this functionality would be pretty trivial. Therefore, I'd like to do it for 1.0. It would also give us a nice, uniform way of including components across all frameworks. It's also shorter to type on the command line. :-) Comments?
Re: [O-MPI devel] why do we need the backward dependencies ?
That was the problem that trigger my question. If we remove the dependence to the libopal in the malloc_interpose we can compile the module. Otherwise the compilation fails because the generation of the mca_memory_malloc_interpose happens priori to the libopal.so. However, reading the last email I now understand why we need the backward dependence to the libopal and liborte. But I still see a problem. **Just to refresh the memories, I'm the only complaining on a regular base about the useless dependencies**. And there are a lot. I know that most of the shared libraries in ompi use functions in the opal section. But few of them rely on any of the orte shared libraries. If the dependencies are set correctly then we don't have to add $(top_ompi_builddir)/ompi/libmpi.la $(top_ompi_builddir)/orte/liborte.la $(top_ompi_builddir)/opal/libopal.la all over the Makefiles. george. Ralf Wildenhues wrote: Andrew, * Ralf Wildenhues wrote on Fri, Sep 23, 2005 at 10:42:34AM CEST: * Andrew Friedley wrote on Thu, Sep 22, 2005 at 09:09:11PM CEST: On Sep 22, 2005, at 12:56 PM, George Bosilca wrote: Now we get this message for all .so file we generate: libtool: install: warning: relinking `*.la' I think I found a small error in the patch, see proposed fix below. Cheers, Ralf Index: opal/mca/memory/malloc_interpose/Makefile.am === --- opal/mca/memory/malloc_interpose/Makefile.am(revision 7493) +++ opal/mca/memory/malloc_interpose/Makefile.am(working copy) @@ -22,6 +22,5 @@ libmca_memory_malloc_interpose_la_SOURCES = \ memory_malloc_interpose.c libmca_memory_malloc_interpose_la_LIBADD = \ - $(memory_malloc_interpose_LIBS) \ - $(top_ompi_builddir)/opal/libopal.la + $(memory_malloc_interpose_LIBS) ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
[O-MPI devel] mpi.h and mpif.h
Guys, I'm looking into some ideas coming during the Euro PVM/MPI meeting. I need as many as possible of the includes files for different MPI implementations. If you have access to any MPI implementation (not the one freely available for download), please send me their mpi.h and mpif.h files. Thanks, george.
Re: [O-MPI devel] mca selection
I'm not sure I understand -- all frameworks have priorities for their
components...?
On Sep 23, 2005, at 11:55 AM, George Bosilca wrote:
This will benefit to several components: BTL/PTL, PML, having a common
set of functions will be really useful. I just have a request. If we
specify something like "--mca btl self,mvapi" I think it can be useful
to get them in the specified order. For some components (like the BTL)
it doesn't make any difference as we will use their internal priorities
to order them.For others we can use the order as an indication of the
user kind priority.
Thanks,
george.
Jeff Squyres wrote:
Short version:
--
I'd like to have a single, top-level MCA param for each framework that
controls the "include" and "exclude" behavior of components.
Something
like:
mpirun --mca btl self,mvapi ...
would "include" self, mvapi (this actually already works for dynamic
compiles). And:
mpirun --mca btl !tcp
would "exclude" tcp. This would be for all frameworks, at the
mca_base_components_open() level, not during framework-specific
selection. Hence, excluded / not-included components wouldn't even be
opened (i.e., faster startup and smaller memory footprint).
Longer version:
---
Long, long ago, before Tim knew that I put in the MCA
params into mca_base_components_open(), he added btl_base_include and
btl_base_exclude to handle this kind of thing. I think that this
should be handled at the MCA level itself -- there should be no need
to
have this kind of exclusion and inclusion at each framework.
More specifically, the frameworks can call mca_base_components_open()
just as they do now, and if the MCA parameter for that framework was
specified, mca_base_components_open() will obey it and pass back a
customized list of components back to the caller. The
btl_base_[include|exclude] parameters (and others similar to it) can
then be removed.
Given that I already am on the hook to fix the static compile issue
for
1.0, adding this functionality would be pretty trivial. Therefore,
I'd
like to do it for 1.0. It would also give us a nice, uniform way of
including components across all frameworks.
It's also shorter to type on the command line. :-)
Comments?
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
Re: [O-MPI devel] why do we need the backward dependencies ?
Hi George, * George Bosilca wrote on Fri, Sep 23, 2005 at 06:05:28PM CEST: > > But I still see a problem. **Just to refresh the memories, I'm the only > complaining on a regular base about the useless dependencies**. And > there are a lot. I know that most of the shared libraries in ompi use > functions in the opal section. But few of them rely on any of the orte > shared libraries. If the dependencies are set correctly then we don't > have to add > > $(top_ompi_builddir)/ompi/libmpi.la > $(top_ompi_builddir)/orte/liborte.la > $(top_ompi_builddir)/opal/libopal.la > > all over the Makefiles. This is basically what I suggested to Jeff as well. It's more work to keep things accurate this way, though, unless you manage to impose strict rule this way. By the way, it might be possible to check this more-or-less with some automatisms, on a capable platform. I.e., on a recent GNU/Linux you could verify whether some deplib was really needed (with comparing DT_NEEDED with and without --as-needed); on Solaris/CC, you could check the other way round: find any missing dependency with Libtool's option -no-undefined. Not great, but it might suffice for a regression test. If you like, I can think of hacking something like this up. Cheers, Ralf
Re: [O-MPI devel] why do we need the backward dependencies ?
As we saw it, it was 6 of one and a half-dozen of the other.
Specifically:
- Almost everything is going to require libopal. Let's swag and say
90% of components will need libopal.
- All ORTE components will need liborte. Maybe half of OMPI components
need it (WAG).
So really, all we're talking about here are a handful of OMPI
components that don't need liborte. And *maybe* a very, very small
number of components that don't need libopal (WAG: less than 5).
So all things being equal, it was tremendously easier [and faster] to
just add all the libraries (libopal to OPAL components, liborte/opal to
ORTE components, and libmpi/orte/opal to MPI components) rather than
try to figure out exactly which ones each component needed.
So -- for the components who had an extra library linked in, who cares?
- In the static case, no additional code is linked into the component
(i.e., the component is identical to whether you linked in the
additional library or not)
- In the dynamic case, the extra library is listed in the component's
linker section. So yes, this is wasteful, but really only by a few
bytes (literally) -- and it potentially allows for faster loading at
run-time.
What exactly is the harm? It creates a small number of artificial
dependencies, but we figured it would be much safer than sorry (i.e.,
better than *not* relinking a component when it was needed).
As for why we listed all three in the MPI case (and both in the ORTE
case), it was actually to make things simpler for developers. True,
because Libtool is cool, you could just list libmpi for MPI components
(and liborte and libopal will be picked up automatically; similarly for
ORTE components), but I'll bet you $10 that most other OMPI developers
stopped reading this e-mail 5 paragraphs ago and would not spend any
cycles on why this was so, and would probably list all 3 libraries for
MPI components anyway (because that's typically how Unix linking works
-- you -l all the libraries that you need and don't rely on the linker
to automatically pick them up for you). :D
We have other things to worry about right now, and real problems to
fix. So who cares?
On Sep 23, 2005, at 12:05 PM, George Bosilca wrote:
That was the problem that trigger my question. If we remove the
dependence to the libopal in the malloc_interpose we can compile the
module. Otherwise the compilation fails because the generation of the
mca_memory_malloc_interpose happens priori to the libopal.so. However,
reading the last email I now understand why we need the backward
dependence to the libopal and liborte.
But I still see a problem. **Just to refresh the memories, I'm the
only complaining on a regular base about the useless dependencies**.
And there are a lot. I know that most of the shared libraries in ompi
use functions in the opal section. But few of them rely on any of the
orte shared libraries. If the dependencies are set correctly then we
don't have to add
$(top_ompi_builddir)/ompi/libmpi.la
$(top_ompi_builddir)/orte/liborte.la
$(top_ompi_builddir)/opal/libopal.la
all over the Makefiles.
george.
Ralf Wildenhues wrote:Andrew,
* Ralf Wildenhues wrote on Fri, Sep 23, 2005 at 10:42:34AM CEST:
* Andrew Friedley wrote on Thu, Sep 22, 2005 at 09:09:11PM CEST:
On Sep 22, 2005, at 12:56 PM, George Bosilca wrote:
Now we get this message for all .so file we generate:
libtool: install: warning: relinking `*.la'
I think I found a small error in the patch, see proposed fix below.
Cheers,
Ralf
Index: opal/mca/memory/malloc_interpose/Makefile.am
===
--- opal/mca/memory/malloc_interpose/Makefile.am(revision
7493)
+++ opal/mca/memory/malloc_interpose/Makefile.am(working copy)
@@ -22,6 +22,5 @@
libmca_memory_malloc_interpose_la_SOURCES = \
memory_malloc_interpose.c
libmca_memory_malloc_interpose_la_LIBADD = \
- $(memory_malloc_interpose_LIBS) \
- $(top_ompi_builddir)/opal/libopal.la
+ $(memory_malloc_interpose_LIBS)
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
