Re: [OMPI devel] RFC: convert send to ssend

[Ralph Castain]

On Aug 24, 2009, at 5:33 PM, Patrick Geoffray wrote:


George Bosilca wrote:
I know the approach "because we can". We develop an MPI library,  
and we should keep it that way. Our main focus should not diverge  
to provide


I would join George in the minority on this one. "Because we can" is  
a slippery slope, there is value in keeping things simple, having  
less knobs and bells and whistles.


On this particular whistle, the user could add one line to his MPI  
code to define send to ssend and be done with it. If he does not  
have the code in the first place, there is nothing he can't do about  
it anyway. So, it's just a matter of convenience for a lazy user.


Not quite that simple, Patrick. Think of things like MPI_Sendrecv,  
where the "send" call is below that of the user's code.


Frankly, I'm surprised at the fuss this has kicked up. It is a barely  
a handful of lines of code, totally protected by a configure switch.


If we spent this much effort arguing over every such small thing,  
nearly every configure option that currently exists would never have  
made it.





Patrick
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: convert send to ssend

[Patrick Geoffray]

George Bosilca wrote:
I know the approach "because we can". We develop an MPI library, and we 
should keep it that way. Our main focus should not diverge to provide 


I would join George in the minority on this one. "Because we can" is a 
slippery slope, there is value in keeping things simple, having less 
knobs and bells and whistles.


On this particular whistle, the user could add one line to his MPI code 
to define send to ssend and be done with it. If he does not have the 
code in the first place, there is nothing he can't do about it anyway. 
So, it's just a matter of convenience for a lazy user.


Patrick

Re: [OMPI devel] RFC: convert send to ssend

[Jeff Squyres]

On Aug 24, 2009, at 1:35 PM, Ashley Pittman wrote:

> The point of b is for sysadmins (or individual developers) who  
want to

> force there to *always* be correct MPI applications.

But couldn't the sysadmin equally well write a config file to achieve
the same effect should they want to?



Yes, probably so.  I was only pulling from the precedent of the MPI  
param checking for the tri-state.



Having it enabled (and on) in the standard "debug" build is going to
change the behaviour of applications with using a debug library, may
well render bugs un-reproducible in debug mode or worse you may end up
with end-user applications that only run in debug mode and not with a
normal build.



Agreed.  Just to be totally clear: I, too, would not advocate that  
this feature be automatically enabled in debug builds.  It should  
default to compiled-out in all cases -- only enabled via a configure  
switch.


--
Jeff Squyres
jsquy...@cisco.com

Re: [OMPI devel] New frameworks and contribs in the trunk

[George Bosilca]

On Aug 21, 2009, at 07:33 , Ralph Castain wrote:


Hi Rich

On Aug 21, 2009, at 5:14 AM, Graham, Richard L. wrote:

I have several questions here - since process migration is an open  
research question,

and there is more than one way to address the issue -
- Is this being implemented as a component, so that other  
approaches can be used ?


Absolutely - we have several organizations involved, all with  
competing approaches


This become a recurrent statement, every time something smelly should  
be defended.



- If so, what sort of component interface is being considered ?


Still being determined. One reason for exposing the frameworks at  
this time is that much of the ongoing effort may occur in separate,  
hidden tmp branches for proprietary reasons. The eventual source  
code for those components may well never be committed, but the  
frameworks need to be in the system so that MCA will pickup the  
binary modules.


This is a wrong reason. We did multi-institution work in the past  
starting from a tmp branch. The only overhead is that somebody has to  
keep the copy in sync with the trunk, but this approach at least has  
the merit to keep our trunk [more or less] clean.


I deliberately left the frameworks "inactive" so that changes in the  
APIs can be done as the work progresses without impacting the OMPI  
community. The participants need to develop a little further before  
we fully understand what the APIs need to be - a little hard to  
openly discuss them without exposing potentially proprietary algos.  
The hope is that, as people develop their components, they can  
identify missing needs in the API so at least that much can be  
safely communicated and resolved.



- What is the impact (or expected impact) on the rest of the system ?


For anyone who doesn't explicitly build it and turn it on, nothing.  
For those who do, there will be no impact on MPI procs themselves as  
they won't load nor activate these frameworks. There will be an  
increased orted footprint and activity level, which could  
potentially reduce performance by stealing cycles from MPI procs -  
obviously, that depends on #procs vs cores and other factors.


If nobody knows how to do it, this _clearly_ should be a good enough  
reason to do the work in a temp branch before polluting the trunk.


  george.




