Richard Graham wrote:
> First, the performance improvements look really nice.
> A few questions:
> - How much of an abstraction violation does this introduce ? This
> looks like the btl needs to start “knowing” about MPI level semantics.
> Currently, the btl purposefully is ulp agnostic. I ask for
If all write to the same destination at the same time - yes. On older systems
you could start to see drgradation around 6 procs, but things heald up ok
further out. My guess is that you want one such queue per n procs, where n
might be 8 (have to experiment), so polling costs are low and memor
I believe the situation that is causing the error has to do with GCC's
FORTIFY_SOURCE. I'm building under CentOS 5.2 using the 1.3 src.rpm
available on the website:
% gcc -DHAVE_CONFIG_H -I. -I.. -I../tools/opari/lib -I../extlib/otf/otflib
-I../extlib/otf/otflib -D_GNU_SOURCE -DBINDIR=\"/usr/bin
You need to add --tag-output - this is a separate option as it applies
both to xml and non-xml situations.
If you like, I can force tag-output "on" by default whenever -xml is
specified.
Ralph
On Jan 16, 2009, at 12:52 PM, Greg Watson wrote:
Ralph,
Is there something I need to do to en
You sholud be able to use the OOB by that point in the system.
However, that is the incorrect entry point for sending messages - you
need to enter via the RML. The correct call is to orte_rml.send_nb.
Or, if you are going to send a buffer instead of an iovec, then the
call would be to orte_
Yes, _FORTIFY_SOURCE does a lot of pedantic things -- google around
and you'll find out what it does. FWIW, we had to make some other
changes in OMPI to handle _FORTIFY_SOURCE as well.
On Jan 20, 2009, at 9:17 AM, Jonathan Billings wrote:
I believe the situation that is causing the error h
I don't think there's any reason we'd want stdout/err not to be
encapsulated, so forcing tag-output makes sense.
Greg
On Jan 20, 2009, at 9:20 AM, Ralph Castain wrote:
You need to add --tag-output - this is a separate option as it
applies both to xml and non-xml situations.
If you like, I
Hi Ralph,
I'm quite embarrassed, I misread the function prototype and was passing in
the actual proc_name rather than a pointer to it! It didn't complain when I
was compiling so I didn't think twice. It was silly mistake on my part in
any case! That RML tip is still handy though, thanks.
Cheers
T
Ralph,
The encapsulation is not quite right yet. I'm seeing this:
[1,0]n = 0
[1,1]n = 0
but it should be:
n = 0
n = 0
Thanks,
Greg
On Jan 20, 2009, at 9:20 AM, Ralph Castain wrote:
You need to add --tag-output - this is a separate option as it
applies both to xml and non-xml situations.
Ah - no problem! Glad it was simple.
Be aware that the RML is the layer responsible for routing OOB
messages. So if you go through the OOB interface, you lose all message
routing - which means forcing open additional connections and
potentially confusing the system.
We should undoubtedly
This problem has been fixed (thankfully, it occurred after the v1.3
tarballs were made).
The problem is that ftp.gnu.org has disabled repository downloads of
config.guess and config.sub while some git vulnerability is being
fixed. Hence, the scripts that we downloaded while making the
ta
I'm embarrassed to admit that I never actually implemented the xml
option for tag-output...this has been rectified with r20302.
Let me know if that works for you - sorry for confusion.
Ralph
On Jan 20, 2009, at 8:08 AM, Greg Watson wrote:
Ralph,
The encapsulation is not quite right yet. I
Has now been updated to include v1.3.1 tickets:
https://svn.open-mpi.org/trac/ompi/report/14
Enjoy.
--
Jeff Squyres
Cisco Systems
Richard Graham wrote:
Re: [OMPI devel] RFC: sm Latency
First, the performance improvements look
really nice.
A few questions:
- How much of an abstraction violation does this introduce?
Doesn't need to be much of an abstraction violation at all if, by that,
we mean teaching the BTL about
Looks good now. Thanks!
Greg
On Jan 20, 2009, at 12:00 PM, Ralph Castain wrote:
I'm embarrassed to admit that I never actually implemented the xml
option for tag-output...this has been rectified with r20302.
Let me know if that works for you - sorry for confusion.
Ralph
On Jan 20, 2009,
Hi Eugene,
Eugene Loh wrote:
>> replace the fifo’s with a single link list per process in shared
>> memory, with senders to this process adding match envelopes
>> atomically, with each process reading its own link list (multiple
> *) Doesn't strike me as a "simple" change.
Actually, it's muc
On Jan 18, 2009, at 8:59 PM, Jeremy Espenshade wrote:
libtool: compile: ppc_4xx-gcc -DHAVE_CONFIG_H -I. -I../../adio/
include -DOMPI_BUILDING=1 -I/home/jeremy/Desktop/openmpi-1.2.8/ompi/
mca/io/romio/romio/../../../../.. -I/home/jeremy/Desktop/
openmpi-1.2.8/ompi/mca/io/romio/romio/../../../.
What: Adding OMPI_CHECK_WITHDIR checks in various .m4 files
Why: Help prevent user errors via --with-=DIR configure options
Where: config/*m4 and */mca/*/*/configure.m4 files, affecting the
following environments:
- bproc (***)
- gm (***)
- loadleveler (***)
- lsf
- mx (***)
- open fabrics
-
Patrick Geoffray wrote:
>Eugene Loh wrote:
>
>
>>>replace the fifo’s with a single link list per process in shared
>>>memory, with senders to this process adding match envelopes
>>>atomically, with each process reading its own link list (multiple
>>>
>>>
>>*) Doesn't strike me as a "sim
This all sounds really great to me. I agree with most of what has
been said -- e.g., benchmarks *are* important. Improving them can
even sometimes have the side effect of improving real applications. ;-)
My one big concern is the moving of architectural boundaries of making
the btl under
On Jan 20, 2009, at 8:53 PM, Jeff Squyres wrote:
This all sounds really great to me. I agree with most of what has
been said -- e.g., benchmarks *are* important. Improving them can
even sometimes have the side effect of improving real
applications. ;-)
My one big concern is the moving
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
hopefully will be the de
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 violation does this introduce?
> Doesn't need to be much of an abstraction violati
On 1/20/09 8:53 PM, "Jeff Squyres" wrote:
> This all sounds really great to me. I agree with most of what has
> been said -- e.g., benchmarks *are* important. Improving them can
> even sometimes have the side effect of improving real applications. ;-)
>
> My one big concern is the moving o
Eugene,
All my remarks are related to the receive side. I think the send side
optimizations are fine, but don't take my word for it.
Eugene Loh wrote:
> To recap:
> 1) The work is already done.
How do you do "directed polling" with ANY_TAG ? How do you ensure you
check all incoming queues from t
25 matches
Mail list logo
