On Aug 24, 2009, at 9:24 PM, Patrick Geoffray wrote:
Ralph Castain wrote:
Not quite that simple, Patrick. Think of things like MPI_Sendrecv,
where the "send" call is below that of the user's code.
You have a point, Ralph. Although, that would be 8 more lines to add
to the user MPI code to
Ralph Castain wrote:
Not quite that simple, Patrick. Think of things like MPI_Sendrecv, where
the "send" call is below that of the user's code.
You have a point, Ralph. Although, that would be 8 more lines to add to
the user MPI code to define a MPI_Sendrecv macro :-)
Seriously, this particu
- "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.
Yes, but have yet to be able to persuade any of our users
to use them (and have no control over them). :-(
--
Christopher Samu
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
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, h
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,
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'
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 --m
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 stat
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 Squy
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 co
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 understan
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 le
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 w
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
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
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 t
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 sug
- "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 mo
Given the limited scope, would it make sense to somehow add this to the
trace library (or a separate debug lib) - i.e., can we do it via a lib that
inserts itself between the MPI binding and PMPI call? I would hate to
duplicate the code in something like sendrecv, but I wonder if we could
refactor
21 matches
Mail list logo