I'm speaking solely of the RTE impact and issues here, of course -  
Josh would have to address the MPI perspective.


HTH
Ralph



Thanks,
Rich


On 8/20/09 6:57 PM, "Ralph Castain"  wrote:

Hmmm...I'm afraid I cannot entirely substantiate your concerns.
Everything compiles just fine for me under both Linux and OSX. True,
the files are not completely instantiated on the trunk at this time,
but they also are not activated on the trunk for precisely that  
reason.


Can you provide an example of where something isn't building? I can't
find it on any platform available to me.

Thanks
Ralph

On Aug 20, 2009, at 4:32 PM, George Bosilca wrote:


Ralph,

I'm a little bit concerned about the commits stated below as their
quality doesn't match the usual quality standards of the trunk.
There are several issues: mostly empty files, names coming from
other frameworks, failure to compile on several platforms (including
Linux and MAC OS X). I'm more than happy to see research code in the
trunk, and I will be really interested to see the proof that
preemptive migration works. However, the quality of the trunk should
not suffer.

Moreover, we have mercurial and svn temporary repositories for such
kind of work. And we did force people in the past to work on
temporary branches before such large commits on the trunk.

Please reconsider your patches.

Thanks,
 george.



https://svn.open-mpi.org/trac/ompi/changeset/21849
https://svn.open-mpi.org/trac/ompi/changeset/21850
https://svn.open-mpi.org/trac/ompi/changeset/21848
https://svn.open-mpi.org/trac/ompi/changeset/21847

___
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


___
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] RFC: convert send to ssend

[George Bosilca]

We spent more time over emails on this thread than the time required  
to write the patch. As apparently I'm the only one concerned about  
what we have in our code base or the only one that do not perceive the  
usefulness of such a feature, I belong to an ignorable minority.


As long as you don't make it compile by default, please ignore my  
rambling.


On Aug 24, 2009, at 15:30 , Jeff Squyres wrote:


On Aug 24, 2009, at 2:26 PM, George Bosilca wrote:


> My point is that this is a fairly trivial-to-implement feature.  It
> can even be done in a way that doesn't impact performance at all
> (default to compile out).

It is more trivial than this: mpirun -np 2 --mca
btl_tcp_rndv_eager_limit 0 --mca btl_tcp_eager_limit 72  --bynode ./
NPmpi ?



You would have a user do that rather than

  mpirun --mca mpi_force_ssend 1 -np 2 --bynode ./NPmpi

?

I'm an OMPI implementor and I'll never remember that the TCP BTL  
requires *2* eager limits, much less what their values are.  :-)


My version is for free, it doesn't require _any_ modification in the  
source code and no long term maintenance. In fact, what I'm trying to  
say it's that we already have such a feature, except it doesn't have a  
cool name (mpi_force_ssend) and it is slightly PML dependent.


  george.

Re: [OMPI devel] RFC: convert send to ssend

[Jeff Squyres]

On Aug 24, 2009, at 2:26 PM, George Bosilca wrote:


> My point is that this is a fairly trivial-to-implement feature.  It
> can even be done in a way that doesn't impact performance at all
> (default to compile out).

It is more trivial than this: mpirun -np 2 --mca
btl_tcp_rndv_eager_limit 0 --mca btl_tcp_eager_limit 72  --bynode ./
NPmpi ?



You would have a user do that rather than

   mpirun --mca mpi_force_ssend 1 -np 2 --bynode ./NPmpi

?

I'm an OMPI implementor and I'll never remember that the TCP BTL  
requires *2* eager limits, much less what their values are.  :-)


--
Jeff Squyres
jsquy...@cisco.com

Re: [OMPI devel] RFC: convert send to ssend

[George Bosilca]

On Aug 24, 2009, at 13:25 , Jeff Squyres wrote:


On Aug 24, 2009, at 11:35 AM, George Bosilca wrote:


As a side note, a very similar effect can be obtained by decreasing
the eager size of the BTLs to be equal to the size of the match
header, which is about 24 bytes.



I disagree with this statement.  ;-)

We currently don't export the BTL or PML header size, so you can't  
possibly know what value to set the eager limit to.  And even if we  
did, as the conversation between you, me, and Brian from the last  
Chicago Forum meeting proved, the exact definition of "eager_limit"  
is a fairly nebulous thing.


It's enough to ask somebody who knows. While I agree that we don't  
have a simple definition of the eager_limit, for this particular topic  
it's enough to set it as low as possible.


