[Mpi-22] mpi-22 Digest, Vol 2, Issue 7

Supalov, Alexander alexander.supalov at [hidden]
Mon May 5 13:02:01 CDT 2008



Woops... Read "dynamic processes" rather than "one-sided". Partial
update, sorry.

-----Original Message-----
From: mpi-22-bounces_at_[hidden]
[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov,
Alexander
Sent: Monday, May 05, 2008 7:54 PM
To: MPI 2.2
Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7

Hi,

We may want to see whether communicator-bound restriction will help down
there. For example, even one communicator with dynamic processes enabled
may "taint" the progress engine enough to make any saving from the
absence of one-sided elsewhere disappear.

On the other hand, attaching attributes to the MPI_COMM_WORLD, although
not fully clean and properly timed, might be a way to spread the
assertions across the job, and let libraries cut their proper part out.
Same with windows and files, by the way. How and when will this pass
down to the progress engine? I don't know. Do you?

Best regards.

Alexander

-----Original Message-----
From: mpi-22-bounces_at_[hidden]
[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres
Sent: Monday, May 05, 2008 7:31 PM
To: MPI 2.2
Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7

On May 5, 2008, at 1:28 PM, Supalov, Alexander wrote:

> Thank you. We can actually introduce what you propose, possibly with  
> a query function to make it still easier to live with, as early as  
> in MPI 2.2, as a subset precursor. Judging by the discussion in  
> Chicago, subsets may not need much more than that in the end,  
> possibly with a little more flags and semantics added in MPI-3.
>
> The reservation against 32- (or for that matter, 64-) bit limitation  
> is the only one I have at the moment. Not being able to attach  
> assertions to communicators, etc. may be missed by some advanced  
> programmers, but here we need to be pragmatic: who will ever want to  
> go that deep?

Libraries that build on top of MPI may want to.  This was one of the  
prime motivations for communications, right?  (private/safe  
communications)  As Quincy stated in Chicago and on the mailing list  
(IIRC), what if a top-level app sets an assertion that a library using  
MPI can't live with?  Being able to set them per-communicator might  
alleviate that issue.


-- 
Jeff Squyres
Cisco Systems
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.




More information about the Mpi-22 mailing list