From: Rolf Rabenseifner Subject: Re: MPI-2 standard issues - MPI_Type_create_f90_... To: Nicholas.Nevin@XXXXXXXXXXXX Date: Mon, 12 Feb 2001 10:27:10 +0100 (CET) Cc: Rabenseifner@XXXXXXXXXXXXXXXXXXXX,In-Reply-To: <20010209133718.A20577@XXXX>, 2001 01:37:18 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Nick: > > > > >2. Why the restriction that types obtained from calls to > > > > >MPI_Type_create_f90_{real,complex,integer} cannot be freed? This .... Rolf: > > Sorry, but this would really change the MPI-2 standard. > > MPI-2 allows to return always the same handle, and not a dup. > > And to save memory, the best is that > > > > - MPI_Type_get_envelope returns the original (predefined) handle > > and not a dup (no costs!) Nick: > Only for predefined types. Yes, and MPI-2 page 293 lines 16-33 clearly say that MPI_Type_create_f90_{real,complex,integer} returns a predefined type (and not a derived type!) > > (--> therefore no reason for freeing it!) ... > I don't think that the proposed correction changes the standard significantly. > Programs which currently work should continue to work and the proposed change will > allow proper cleanup by applications which wish to do so. > > IMO standards should not rely on assumptions like the one you make above, > i.e. "application will only use dozens of such datatypes". It is up to the implementors to find a good immplementation according to the MPI-2, page 293, lines 34-37. I.e. it may be necesary to resize the hash table if an application uses more than 100, 1000, 10000 ... datatypes. > Note that the requirements for MPI_Type_get_contents also > mean that MPI_Type_create_f90_* must return a distinct handle for each > possible range/precision. If these handles cannot be freed this could > cause problems for implementations which restrict the number of handles > which can be in use at any one time. I believe, (a) that this is no problem and (b) that it is possible to handle the parameterized predefined datatypes in a way, that does not need any restrictions: (a) You think about a lot of semantically different parameterized datatypes. Because sender and receiver must use the same datatype, it cannot depend on actual values. It must depend on an estimate about the expected range. This estimate will not be done with thousands of different values. If it is done a lot of time with identical values, then you have no problem with restricting the number of handles. (b) If you really want to support a restricted number of derived datatypes and all predefined (basic & parameterized) datatypes, than you could use some ticky structures for a (32 bit) datatype handle: 1 bit is_parameterized if is_parameterized 23 bit for r (REAL*16 has only a 15 bits exponent) 6 bit for p (allows mantissas with up to 64 decimal digits = about 214 bits mantissa) 2 bit for type (real,complex,integer) else index into an array of datatypes The first 3 entries in that array can be used for all other description of the parameterized dataytypes Therefore, - I do not see, that a change of the MPI-2 standard is necessary, - nor would I agree that this would be a small change. Rolf Dr. Rolf Rabenseifner High Performance Computing Parallel Computing Center Stuttgart (HLRS) Rechenzentrum Universitaet Stuttgart (RUS) Phone: ++49 711 6855530 Allmandring 30 FAX: ++49 711 6787626 D-70550 Stuttgart rabenseifner@XXXXXXXXXXXXXXXXXXXX Germany http://www.hlrs.de/people/rabenseifner