My point is that this is a fairly trivial-to-implement feature.  It  
can even be done in a way that doesn't impact performance at all  
(default to compile out).


It is more trivial than this: mpirun -np 2 --mca  
btl_tcp_rndv_eager_limit 0 --mca btl_tcp_eager_limit 72  --bynode ./ 
NPmpi ?


We all know that there are many MPI correctness tools that are  
available, but it can be difficult to get users to actually use  
them.  If they can flip a switch a mpirun time to turn on some  
semantic checking, that's a Good Thing.


I know the approach "because we can". We develop an MPI library, and  
we should keep it that way. Our main focus should not diverge to  
provide features for a hand of users, features that will barely be  
maintained and that might hit us back in the future. There are way to  
many critical features that we need now, to focus on something as  
trivial as transforming sends in ssends.


Anyway, we are a community based project and the vote of the community  
will decide the fate of this RFC.


  george.

Re: [OMPI devel] RFC: convert send to ssend

[Samuel K. Gutierrez]

Hi Ashley,

My understanding is that this behavior would not be enabled by default 
in the standard debug build.  The "always convert to synchronous sends" 
mode would be an additional configure-time option.


Samuel K. Gutierrez

Ashley Pittman wrote:

On Mon, 2009-08-24 at 13:27 -0400, Jeff Squyres wrote:
  

It's the difference between:

a. if (0) { ... convert ... }  Modern compilers will remove this code  
as part of dead-code removal.
b. if (1) { ... convert ... }  Modern compilers will remove the "if  
(1)" and always execute the code.
c. if (some_variable) { ... convert ...}  An MCA parameter can load  
some_variable with 0 or 1.


The point of b is for sysadmins (or individual developers) who want to  
force there to *always* be correct MPI applications.



But couldn't the sysadmin equally well write a config file to achieve
the same effect should they want to?

Having it enabled (and on) in the standard "debug" build is going to
change the behaviour of applications with using a debug library, may
well render bugs un-reproducible in debug mode or worse you may end up
with end-user applications that only run in debug mode and not with a
normal build.

I'm all for having as much error checking enabled in debug builds as
possible but to change the behaviour risks masking problems elsewhere
IMHO.

Ashley,

  

Re: [OMPI devel] RFC: convert send to ssend

[Ashley Pittman]

On Mon, 2009-08-24 at 13:27 -0400, Jeff Squyres wrote:
> It's the difference between:
> 
> a. if (0) { ... convert ... }  Modern compilers will remove this code  
> as part of dead-code removal.
> b. if (1) { ... convert ... }  Modern compilers will remove the "if  
> (1)" and always execute the code.
> c. if (some_variable) { ... convert ...}  An MCA parameter can load  
> some_variable with 0 or 1.
> 
> The point of b is for sysadmins (or individual developers) who want to  
> force there to *always* be correct MPI applications.

But couldn't the sysadmin equally well write a config file to achieve
the same effect should they want to?

Having it enabled (and on) in the standard "debug" build is going to
change the behaviour of applications with using a debug library, may
well render bugs un-reproducible in debug mode or worse you may end up
with end-user applications that only run in debug mode and not with a
normal build.

I'm all for having as much error checking enabled in debug builds as
possible but to change the behaviour risks masking problems elsewhere
IMHO.

Ashley,

-- 

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk

Re: [OMPI devel] RFC: convert send to ssend

[Jeff Squyres]

On Aug 24, 2009, at 12:14 PM, Ashley Pittman wrote:


> - compiled out
> - compiled in, always convert standard send to sync send
> - compiled in, use MCA parameter to determine whether to convert
> standard -> sync
>
> And we can leave the default as "compiled out".
>
> Howzat?

I don't understand, what the purpose of the middle state?  It seems  
like

a bad idea to me.




It's the difference between:

a. if (0) { ... convert ... }  Modern compilers will remove this code  
as part of dead-code removal.
b. if (1) { ... convert ... }  Modern compilers will remove the "if  
(1)" and always execute the code.
c. if (some_variable) { ... convert ...}  An MCA parameter can load  
some_variable with 0 or 1.


The point of b is for sysadmins (or individual developers) who want to  
force there to *always* be correct MPI applications.


--
Jeff Squyres
jsquy...@cisco.com

Re: [OMPI devel] RFC: convert send to ssend

[Jeff Squyres]

On Aug 24, 2009, at 11:35 AM, George Bosilca wrote:


As a side note, a very similar effect can be obtained by decreasing
the eager size of the BTLs to be equal to the size of the match
header, which is about 24 bytes.




