One other issue is that we'd have to make [at least some of] the MPI_Info_* functions be able to be called before MPI_INIT. On Feb 29, 2008, at 3:54 PM, Supalov, Alexander wrote:

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.

_______________________________________________ Mpi3-subsetting mailing list Mpi3-subsetting_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting

-- Jeff Squyres Cisco Systems