Re: [OMPI devel] 1.3.1 blocker
We just tested it and it worked for us. Looks good. Thanks ! Rolf Brian Barrett wrote: I believe the problem is fixed with r20776 (and r20777), at least for the test case Jeff had in the bug tracker. Can someone else give it a whirl and see if I'm just getting lucky? Thanks, Brian On Mar 13, 2009, at 7:51 AM, Ralph Castain wrote: Just as an FYI: While I have some data on this issue, I will likely not have time to address it in the next week or so due to institutional priorities. So if someone who cares about rsh/ssh launching (I'm afraid we don't) would like to take a look at it, they are welcome to do so. :-) Ralph On Mar 12, 2009, at 9:30 PM, Jeff Squyres wrote: To let everyone else know... We unfortunately ran into a blocker bug today, literally right before 1.3.1 went out the door. Doh! https://svn.open-mpi.org/trac/ompi/ticket/1832 -- Jeff Squyres Cisco Systems ___ 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
Re: [OMPI devel] 1.3.1 blocker
I believe the problem is fixed with r20776 (and r20777), at least for the test case Jeff had in the bug tracker. Can someone else give it a whirl and see if I'm just getting lucky? Thanks, Brian On Mar 13, 2009, at 7:51 AM, Ralph Castain wrote: Just as an FYI: While I have some data on this issue, I will likely not have time to address it in the next week or so due to institutional priorities. So if someone who cares about rsh/ssh launching (I'm afraid we don't) would like to take a look at it, they are welcome to do so. :-) Ralph On Mar 12, 2009, at 9:30 PM, Jeff Squyres wrote: To let everyone else know... We unfortunately ran into a blocker bug today, literally right before 1.3.1 went out the door. Doh! https://svn.open-mpi.org/trac/ompi/ticket/1832 -- Jeff Squyres Cisco Systems ___ 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 -- Brian Barrett Open MPI developer http://www.open-mpi.org/
[OMPI devel] some comments on attribute catching, create/free() keyvals and all that.
I've posted this to MPICH2-Dev, and then decided to re-post this here,
at the behavior of Open MPI is exactly the same.
You may also want to try the code right below, and next the one at the
end of the forwarder message.
#include
#include
int main( int argc, char ** argv ) {
int Key1, tmp1, Key2, tmp2;
MPI_Init(&argc, &argv);
MPI_Keyval_create(MPI_NULL_COPY_FN, MPI_NULL_DELETE_FN, &Key1,(void *) 0);
tmp1=Key1;
MPI_Keyval_free(&tmp1);
MPI_Keyval_create(MPI_NULL_COPY_FN, MPI_NULL_DELETE_FN, &Key2, (void *) 0);
tmp2=Key2;
MPI_Keyval_free(&tmp2);
MPI_Finalize();
printf("MPI_KEYVAL_INVALID: %d\n", MPI_KEYVAL_INVALID);
printf("Key1: %d\n", Key1);
printf("tmp1: %d\n", tmp1);
printf("Key2: %d\n", Key2);
printf("tmp2: %d\n", tmp2);
return 0;
}
-- Forwarded message --
From: Lisandro Dalcin
List-Post: devel@lists.open-mpi.org
Date: Fri, Mar 13, 2009 at 4:01 PM
Subject: some comments on attribute catching, create/free() keyvals
and all that.
To: mpich2-...@mcs.anl.gov
As I've shown in a previous emal, MPICH2 likely implement
create()/free() for keyvals using a counter that is incr/decr ...
Now, give a try to the code pasted below. This shows that (at least in
MPICH2), MPI_Keyval_free() have to be used with great care as it is
IMHO dangerous, and basically these calls should be all done near
MPI_Finalize() time... or bad things could happen...
The only reference I can found in the MPI standard is at
(http://www.mpi-forum.org/docs/mpi21-report-bw/node147.htm#Node147)
where MPI_Comm_free_keyval() is explained... However, I believe that
description is talking about different things...
Should MPICH2 stop decrefing the keyval counter? You know, about 2<<31
values should be enough, right ;-) ?
But then.. What the pourpose of having MPI_Keyval_free()? Just to
invalidate de passed value by setting it to KEYVAL_INVALID?
#include
#include
int free_KeyVal(MPI_Comm c, int k, void *v,void *ctx)
{
printf("free_KeyVal()\n");
return MPI_SUCCESS;
}
int main( int argc, char ** argv ) {
int Key1, Key2, Val1=1, Val2=2, ValOut;
MPI_Init(&argc, &argv);
MPI_Keyval_create(MPI_NULL_COPY_FN, free_KeyVal, &Key1,(void *) 0);
MPI_Attr_put(MPI_COMM_SELF, Key1, &Val1);
MPI_Keyval_free(&Key1);
MPI_Keyval_create(MPI_NULL_COPY_FN, MPI_NULL_DELETE_FN, &Key2,(void *) 0);
MPI_Attr_put(MPI_COMM_SELF, Key2, &Val2);
MPI_Keyval_free(&Key2);
MPI_Finalize();
return 0;
}
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Re: [OMPI devel] 1.3.1 blocker
Just as an FYI: While I have some data on this issue, I will likely not have time to address it in the next week or so due to institutional priorities. So if someone who cares about rsh/ssh launching (I'm afraid we don't) would like to take a look at it, they are welcome to do so. :-) Ralph On Mar 12, 2009, at 9:30 PM, Jeff Squyres wrote: To let everyone else know... We unfortunately ran into a blocker bug today, literally right before 1.3.1 went out the door. Doh! https://svn.open-mpi.org/trac/ompi/ticket/1832 -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Meta Question -- Open MPI: Is it a dessert toppingor is it a floor wax?
I would like to add my 0.02 to this discussion.
The "code stability" it is not something that should stop project from
development and progress. During MPI Project live we already saw some
pretty critical changes (pml/btl/etc...) and as result after all we have
more stable and more optimized MPI. OMPI already have defined
workflow that allow to us handle big code changes without loosing code
stability for a long period of time. As I understand the btl movement
will make the code more modular and will open window for new features
and optimizations.
So if the BTL movement will not effect negatively on MPI performance and
code stability (for a long period of time, temporary unstability may be
reasonable) I do not see any constructive reason to block this
modification. If I understand correct the code will go to the
feature_oriented branch and we will have enough time to run QA cycles
before it will be moved to super_stable mode.
And after all I hope that we will get more stable,modular and feature
rich MPI implementation.
Thanks,
Pasha
Brian W. Barrett wrote:
I'm going to stay out of the debate about whether Andy correctly
characterized the two points you brought up as a distributed OS or not.
Sandia's position on these two points remains the same as I previously
stated when the question was distributed OS or not. The primary goal
of the Open MPI project was and should remain to be the best MPI
project available. Low-cost items to support different run-times or
different non-MPI communication contexts are worth the work. But
high-cost items should be avoided, as they degrade our ability to
provide the best MPI project available (of course, others, including
OMPI developers, can take the source and do what they wish outside the
primary development tree).
High performance is a concern, but so is code maintainability. If it
takes twices as long to implement feature A because I have to worry
about it's impact not only on MPI, but also on projects X, Y, Z, as an
MPI developer, I've lost something important.
Brian
On Thu, 12 Mar 2009, Richard Graham wrote:
I am assuming that by distributed OS you are referring to the changes
that
we (not just ORNL) are trying to do. If this is the case, this is a
mischaracterization of the of out intentions. We have two goals
- To be able to use a different run-time than ORTE to drive Open MPI
- To use the communication primitives outside the context of MPI
(with or
without ORTE)
High performance is critical, and at NO time have we ever said anything
about sacrificing performance - these have been concerns that others
(rightfully) have expressed.
Rich
On 3/12/09 8:24 AM, "Jeff Squyres" wrote:
I think I have to agree with Terry.
I love to inspire and see new, original, and unintended uses for Open
MPI. But our primary focus must remain to create, maintain, and
continue to deliver a high performance MPI implementation.
We have a long history of adding "small" things to Open MPI that are
useful to 3rd parties because it helps them, helps further Open MPI
adoption/usefulness, and wasn't difficult for us to do ("small" can
have varying definitions). I'm in favor of such things, as long as we
maintain a policy of "in cases of conflict, OMPI/high performance MPI
wins".
On Mar 12, 2009, at 9:01 AM, Terry Dontje wrote:
Sun's participation in this community was to obtain a stable and
performant MPI implementation that had some research work done on the
side to improve those goals and the introduction of new features. We
don't have problems with others using and improving on the OMPI code
base but we need to make sure such usage doesn't detract from our
primary goal of performant MPI implementation.
However, changes to the OMPI code base to allow it to morph or even
support a distributed OS does cause for some concern. That is are we
opening the door to having more interfaces to support? If so is this
wise in the fact that it seems to me we have a hard enough time trying
to focus on the MPI items? Not to mention this definitely starts
detracting from the original goals.
--td
Andrew Lumsdaine wrote:
Hi all -- There is a meta question that I think is underlying some
of
the discussion about what to do with BTLs etc. Namely, is Open
MPI an
MPI implementation with a portable run time system -- or is it a
distributed OS with an MPI interface? It seems like some of the
changes being asked for (e.g., with the BTLs) reflect the latter --
but perhaps not everyone shares that view and hence the impedance
mismatch.
I doubt this is the last time that tensions will come up because of
differing views on this question.
I suggest that we come to some kind of common understanding of the
question (and answer) and structure development and administration
accordingly.
Best Regards,
Andrew Lumsdaine
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
__