I disagree with this statement.  ;-)

We currently don't export the BTL or PML header size, so you can't  
possibly know what value to set the eager limit to.  And even if we  
did, as the conversation between you, me, and Brian from the last  
Chicago Forum meeting proved, the exact definition of "eager_limit" is  
a fairly nebulous thing.


My point is that this is a fairly trivial-to-implement feature.  It  
can even be done in a way that doesn't impact performance at all  
(default to compile out).  We all know that there are many MPI  
correctness tools that are available, but it can be difficult to get  
users to actually use them.  If they can flip a switch a mpirun time  
to turn on some semantic checking, that's a Good Thing.


--
Jeff Squyres
jsquy...@cisco.com

Re: [OMPI devel] RFC: convert send to ssend

[Ashley Pittman]

On Mon, 2009-08-24 at 10:52 -0400, Jeff Squyres wrote:

> Adapting that to this RFC, perhaps something like this:
> 
> - compiled out
> - compiled in, always convert standard send to sync send
> - compiled in, use MCA parameter to determine whether to convert  
> standard -> sync
> 
> And we can leave the default as "compiled out".
> 
> Howzat?

I don't understand, what the purpose of the middle state?  It seems like
a bad idea to me.

Ashley,

-- 

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk

Re: [OMPI devel] RFC: convert send to ssend

[Sylvain Jeaugey]

For the record, I see an big interest in this.

Sometimes, you have to answer calls for tender featuring applications that 
must work with no code change, even if the code is completely not 
MPI-compliant.


That's sad, but true (no pun intended :-))

Sylvain

On Mon, 24 Aug 2009, George Bosilca wrote:

Do people know that there exist tools for checking MPI code correctness? 
Many, many tools and most of them are freely available.


Personally I don't see any interest of doing this, absolutely no interest. 
There is basically no added value to our MPI, except for a very limited 
number of users, and these users if they manage to write a parallel 
application that need this checking I'm sure they will greatly benefit from a 
real tool to help them correct their MPI code.


As a side note, a very similar effect can be obtained by decreasing the eager 
size of the BTLs to be equal to the size of the match header, which is about 
24 bytes.


george.

On Aug 24, 2009, at 11:11 , Samuel K. Gutierrez wrote:


Hi Jeff,

Sounds good to me.

Samuel K. Gutierrez


Jeff Squyres wrote:
The debug builds already have quite a bit of performance overhead.  It 
might be desirable to change this RFC to have a similar tri-state as the 
MPI parameter checking:


- compiled out
- compiled in, always check
- compiled in, use MCA parameter to determine whether to check

Adapting that to this RFC, perhaps something like this:

- compiled out
- compiled in, always convert standard send to sync send
- compiled in, use MCA parameter to determine whether to convert standard 
-> sync


And we can leave the default as "compiled out".

Howzat?


On Aug 23, 2009, at 9:07 PM, Samuel K. Gutierrez wrote:


Hi all,

How about exposing this functionality as a run-time parameter that is 
only

available in debug builds?  This will make debugging easier and won't
impact the performance of optimized builds.  Just an idea...

Samuel K. Gutierrez



- "Jeff Squyres"  wrote:


Does anyone have any suggestions?  Or are we stuck
with compile-time checking?


I didn't see this until now, but I'd be happy with
just a compile time option so we could produce an
install just for debugging purposes and have our
users explicitly select it with modules.

I have to say that this is of interest to us as we're
trying to help a researcher at one of our member uni's
to track down a bug where a message appears to go missing.

cheers!
Chris
--
Christopher Samuel - (03) 9925 4751 - Systems Manager
 The Victorian Partnership for Advanced Computing
 P.O. Box 201, Carlton South, VIC 3053, Australia
VPAC is a not-for-profit Registered Research Agency
___
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





___
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] RFC: convert send to ssend

[George Bosilca]

Do people know that there exist tools for checking MPI code  
correctness? Many, many tools and most of them are freely available.


Personally I don't see any interest of doing this, absolutely no  
interest. There is basically no added value to our MPI, except for a  
very limited number of users, and these users if they manage to write  
a parallel application that need this checking I'm sure they will  
greatly benefit from a real tool to help them correct their MPI code.


As a side note, a very similar effect can be obtained by decreasing  
the eager size of the BTLs to be equal to the size of the match  
header, which is about 24 bytes.


  george.

On Aug 24, 2009, at 11:11 , Samuel K. Gutierrez wrote:


Hi Jeff,

Sounds good to me.

Samuel K. Gutierrez


