I think it is possible to have a standard AND have good performance.
The key is to adopt a standard that is based upon fixing a data format
DESCRIPTION rather than fixing the data format itself. Approahces like
XDR, which always store in a canonical form, force conversion on send
AND recv (or alternatively read and write) even if source and
destination have compatible formats. If, however, you decide to agree on
how to DESCRIBE the format rather than on a given canonical format, you
can guarentee that conversion occurs ONLY when source and destination
are incompatible. Look at Lawrence Livermore Lab's PDB (Portable Data
Base) product by Stewart Brown to see how it handles numeric format
conversion. It uses a parameter-value language sufficient to
characterize all integer and floating point formats that have been in
use by past and present CPUs and which are ever likely to exist in
future CPUs.
For example, PDB stores and manages knowledge of floating point
representations with parameters such as...
a. # of mantissa bits
b. # exponent bits
c. # sign bits
c. exponent bias
d. exponent base
e. byte order
f. bit-offset of start of mantissa
g. bit-offset of start of exponent
h. bit-offset of start of sign
When bytes are read from a file, the "in-memory" description of the
floating point format is compared with the "in-file" description of the
floating point format. If they are identical, no conversion is
performed, if they are different, a conversion routine is called.
Furthermore, one can write a single, generic conversion routine that
will convert from any one reprsentation describable by the
parameter-value language to any other. Even furthermore, because such a
routine is very general, it can be improved by writing specialized
routines that handle conversion between specific instances of two
formats AS THE NEED ARISES. Finally, if it is known in advance that
conversion is going to be necessary (for example, you compute on a Cray
but will visualize on an SGI), you can target the conversion to occur on
either read or write. Thus, if you expect to write once on a Cray but
read multiple times on the SGI, you can target the conversion to occur
during write on the Cray so that when it is read on the SGI, no
conversion will be necessary. PDB has been doing this for years here at
LLNL.
Mark Miller
LLNL
miller@viper.llnl.gov