I'd like to start a discussion and see if we can reach some reasonable
consensus on whether big-endian is acceptable to the community. I
think this is an important issue, as a little-endian Linux/IA-64 is
going to make it a second choice for a significant number of
people. This reason for this follows (from my orginal message to
David):
[Original message]
I write visualisation software for astronomy. This software is used
all over the world, and often has to deal with very large
datasets. It's not uncommon to "load" a dataset (a cube) but only view
a small portion of it (a single plane (channel) of the cube). On
big-endian machines I can avoid loading data and instead use memory
mapping, because all the portable binary data formats are big-endian
(FITS, Miriad and my own).
Being able to memory map a gigabyte dataset makes "loading" extremely
fast. It also means you don't need stacks of swap space.
In the astronomy community, big-endian machines dominate (despite the
growth of Linux/x86), and will always be favoured because the most
important data format (FITS) is big-endian. When we tender for a new
supercomputer, it is a requirement that it be big-endian.
BTW: FITS has become a NIST standard and is widely used outside the
astronomy community.
So, even though Linux/x86 is the most common Linux, I really don't
think it justifies making Linux/IA-64 little-endian. Remember that
there is already the difference in word size, so the two platforms are
not going to have semi-seamless migration of data anyway. And for
scientific applications, big-endian is the standard.
If Linux/IA-64 is little endian, it will always be a second choice
after Sun Sparc and SGI MIPS in the astronomy community and probably
the science community as well.
I implore you: please reconsider your decision. Don't punish Linux
because of the x86 legacy.
[End]
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/