In article <11************ **********@o13g 2000cwo.googleg roups.com>,
Pe*******@gmail .com <Pe*******@gmai l.com> wrote:
Walter Roberson wrote: In article <Q1************ *****@newsread2 .news.atl.earth link.net>,
Martin Ambuhl <ma*****@earthl ink.net> wrote: >Pe*******@gmai l.com wrote:
>> I write the content of a in file "data" (in Sun Machine). Then I read
>> "data" in both SunOS and linux. But the result is different. Do you
>> know how to make it binary data portable.
The "xdr" library (which is NOT part of the C standard itself) was
written to try to deal with these issues.
Do you have a rough idea how much performance will be lost using xdr
instead of using native representations , when I don't have to use xdr?
No, I can't rightly say that I do.
SunOS is an operating system, which is produced for multiple
processors.
Linux is an operating system, which is produced for a wide variety
of processors.
Telling us that you are taking the data from SunOS to Linux
narrows down the source data representations to one of a few,
but leaves the destination data representation pretty wide open.
We can't meaningfully speak about "efficiency " without knowing
the hardware details of the source and destination computers
and of exactly how the data is to be processed. For example,
if the data is just sitting around on the Sun box and you
write a program that does nothing other than read it there,
serialize it, copy it to the Linux box, and deserialize it,
and you run that program in the background, then how much
"efficiency " is lost compared to getting faster but incorrect
answers due to having used incompatible binary formats ?
Were you aware that even if both sides happen to use IEEE 754
repesentations, that merely doing byte-order conversions is not
sufficient ? IEEE 754 nails the representation for most
arithmetic values, but there are values that the implementation is
given more flexibility for. IEEE 754 includes representations
for positive and negative infinities, negative zero, various
signaling numbers, de-normalized numbers, and sets of
"Not A Number" (NaN). The available denormalized numbers and
NaN are especially implementation dependant if my memory serves
me correctly.
You didn't tell us anything about the characteristics of the binary
data, so we must assue that you are using "long double" on the Sun, and
that the data includes some of the IEEE 754 special cases. And since
you didn't tells us anything about the destination Linux system, we
must assume that it is a bit-sliced machine that uses either
one's-complement or seperate-sign and that it doesn't have "long
double" available at all.
--
The rule of thumb for speed is:
1. If it doesn't work then speed doesn't matter. -- Christian Bau