When teaching recently about the Big vs. Little Endian battle, a student asked whether it had been settled, and I realized I didn't know. Looking at the Wikipedia article, it seems that the most popular current OS/architecture pairs use Little Endian but that Internet Protocol specifies Big Endian for transferring numeric values in packet headers. Would that be a good summary of the current status? Do current network cards or CPUs provide hardware support for switching byte order?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
I'd argue that it's not so much won as ceased to matter. ARM which makes up basically all of the mobile market is bi-endian (oh, the heresy!). In the sense that x86 basically "won" the desktop market I suppose you could say that little endian won but I think given the overall code depth (shallow) and abstraction (lots) of many of today's applications, it's much less of an issue than it used to be. I don't recall endianness really coming up in my Computer Architecture class.
I suspect that many developers aren't even aware of endianness or why it's important. Because for the vast (and I mean vast) majority it's utterly irrelevant to their daily working environment. This was different 30 years ago when everyone was coding much closer to the metal as opposed to manipulating text files on a screen in fancy and dramatic ways.
My general suspicion is that Object Oriented Programming was the beginning of the end of caring about endianness since the layers of access and abstraction in a good OO system hide implementation details from the user. Since implementation includes endianness, people got used to it not being an explicit factor.
Addendum: zxcdw mentioned portability being concern. However, what has arisen with a vengeance in the last 20 years? Programming Languages built on virtual machines. Sure the virtual machine endianness might matter but it can be made very consistent for that one language to the point where it's basically a non-issue. Only the VM implementors would even have to worry about endianness from a portability standpoint.
Endians only really matters when you are transferring binary data systems.
With the advancement of processor speed (and much much lower cost of storage) binary data interfaces are becoming rarer so you don't notice them at the application layer. You are either using a textual transfer format (XML/JSON) or you are using data layer abstraction that takes care of the translation for you (so you don't even notice that there is a translation).
But when you are coding at the binary data layer you do notice and it is very important. For example When I worked at VERITAS (Symantec now) I was building software that was being built on 25 different hardware platforms (not only big/little endian there are other types).
No, nobody has won. We as a species we have failed to standardize the order in which we store our bytes, along with the direction we write and the side of the street we drive on.
As a consequence, anyone who wants to transfer data between two different systems over a network or in a file, has only about a 50% chance of the reasonable initial version of their data dumping code being correct in their environment, and even if it works, has a 50% chance of working in their customer's.
To deal with this you need to go look up platform specific functions with names like "htonl" in headers with names obviously dating back to the 70's like "arpa/inet.h", because the situation has not improved since then and probably never will.
There is still no consensus:
So at the hardware level, LE is far more common. But:
Both orders are going to be with us for the foreseeable future.