6 ms·

I actually did a writeup on this: https://www.technicalsourcery.net/posts/on-endianness/ https://www.technicalsourcery.net/posts/on-endianness/ TLDR: Little en

I actually did a writeup on this: https://www.technicalsourcery.net/posts/on-endianness/ https://www.technicalsourcery.net/posts/on-endianness/ TLDR: Little endian is better for most data situations (and incidentally is a more natural ordering for humans), so it's good that it won out in the end.

deleted 2y ago
[deleted]
Tor3 2y ago
Well, the bits jump around.. bytes are ordered, but the bits aren't, with LE (between bytes) so there's always room for a never-ending discussion about what's best ("Are you a bit person? Or a byte person? Then your preferences may differ"). The best argument for LE would be that a processor like e.g. the 6502 could start processing the least significant byte while fetching the most significant byte, and that on a VAX you could pass a 4-byte integer to a Fortran function expecting a 2-byte integer and it would actually work (as long as the value was > 65536). That was actually done a lot back in the day.. and created problems when recompiling the Fortran code for a BE architecture.
- deleted 2y ago
  [deleted]
- akira2501 2y ago
  LE is easier to handle, BE is easier to read.
  - nicce 2y ago
    LE is also much faster in terms of performance. For example, because of the efficiency of the add or subtract operations.
    - bregma 2y ago
      At the circuit level (where the performance is determined) it doesn't matter if your half-adder combines its left and right inputs or its right and left inputs. So no, there is no difference in efficiency or performance when it comes to endianness. The only time it would make a difference is if your memory bus width is less than your wordsize and you lack any kind of caching.
    - foldr 2y ago
      I wonder if you're thinking of the efficiency penalty for dealing with big-endian values on a little-endian architecture. As the sister comment says, there's nothing inherently more efficient about either byte order when it comes to the processor performing arithmetic operations in on values in its native byte order.
    - p_l 2y ago
      Unless you have a bit-serial machine (close to extinct), LE vs BE matters not for ALU so long as you don't have to run the computation through multiple rounds (like having 32bit ALU but doing 64bit arithmetic)
      - Tor3 2y ago
        .. or a 6502 microprocessor doing 16-bit arithmetic with an 8-bit ALU. The 6502 was designed by a team who used to work with the big endian 6800, and chose little endian for their 6502 for a slight performance improvement.
        p_l 2y ago
        That falls into my second case of using smaller ALU in two steps :)
      - magicalhippo 2y ago
        > so long as you don't have to run the computation through multiple rounds To be fair, this is not exactly uncommon for many workloads, even on todays 64bit machines.
      - 2y ago
- Tor3 2y ago
  I had another look at the actual article/RFC: This is more than just the little endian/big endian byte order, it's about the bit order of serial messages, where, unlike bytes, the bit order could actually be different (for bytes stored in memory the bits of each individual byte in modern / semi-modern computers are always stored in the same order whether it's a LE or a BE memory architecture). In a serial protocol you could send the most significant bit of the stream first, or the least significant bit first, and that's what's at first discussed in that RFC.
  - kstenerud 2y ago
    Yes, that's right. Since CPUs abstract away the bit ordering, it only starts to matter when dealing with bit-oriented communications. And since it is abstracted away, there's no real benefit to be gained by BE or LE at the bit-level.
weinzierl 2y ago
Brilliant write up! I do not really understand the "Sorting unknown uint-struct blobs" point. Could you give an example or explain in more detail, what a "unknown uint-struct blob" is? The odd/even advantage could be put even stronger, because every additional bit you know from the little end gives additional information about the number's divisibility. For example, one bit tells divisibility by two (aka ofd/even), two bits tell divisibility by four, and so on.
- kstenerud 2y ago
  For example, if you had a file that comprised the following struct: struct someblob { uint64_t timestamp; uint64_t checksum; uint32_t item_count; struct something items[0]; }; Even if you didn't know that a collection of files were structured this way, you could still read, say, the first 128 bits as an unsigned integer and compare them, and they'd just happen to be naturally ordered because the timestamp field grows from right to left, and would have precedence over the "lower 64 bits" of the checksum field. It's a very minor benefit (of dubious real-world utility), but I wanted to be comprehensive :P
  - tekacs 2y ago
    This comes in really really handy in lexicographical ordering. For example, if storing in the keys of a KV store a pattern of: [u32, String, u32, String, …] If you want those arrays to be sorted lexicographically, you’ll want to store those u32 instances in big endian, so that both those and the strings sort from left-to-right.
  - weinzierl 2y ago
    Thanks! That makes sense. Mentally, I would put this in the "conventional" advantage category, because it relies on comparing fixed length chunks of memory and computationally it should not make a difference if `timestamp` is stored LE or BE for sorting.
    - kstenerud 2y ago
      Actually, in this case it would. Consider the layout (byte-by-byte): BE: t8 t7 t6 t5 t4 t3 t2 t1 c8 c7 c6 c5 c4 c3 c2 c1 In the big endian case, the byte-by-byte of the struct naturally places the timestamp at the high end of the 128 bit value you blindly read. LE: t1 t2 t3 t4 t5 t6 t7 t8 c1 c2 c3 c4 c5 c6 c7 c8 In the little endian case, it's the CHECKSUM at the high end of the 128 bit value.
