4 ms·

I think the main advantage I see in LE architectures is that integral types don't have to relocate. For example, the int32 value 30 is represented in memory as

I think the main advantage I see in LE architectures is that integral types don't have to relocate. For example, the int32 value 30 is represented in memory as "1E 00 00 00". The int16 value 30 is represented in memory as "1E 00". So casting downwards means that the pointers are the same, and you just ignore the trailing 0s. Contrast this to BE architectures, where you have "00 00 00 1E" vs "00 1E" -- casting from the larger to the smaller type means that you have to move the pointer.

bodyfour 12y ago
Yes, exactly. Maybe an example that's easier to visualize is when you learned to do arithmetic as a child. If I gave you a bunch of numbers to add like 57, 9, and 318 the first thing you would do is right justify them all. For any math operation, you start at the least significant digit and work up. This is ultimately equivalent to the int32/int16 example you gave -- if you are trying to operate on numbers of different length you have to first ensure that their LSBs line up. Little-endian is like writing your decimal integers right-justified on the blackboard. So little-endian is (slightly) more convenient for machines and big-endian is (slightly) more convenient to humans reading memory dumps. The unfortunate thing is that "network byte order" is big-endian so it's still the traditional endianness to use for wire protocols or on-disk formats. In my own designs I've switched to specifying fixed-width integers as little-endian which makes more sense for 99.9% of computers today.
cesarb 12y ago
Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x. Contrast with a big-endian representation, where the byte at offset x would have weight 256^(length - 1 - x).
- KMag 12y ago
  Except that it's often convenient for encodings to sort lexographically and numerically the same way. There are several multi-precision number formats with this property, but they're all either equally slow to load on any endian machine, or faster to load on big-endian machines. Also, on a 64-bit big-endian architecture, you don't need specialized string comparison instructions to get efficient string comparisons. The code is only slightly more complicated on BE architectures that only support aligned 64-bit loads.
- wyager 12y ago
  >Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x. This is literally the opposite of how most programmers in the world write numbers naturally. See "1234". The digit at offset x from the right has weight 10^x. That corresponds to big-endian. Considering that the only important difference between little and big endian is when people have to read or write it by hand, we should probably model it after common human representation...
  - hamstergene 12y ago
    By the way, this "natural" way of writing numbers comes unchanged from right-to-left writing system of Arabic. They naturally read 1234 starting from the lowest significant digit (here, '4'). Think about the irony :)
    - KMag 12y ago
      I'm not sure about Arabic, but my understanding of Hebrew (another member of the Semitic language family) is that they still pronounce the numbers left to right, and if a line break forces digits to be split across lines, the most significant digits are put on the top line.
      - hamstergene 12y ago
        You got me curious. I googled and found[1] that indeed they only pronounce numbers 21-99 that way, e.g. for 31 the order of words is "one thirty", but higher order components go left to right, e.g. for 25031 the order of words is "five twenty thousand one thirty". 1. http://arabic.tripod.com/VocabNumbers.htm http://arabic.tripod.com/VocabNumbers.htm
wyager 12y ago
Modern processors can perform this cast in a negligible amount of time, and due to modern memory architecture there's no advantage to reading 2 bytes instead of 4.

bodyfour 12y ago

Yes, exactly. Maybe an example that's easier to visualize is when you learned to do arithmetic as a child. If I gave you a bunch of numbers to add like 57, 9, and 318 the first thing you would do is right justify them all. For any math operation, you start at the least significant digit and work up. This is ultimately equivalent to the int32/int16 example you gave -- if you are trying to operate on numbers of different length you have to first ensure that their LSBs line up. Little-endian is like writing your decimal integers right-justified on the blackboard. So little-endian is (slightly) more convenient for machines and big-endian is (slightly) more convenient to humans reading memory dumps. The unfortunate thing is that "network byte order" is big-endian so it's still the traditional endianness to use for wire protocols or on-disk formats. In my own designs I've switched to specifying fixed-width integers as little-endian which makes more sense for 99.9% of computers today.

cesarb 12y ago

Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x. Contrast with a big-endian representation, where the byte at offset x would have weight 256^(length - 1 - x).

KMag 12y ago
Except that it's often convenient for encodings to sort lexographically and numerically the same way. There are several multi-precision number formats with this property, but they're all either equally slow to load on any endian machine, or faster to load on big-endian machines. Also, on a 64-bit big-endian architecture, you don't need specialized string comparison instructions to get efficient string comparisons. The code is only slightly more complicated on BE architectures that only support aligned 64-bit loads.
wyager 12y ago
>Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x. This is literally the opposite of how most programmers in the world write numbers naturally. See "1234". The digit at offset x from the right has weight 10^x. That corresponds to big-endian. Considering that the only important difference between little and big endian is when people have to read or write it by hand, we should probably model it after common human representation...
- hamstergene 12y ago
  By the way, this "natural" way of writing numbers comes unchanged from right-to-left writing system of Arabic. They naturally read 1234 starting from the lowest significant digit (here, '4'). Think about the irony :)
  - KMag 12y ago
    I'm not sure about Arabic, but my understanding of Hebrew (another member of the Semitic language family) is that they still pronounce the numbers left to right, and if a line break forces digits to be split across lines, the most significant digits are put on the top line.
    - hamstergene 12y ago
      You got me curious. I googled and found[1] that indeed they only pronounce numbers 21-99 that way, e.g. for 31 the order of words is "one thirty", but higher order components go left to right, e.g. for 25031 the order of words is "five twenty thousand one thirty". 1. http://arabic.tripod.com/VocabNumbers.htm http://arabic.tripod.com/VocabNumbers.htm

wyager 12y ago

Modern processors can perform this cast in a negligible amount of time, and due to modern memory architecture there's no advantage to reading 2 bytes instead of 4.