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
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
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?
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
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:
>
>>
- "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
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
WHAT: MCA parameter for converting all standard mode MPI sends to
synchronous mode sends
WHY: helpful in debugging user apps
WHERE: here's the output from "svn st"
M ompi/runtime/params.h
M ompi/runtime/ompi_mpi_params.c
M ompi/mpi/c/send.c
M ompi/mpi/c/send_init.c
M
20 matches
Mail list logo