Ron Brightwell wrote:
If you poll only the queue that correspond to a posted receive, you only optimize micro-benchmarks, until they start using ANY_SOURCE.
Note that the HPCC RandomAccess benchmark only uses MPI_ANY_SOURCE (and
MPI_ANY_TAG).
But HPCC RandomAccess also jus
Patrick Geoffray wrote:
Eugene Loh wrote:
Possibly, you meant to ask how one does directed polling with a
wildcard source MPI_ANY_SOURCE. If that was your question, the
answer is we punt. We report failure to the ULP, which reverts to
the standard code path.
Sorry, I meant ANY_SOURCE. If
> > Possibly, you meant to ask how one does directed polling with a wildcard
> > source MPI_ANY_SOURCE. If that was your question, the answer is we
> > punt. We report failure to the ULP, which reverts to the standard code
> > path.
>
> Sorry, I meant ANY_SOURCE. If you poll only the queue th
Eugene Loh wrote:
Possibly, you meant to ask how one does directed polling with a wildcard
source MPI_ANY_SOURCE. If that was your question, the answer is we
punt. We report failure to the ULP, which reverts to the standard code
path.
Sorry, I meant ANY_SOURCE. If you poll only the queue th
Can you send the information listed here:
http://www.open-mpi.org/community/help/
On Jan 21, 2009, at 5:25 PM, David Robertson wrote:
Hello,
I'm having a problem with MPI_COMM_WORLD in Fortran 90. I have tried
with OpenMPI versions 1.2.6, 1.2.8 and 1.3. Both versions are
compiled wit
Hello,
I'm having a problem with MPI_COMM_WORLD in Fortran 90. I have tried
with OpenMPI versions 1.2.6, 1.2.8 and 1.3. Both versions are compiled
with the PGI 8.0-2 suite. I've run the program in a debugger and with
"USE mpi" and MPI_COMM_WORLD returns 'Cannot find name
"MPI_COMM_WORLD"'. If
Can't speak officially for the VT folks, but it looks like the following
bits in ompi/vt/vt/acinclude.m4 needs to list SPARC and Alpha (maybe
ARM?) along side MIPS as gettimeofday() platforms. Alternatively
(perhaps preferred) one should turn this around to explicitly list the
platforms that *
Appropriate mapper components will be used, along with a file
describing which nodes are in which CU etc. So it won't be so much a
matter of discovery as pre-knowledge.
On Jan 21, 2009, at 12:02 PM, Jeff Squyres wrote:
Sounds reasonable. How do you plan to discover this information?
On J
Sounds reasonable. How do you plan to discover this information?
On Jan 21, 2009, at 9:58 AM, Ralph Castain wrote:
What: Extend the current use of the ompi_proc_t flags field (without
changing the field itself)
Why: Provide more atomistic sense of locality to support new
collective/BTL co
The Debian OMPI maintainers raised a few failures on some of their
architectures to my attention -- it looks like there's some wonkyness
on Debian on SPARC and Alpha -- scroll to the bottom of these two pages:
http://buildd.debian.org/fetch.cgi?&pkg=openmpi&ver=1.3-1&arch=sparc&stamp=12325135
Patrick Geoffray wrote:
Eugene Loh wrote:
To recap:
1) The work is already done.
How do you do "directed polling" with ANY_TAG ?
Not sure I understand the question. So, maybe we start by being
explicitly about what we mean by "directed polling".
Currently, the sm BTL h
What: Extend the current use of the ompi_proc_t flags field (without
changing the field itself)
Why: Provide more atomistic sense of locality to support new
collective/BTL components
Where: Add macros to define and check the various flag fields in ompi/
proc.h. Revise the orte_ess.proc_is_
Brian is referring to the "rdma" onesided component (OMPI osd
framework) that directly invokes the BTL functions (vs. using the PML
send/receive functions). The osd matching is quite different than
pt2pt matching.
His concern is that that model continues to work -- e.g., if the rdma
osd
Richard Graham wrote:
On 1/20/09 8:53 PM, "Jeff Squyres" wrote:
Eugene: you mentioned that there are other possibilities to having the
BTL understand match headers, such as a callback into the PML. Have
you tried this approach to see what the performance cost would be,
perchance?
Richard Graham wrote:
Re: [OMPI devel] RFC: sm Latency
On 1/20/09 2:08 PM, "Eugene Loh" wrote:
Richard Graham wrote:
Re: [OMPI devel] RFC: sm Latency First, the
performance improvements look really nice.
A few questions:
- How much of an abstraction v
Brian Barrett wrote:
I unfortunately don't have time to look in depth at the patch. But
my concern is that currently (today, not at some made up time in the
future, maybe), we use the BTLs for more than just MPI point-to-
point. The rdma one-sided component (which was added for 1.3 and
h
16 matches
Mail list logo