Re: [OMPI devel] RFC: sm Latency

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

Re: [OMPI devel] RFC: sm Latency

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

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 violation does this introduce? > Doesn't need to be much of

Re: [OMPI devel] RFC: sm Latency

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

Re: [OMPI devel] RFC: sm Latency

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

Re: [OMPI devel] RFC: sm Latency

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

Re: [OMPI devel] RFC: sm Latency

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

[OMPI devel] RFC: Adding OMPI_CHECK_WITHDIR checks

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 -

Re: [OMPI devel] Make Error: io_romio_ad_wait.c

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/

Re: [OMPI devel] RFC: sm Latency

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

Re: [OMPI devel] -display-map

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,

Re: [OMPI devel] RFC: sm Latency

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

[OMPI devel] trac report 14

Has now been updated to include v1.3.1 tickets: https://svn.open-mpi.org/trac/ompi/report/14 Enjoy. -- Jeff Squyres Cisco Systems

Re: [OMPI devel] -display-map

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.

Re: [OMPI devel] === CREATE FAILURE (v1.3) ===

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

Re: [OMPI devel] When can I use OOB channel?

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

Re: [OMPI devel] -display-map

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.

Re: [OMPI devel] When can I use OOB channel?

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

Re: [OMPI devel] -display-map

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,

Re: [OMPI devel] -display-map

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

Re: [OMPI devel] OpenMPI rpm build 1.3rc3r20226 build failed

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

Re: [OMPI devel] RFC: sm Latency

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

Re: [OMPI devel] RFC: sm Latency

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