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
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,
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?
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
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
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
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
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
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
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
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
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
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
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
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 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
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
17 matches
Mail list logo