wakawaka28 2y ago
The writeup does not convey a consistent message on "naturalness"... The normal way numbers are written in most or all of the world is big-endian so obviously that is the one that would be found "natural" to most people, regardless of whatever perceived advantages going little-endian has. Furthermore, number names in every language I know of start with the biggest units. The direction of writing does not matter so much as the direction of reading. Anything other than big-endian would require readers to skip around in text to actually say the name of a number in a sentence.
- kstenerud 2y ago
  What we consider "natural" now is not what was originally considered "natural" during the early centuries of the Hindu-Arabic numerals' journey. In fact, we can still see the vestiges of the "low order digits first" convention in some languages even today (for example, in German). Even Greek numbers underwent reversals in the early years (earliest known evidence circa 4th century BC).
  - Someone 2y ago
    > In fact, we can still see the vestiges of the "low order digits first" convention in some languages even today (for example, in German). Also in English, with the numbers thirteen through nineteen (and, fairly well hidden, eleven and twelve)
    - somat 2y ago
      I always thought eleven and twelve were remnants from when the system was more base twelveish. It was never actually base 12, that would have required inventing 0, But sometimes I wonder if we would not have been better off sticking with base 12. And before someone chimes in with "base 10 is natural because we have 10 fingers" no we have 8 fingers, by that logic we should be using base 8, but the real winner in using base 12 is count using your finger bones(there are twelve of them) and use your thumb to keep your count, use both hands and you can get to 100(144 in base 10). this is probably why base twelveish was so common, shepards counting sheep. try counting to 100 in base 10 on your fingers, not so natural now is it.

deleted 2y ago

[deleted]

Tor3 2y ago

Well, the bits jump around.. bytes are ordered, but the bits aren't, with LE (between bytes) so there's always room for a never-ending discussion about what's best ("Are you a bit person? Or a byte person? Then your preferences may differ"). The best argument for LE would be that a processor like e.g. the 6502 could start processing the least significant byte while fetching the most significant byte, and that on a VAX you could pass a 4-byte integer to a Fortran function expecting a 2-byte integer and it would actually work (as long as the value was > 65536). That was actually done a lot back in the day.. and created problems when recompiling the Fortran code for a BE architecture.

deleted 2y ago
[deleted]
akira2501 2y ago
LE is easier to handle, BE is easier to read.
- nicce 2y ago
  LE is also much faster in terms of performance. For example, because of the efficiency of the add or subtract operations.
  - bregma 2y ago
    At the circuit level (where the performance is determined) it doesn't matter if your half-adder combines its left and right inputs or its right and left inputs. So no, there is no difference in efficiency or performance when it comes to endianness. The only time it would make a difference is if your memory bus width is less than your wordsize and you lack any kind of caching.
  - foldr 2y ago
    I wonder if you're thinking of the efficiency penalty for dealing with big-endian values on a little-endian architecture. As the sister comment says, there's nothing inherently more efficient about either byte order when it comes to the processor performing arithmetic operations in on values in its native byte order.
  - p_l 2y ago
    Unless you have a bit-serial machine (close to extinct), LE vs BE matters not for ALU so long as you don't have to run the computation through multiple rounds (like having 32bit ALU but doing 64bit arithmetic)
    - Tor3 2y ago
      .. or a 6502 microprocessor doing 16-bit arithmetic with an 8-bit ALU. The 6502 was designed by a team who used to work with the big endian 6800, and chose little endian for their 6502 for a slight performance improvement.
      - p_l 2y ago
        That falls into my second case of using smaller ALU in two steps :)
    - magicalhippo 2y ago
      > so long as you don't have to run the computation through multiple rounds To be fair, this is not exactly uncommon for many workloads, even on todays 64bit machines.
    - 2y ago
