[Mpi3-subsetting] agenda for subsetting kickoff telecon ww09
Supalov, Alexander
alexander.supalov at [hidden]
Fri Feb 29 14:54:18 CST 2008
Hi,
Thanks. I was thinking privately about MPI_Init_subsets or so that would
use an Info object, too. I bet a comparable idea - or at least desire to
keep the number of subset related calls under strict control - was aired
at the telecon by someone, but we didn't go into much detail then.
One reservation I have about Info objects is that they are so flexible
as to be dangerous. They promoting lots of optional, loosely controlled
features that can effectively blur the interface definition. On the
other hand, I don't see any viable alternative to that, at least if the
number of subsets is going to be substantial and ever growing.
Of course, it's a little too early to fix any implementation details I'm
afraid. Anyway, let's keep this idea in mind while we're settling the
scope.
Best regards.
Alexander
-----Original Message-----
From: mpi3-subsetting-bounces_at_[hidden]
[mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of Jeff
Squyres
Sent: Friday, February 29, 2008 9:29 PM
To: mpi3-subsetting_at_[hidden]
Subject: Re: [Mpi3-subsetting] agenda for subsetting kickoff telecon
ww09
On Feb 28, 2008, at 11:29 PM, Supalov, Alexander wrote:
> - Communicator & group management: better memory footprint.
Take this point to an extreme - it may be possible to say "this app
only uses MPI_COMM_WORLD". In this case, you can remove the
communicator field from network packets for a small gain in latency,
or perhaps reduce it from 4 to 2 bytes or 1 byte (e.g., if an app says
"I'll only use 4 communicators").
> - Message tagging: better support for stable dataflow exchanges,
> smaller
> packets.
Two points here:
- allow app to eliminate MPI_ANY_TAG
- just like with communicators, allow the app to say "I'll only use N
tags", where N can save you space in network packets (e.g., if N==1,
no need for tag on the wire; if N == 2, then you only need 1 byte for
the tag, etc.).
> - Non-blocking communication: easier ordering, simplified request
> handling.
If there is no non-blocking communication, enormous chunks of the
progression engine can be optimized in terms of memory (i.e., remove
lots of now-unnecessary code) and probably a little speed.
On the teleconf (sorry I missed it), was there discussion of how to
specify these hints? Perhaps a new function: MPI_INIT_INFO (pass an
MPI_Info handle to MPI_INIT)? Or is it something that needs to be
specified at compile/link time?
--
Jeff Squyres
Cisco Systems
_______________________________________________
Mpi3-subsetting mailing list
Mpi3-subsetting_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting
---------------------------------------------------------------------
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 Mpi3-subsetting
mailing list