Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support different byte orders in serializer #1295

Open
vtjnash opened this issue Sep 20, 2012 · 5 comments
Open

support different byte orders in serializer #1295

vtjnash opened this issue Sep 20, 2012 · 5 comments
Labels
domain:io Involving the I/O subsystem: libuv, read, write, etc. kind:breaking This change will break code status:needs decision A decision on this change is needed

Comments

@vtjnash
Copy link
Sponsor Member

vtjnash commented Sep 20, 2012

In the serializer (and elsewhere?), array reads and writes probably should be done in network byte order.

@StefanKarpinski
Copy link
Sponsor Member

God no. Network byte order needs to die. There's nothing better about it. If anything, the serializer should have a BOM in the header of the data stream and conditionally translate from the serialized order, which ought to be native to the sender, to the native order of the receiver. Alternatively, the receiver can just die if the BOM doesn't match its local endianness. Who the hell runs a cluster with heterogenous endianness? That's a silly thing to do.

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Sep 27, 2012

It's better only in that it is consistant. Isn't Serialization used for writing files too? Adding a header with endianness makes sense too (since it reduces work for the common case of little-endian to little-endian). I was talking with Jeff about making a few changes to the structure of the serialization protocol, to make it more robust against other sorts of data corruption issues.

@StefanKarpinski
Copy link
Sponsor Member

My general opinion on endianness and serialization formats is that byte swapping should be done lazily even for writing files because by far the most common case is that you are communicating between machines with the same endianness. Moreover, these days it is almost certainly little-endian, especially since Julia doesn't even run on any big-endian architectures. Are there any common big-endian architectures that people even use these days?

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Sep 27, 2012

PowerPC (the only other architecture currently supported by the LLVM JIT) is big/bi-endian. It shows up in FPGAs (e.g. Xilinx Virtex 4/5), all modern game consoles (e.g. XBox360, Wii and PS3 are big-endian), high-performance computers[citation needed], and old apple computers (which are stuck at Mac OS 10.5).

ARM is little/bi-endian. So it can be used in big-endian mode (although it appears that Android generally uses little-endian everywhere).

@StefanKarpinski
Copy link
Sponsor Member

Ok, well, it sounds like something we ought to plan to accommodate, but not at the expense of making the vastly most common case of little-endian-to-little-endian do lots of pointless byte swapping.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:io Involving the I/O subsystem: libuv, read, write, etc. kind:breaking This change will break code status:needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

4 participants