[Mpi3-tools] Meeting Minutes / Hot Button Issues / Next Meeting

Jeff Squyres jsquyres at cisco.com
Fri Aug 14 08:02:00 CDT 2009


On Aug 12, 2009, at 3:09 PM, John DelSignore wrote:

> > It strikes me that TVT/Allinea might have experience in this area
> > (general name/type/value registration).
>
> Sorry, I couldn't attend the concall, so I'm not sure I follow 100%  
> what you are trying to accomplish.
>
> Representing a type is not too complicated, but that depends on the  
> language (C, C++, Fortran, etc) and the kind of type (e.g., integer,  
> float, complex, aggregate, array, pointer, reference, etc.).  
> Generally, debug information schemes like STABS and DWARF (which are  
> commonly used on most Unix systems), allow the compiler and language  
> to name the type, and provide the properties of the type. For  
> example, "int" in C may be the same kind of type as "INTEGER*4" in  
> Fortran: e.g., a 4-byte signed integer.
>


The general idea here was that the proposal was seeking to have a  
registration system that MPI implementations could register a variety  
of run-time tunable parameters and run-time available information  
values -- we talked about this on a con call when the Forum was  
meeting in Chicago.  We continued the discussion the other day, but it  
devolved into "we need lots of different types" / "do the types need  
to match the MPI datatypes" / "do we need to MPI_SEND/MPI_RECV these  
values around" / "what about complex types?" / etc.

I suggested that the proposal authors should look to other sources for  
inspiration rather than re-invent the wheel (if possible) because this  
problem space shares many similarities with other systems.  For  
example, CORBA-like systems have long since "solved" the serialization/ 
de-serialization issue (ser/de-ser is a different problem, but it  
shares many similar characteristics).  And debuggers already have a  
system for identifying types of symbols in executables, printing and  
assigning the correct types to them interactively at run-time, etc.

At their heart, these systems are just mappings of names to meta types  
(like type, value, etc.).  I'm just suggesting that we look to others  
to see if there's knowledge / techniques that might be useful to re- 
use here rather than make it up anew, possibly ignoring some hard-won  
knowledge that others have gleaned from doing similar / analogous  
systems.

Hopefully that rambling made sense...

-- 
Jeff Squyres
jsquyres at cisco.com




More information about the mpiwg-tools mailing list