Hacker News Reader

Comment by ajross | Hacker News Reader

Little endian is also better for multi-word addition/subtraction. Your first operand will be the low word, which your pointer conveniently already indexes. This was a classic trick in the days of 8 and 16 bit systems, and assembly code for modern modular crypto systems still uses it.

Really I think consensus is that the industry focus on big endian systems was actually a mistake. It prioritized programmer comfort in a regime where it never really mattered.

View on HN

Yes, LE is actually the more logical and elegant one, since bit n has weight 2^n, and byte n has a weight 256^n. The BE equivalents introduce an extra length- term into the equation (length-n).

I've always found LE vs BE to be somewhat like 0- vs 1-based array indices; one is more "conventional" to a human, but the other doesn't require a lot of contortions when expressed algebraically or algorithmically.

(With 0-based indices, element i is at address base + i * size; with 1-based indices, it's base + (i-1) * size, and it only gets worse from there as you add dimensions and other calculations.)

Or you could just decrement base.

This also conveniently allows you to store the length at the "real" base.

    0 array length <--- base pointer
    1 element 1    <--- array[1] == *(base + 1)
    2 element 2    <--- array[2] == *(base + 2)

0-based offsets

OTOH, big-endian is better for comparison; you can tell when one integer is larger than another by looking at as little as just one bit, from the most significant end.

But comparison is done in registers which don't have a byte order. Unless you mean doing something like 256bit_a > 256bit_b which I would think it's a very rare operation. Good point though.

In the worst case, comparison is still like subtraction.

Even if the whole datum is examined, comparison is more parallelizable; it doesn't require carry propagation.

That's only an scalar code optimization though. You can still do comparison in constant time on little endian data, you just lack the ability to early-exit from the loop. In the modern world of SIMD data, that optimization often doesn't exist. Fair enough point though.

To follow up on this, I recently implemented a packed vector format. As a LE advocate I surprised myself by ordering the packing in BE order — because that let me simply byte-compare vector encodings to compare the underlying vectors, which was a huge performance increase.

Data structures which are frequently compared, e.g. to be sorted, benefit from BE ordering. Just binary compare them as byte strings, usually an efficient inline operation.

If I were implementing a packed wire format for SQL data, for example, I’d probably do it in BE order.

Now that I think about it, most manual arithmetic would also be easier if we described numbers with the least-significant digits first. If you're doing sums in your head, you could just list out the answer's digits as you calculate them, rather than needing to remember the list of digits and reverse them at the end.

Alternate methods of manual arithmetic that calculate the most significant digits first eliminate the need to remember and reverse digits.

With practice it can be faster than entering on a calculator!

Reply on news.ycombinator.com