Jeff Squyres wrote:
The debug builds already have quite a bit of performance overhead.   
It might be desirable to change this RFC to have a similar tri- 
state as the MPI parameter checking:


- compiled out
- compiled in, always check
- compiled in, use MCA parameter to determine whether to check

Adapting that to this RFC, perhaps something like this:

- compiled out
- compiled in, always convert standard send to sync send
- compiled in, use MCA parameter to determine whether to convert  
standard -> sync


And we can leave the default as "compiled out".

Howzat?


On Aug 23, 2009, at 9:07 PM, Samuel K. Gutierrez wrote:


Hi all,

How about exposing this functionality as a run-time parameter that  
is only
available in debug builds?  This will make debugging easier and  
won't

impact the performance of optimized builds.  Just an idea...

Samuel K. Gutierrez

>
> - "Jeff Squyres"  wrote:
>
>> Does anyone have any suggestions?  Or are we stuck
>> with compile-time checking?
>
> I didn't see this until now, but I'd be happy with
> just a compile time option so we could produce an
> install just for debugging purposes and have our
> users explicitly select it with modules.
>
> I have to say that this is of interest to us as we're
> trying to help a researcher at one of our member uni's
> to track down a bug where a message appears to go missing.
>
> cheers!
> Chris
> --
> Christopher Samuel - (03) 9925 4751 - Systems Manager
>  The Victorian Partnership for Advanced Computing
>  P.O. Box 201, Carlton South, VIC 3053, Australia
> VPAC is a not-for-profit Registered Research Agency
> ___
> 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





___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: convert send to ssend

[Samuel K. Gutierrez]

Hi Jeff,

Sounds good to me.

Samuel K. Gutierrez


Jeff Squyres wrote:
The debug builds already have quite a bit of performance overhead.  It 
might be desirable to change this RFC to have a similar tri-state as 
the MPI parameter checking:


- compiled out
- compiled in, always check
- compiled in, use MCA parameter to determine whether to check

Adapting that to this RFC, perhaps something like this:

- compiled out
- compiled in, always convert standard send to sync send
- compiled in, use MCA parameter to determine whether to convert 
standard -> sync


And we can leave the default as "compiled out".

Howzat?


On Aug 23, 2009, at 9:07 PM, Samuel K. Gutierrez wrote:


Hi all,

How about exposing this functionality as a run-time parameter that is 
only

available in debug builds?  This will make debugging easier and won't
impact the performance of optimized builds.  Just an idea...

Samuel K. Gutierrez

>
> - "Jeff Squyres"  wrote:
>
>> Does anyone have any suggestions?  Or are we stuck
>> with compile-time checking?
>
> I didn't see this until now, but I'd be happy with
> just a compile time option so we could produce an
> install just for debugging purposes and have our
> users explicitly select it with modules.
>
> I have to say that this is of interest to us as we're
> trying to help a researcher at one of our member uni's
> to track down a bug where a message appears to go missing.
>
> cheers!
> Chris
> --
> Christopher Samuel - (03) 9925 4751 - Systems Manager
>  The Victorian Partnership for Advanced Computing
>  P.O. Box 201, Carlton South, VIC 3053, Australia
> VPAC is a not-for-profit Registered Research Agency
> ___
> 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

[OMPI devel] Platform acquires HP-MPI

[Jeff Squyres]

In case you hadn't already heard:

http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104=/www/story/08-24-2009/0005081883=

Note that Platform already owns Scali MPI.

--
Jeff Squyres
jsquy...@cisco.com

Re: [OMPI devel] Improvements to "mpi_leave_pinned" behavior

[Ashley Pittman]

On Fri, 2009-08-21 at 10:41 -0400, Jeff Squyres wrote:
> Roland has pushed his new Linux "ummunotify" kernel upstream (i.e.,  
> it's in his -next git branch):
> 
> http://git.kernel.org/?p=linux/kernel/git/roland/infiniband.git;a=commit;h=2fadea9acc19674c07ae7a9d90758f4b9b793940
> 
> It's not yet guaranteed that it will be accepted, but it looks good so  
> far.  With some bug fixes from Pasha/Mellanox and Lenny+Mike/Voltaire,  
> I think it's ready for wide-spread testing (I mailed some of you  
> yesterday asking for specific testing).  I'm asking all to give the  
> prototype code a whirl to shake out any remaining design bugs.

Good to hear this long-standing issue is getting the attention it
deserves, this will be a huge step forward when it's up and running.

Ashley,

-- 

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk