The Case Against Big Endian

In September 2025, Linus Torvalds responded to a request for merging big endian RISC-V code with characteristic bluntness:

Oh Christ. Is somebody seriously working on BE support in 2025?

He continued:

This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.

The message is clear: big endian's time has passed.

The State of Big Endian Today

Big endian architectures are vanishingly rare. Even processors that technically support big endian—like Arm and Power—are bi-endian by design, and both ecosystems are actively shifting toward little endian. Most Linux distributions don’t even ship big endian images for these platforms anymore.

The deprecation is now official. In the Linux kernel, arm64 big endian support has been marked as broken—the first step toward complete removal. The rationale from the kernel maintainers is instructive:

Big-endian arm64 configurations are vanishingly rare, yet we still claim to support them in Linux despite very limited testing or visible interest. Supporting big-endian adds unnecessary burden to reviewers and contributors which, without any known active users, is hard to justify. For example, recent work to improve our futex routines and to implement nested virtualisation support is non-trivially complicated by having to support both big- and little-endianness.

They cite real costs: recent work on futex routines and nested virtualization support became “non-trivially complicated” by the requirement to support both endiannesses.

Big endian support isn’t just legacy—it’s actively being removed.

But What About Networking?

The theoretical case for big endian usually centers on networking. Network protocols use big endian byte order (often called “network byte order”), so processors handling heavy network traffic should benefit from native big endian support, right?

Not really.

Modern architectures include efficient byte swap instructions. The RISC-V Zbb extension that Torvalds mentioned provides exactly this. On x86-64, the bswap instruction takes just two cycles.

Is two cycles significant? Consider the context:

• A bswap costs the same as writing to memory twice
• A typical C function call costs dozens of cycles
• A system call can cost thousands of cycles

Network devices make enormous numbers of function calls and system calls. In that context, two cycles for a byte swap is noise. Unless you’re writing hand-optimized assembly—and if you’re writing in C, you’ve already accepted far larger overhead—those two cycles simply don’t matter.

The Bottom Line

If you’re contemplating big endian support for a new project in 2025, think again. The ecosystem has moved on. The maintenance burden is real. The theoretical performance benefits are illusory.

Big endian had its moment. That moment has passed.