Tor3 2y ago
I had another look at the actual article/RFC: This is more than just the little endian/big endian byte order, it's about the bit order of serial messages, where, unlike bytes, the bit order could actually be different (for bytes stored in memory the bits of each individual byte in modern / semi-modern computers are always stored in the same order whether it's a LE or a BE memory architecture). In a serial protocol you could send the most significant bit of the stream first, or the least significant bit first, and that's what's at first discussed in that RFC.
- kstenerud 2y ago
  Yes, that's right. Since CPUs abstract away the bit ordering, it only starts to matter when dealing with bit-oriented communications. And since it is abstracted away, there's no real benefit to be gained by BE or LE at the bit-level.

weinzierl 2y ago

Brilliant write up! I do not really understand the "Sorting unknown uint-struct blobs" point. Could you give an example or explain in more detail, what a "unknown uint-struct blob" is? The odd/even advantage could be put even stronger, because every additional bit you know from the little end gives additional information about the number's divisibility. For example, one bit tells divisibility by two (aka ofd/even), two bits tell divisibility by four, and so on.

kstenerud 2y ago
For example, if you had a file that comprised the following struct: struct someblob { uint64_t timestamp; uint64_t checksum; uint32_t item_count; struct something items[0]; }; Even if you didn't know that a collection of files were structured this way, you could still read, say, the first 128 bits as an unsigned integer and compare them, and they'd just happen to be naturally ordered because the timestamp field grows from right to left, and would have precedence over the "lower 64 bits" of the checksum field. It's a very minor benefit (of dubious real-world utility), but I wanted to be comprehensive :P
- tekacs 2y ago
  This comes in really really handy in lexicographical ordering. For example, if storing in the keys of a KV store a pattern of: [u32, String, u32, String, …] If you want those arrays to be sorted lexicographically, you’ll want to store those u32 instances in big endian, so that both those and the strings sort from left-to-right.
- weinzierl 2y ago
  Thanks! That makes sense. Mentally, I would put this in the "conventional" advantage category, because it relies on comparing fixed length chunks of memory and computationally it should not make a difference if `timestamp` is stored LE or BE for sorting.
  - kstenerud 2y ago
    Actually, in this case it would. Consider the layout (byte-by-byte): BE: t8 t7 t6 t5 t4 t3 t2 t1 c8 c7 c6 c5 c4 c3 c2 c1 In the big endian case, the byte-by-byte of the struct naturally places the timestamp at the high end of the 128 bit value you blindly read. LE: t1 t2 t3 t4 t5 t6 t7 t8 c1 c2 c3 c4 c5 c6 c7 c8 In the little endian case, it's the CHECKSUM at the high end of the 128 bit value.

wakawaka28 2y ago

The writeup does not convey a consistent message on "naturalness"... The normal way numbers are written in most or all of the world is big-endian so obviously that is the one that would be found "natural" to most people, regardless of whatever perceived advantages going little-endian has. Furthermore, number names in every language I know of start with the biggest units. The direction of writing does not matter so much as the direction of reading. Anything other than big-endian would require readers to skip around in text to actually say the name of a number in a sentence.

kstenerud 2y ago
What we consider "natural" now is not what was originally considered "natural" during the early centuries of the Hindu-Arabic numerals' journey. In fact, we can still see the vestiges of the "low order digits first" convention in some languages even today (for example, in German). Even Greek numbers underwent reversals in the early years (earliest known evidence circa 4th century BC).
- Someone 2y ago
  > In fact, we can still see the vestiges of the "low order digits first" convention in some languages even today (for example, in German). Also in English, with the numbers thirteen through nineteen (and, fairly well hidden, eleven and twelve)
  - somat 2y ago
    I always thought eleven and twelve were remnants from when the system was more base twelveish. It was never actually base 12, that would have required inventing 0, But sometimes I wonder if we would not have been better off sticking with base 12. And before someone chimes in with "base 10 is natural because we have 10 fingers" no we have 8 fingers, by that logic we should be using base 8, but the real winner in using base 12 is count using your finger bones(there are twelve of them) and use your thumb to keep your count, use both hands and you can get to 100(144 in base 10). this is probably why base twelveish was so common, shepards counting sheep. try counting to 100 in base 10 on your fingers, not so natural now is it.