endianness and 64-bit machines

Discussion in 'C Programming' started by bob_jenkins@burtleburtle.net, May 17, 2006.

  1. Guest

    When comparing strings, if a machine is big-endian, even if strings are
    not aligned, you can do some shifts then do word comparisons rather
    than byte-by-byte comparisons. Little-endian machines, though, haven't
    much choice but to read strings byte by byte during comparisons. The
    expense of those shifts is a little less than the cost of reading
    things byte-by-byte on 32-bit machines. But on 64-bit machines, the
    shift-and-compare-words approach is much faster than the byte-by-byte
    approach.

    So being big-endian has an advantage, and it's a bigger advantage for
    64-bit machines than it is for 32-bit machines. How much does this
    matter? I know databases spend a lot of time doing comparisons.
     
    , May 17, 2006
    #1
    1. Advertising

  2. pete Guest

    wrote:
    >
    > When comparing strings, if a machine is big-endian,
    > even if strings are
    > not aligned, you can do some shifts then do word comparisons rather
    > than byte-by-byte comparisons.
    > Little-endian machines, though, haven't
    > much choice but to read strings byte by byte during comparisons. The
    > expense of those shifts is a little less than the cost of reading
    > things byte-by-byte on 32-bit machines. But on 64-bit machines, the
    > shift-and-compare-words approach is much faster than the byte-by-byte
    > approach.
    >
    > So being big-endian has an advantage, and it's a bigger advantage for
    > 64-bit machines than it is for 32-bit machines. How much does this
    > matter? I know databases spend a lot of time doing comparisons.


    Followup to:
    news:comp.programming

    --
    pete
     
    pete, May 17, 2006
    #2
    1. Advertising

  3. >When comparing strings, if a machine is big-endian, even if strings are
    >not aligned, you can do some shifts then do word comparisons rather
    >than byte-by-byte comparisons. Little-endian machines, though, haven't
    >much choice but to read strings byte by byte during comparisons.


    I don't believe this. If you can do it with big-endian, you can do
    it with little-endian, until you find a mismatch, at which point
    you need to deal with figuring out whether the mismatch is beyond the
    string terminator or not (on big-endian, little-endian, and non-endian
    machines).

    >The
    >expense of those shifts is a little less than the cost of reading
    >things byte-by-byte on 32-bit machines.


    This sounds like an unwarranted generalization, probably from a single
    64-bit machine.

    >But on 64-bit machines, the
    >shift-and-compare-words approach is much faster than the byte-by-byte
    >approach.


    >So being big-endian has an advantage,


    For a single very narrow purpose. Being big-endian also has a disadvantage
    for multi-precision addition/subtraction.

    >and it's a bigger advantage for
    >64-bit machines than it is for 32-bit machines. How much does this
    >matter? I know databases spend a lot of time doing comparisons.


    Gordon L. Burditt
     
    Gordon Burditt, May 17, 2006
    #3
  4. CBFalconer Guest

    Gordon Burditt wrote:
    >
    >> When comparing strings, if a machine is big-endian, even if
    >> strings are not aligned, you can do some shifts then do word
    >> comparisons rather than byte-by-byte comparisons. Little-endian
    >> machines, though, haven't much choice but to read strings byte
    >> by byte during comparisons.

    >
    > I don't believe this. If you can do it with big-endian, you can
    > do it with little-endian, until you find a mismatch, at which
    > point you need to deal with figuring out whether the mismatch is
    > beyond the string terminator or not (on big-endian, little-endian,
    > and non-endian machines).


    Please preserve attributions for material you quote.

    Once more, the distribution of actual string sizes in a system
    comes into play. I assume, without more justification than
    instinct, that most strings are short, and thus the effort to
    switch between comparision of large entities and single chars is
    not going to be efficacious.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Also see <http://www.safalra.com/special/googlegroupsreply/>
     
    CBFalconer, May 17, 2006
    #4
  5. On Wed, 17 May 2006 -0000 (Gordon Burditt) wrote:
    >>So being big-endian has an advantage,

    >
    >For a single very narrow purpose. Being big-endian also has a disadvantage
    >for multi-precision addition/subtraction.


    if little endian is something like
    <----><---->
    a[0] a[1]
    i agree it is easier because the number can increase
    <----><----><---->
    a[0] a[1] a[2]

    in big endian i have to move the pointer
    <----><----><---->
    a[-1] a[0] a[1]

    so little endian is how represent number in a computer and
    0d=0b, 1d=1b, 2d==01b, 3d==11b,4d=001b, 5d=101b, 6d=011b etc

    >>and it's a bigger advantage for
    >>64-bit machines than it is for 32-bit machines. How much does this
    >>matter? I know databases spend a lot of time doing comparisons.

    >
    > Gordon L. Burditt
     
    RSoIsCaIrLiIoA, May 19, 2006
    #5
  6. Malcolm Guest

    "Gordon Burditt" <> wrote
    >
    >>So being big-endian has an advantage,

    >
    > For a single very narrow purpose. Being big-endian also has a
    > disadvantage
    > for multi-precision addition/subtraction.
    >

    But it has the big advantage that Microsoft don't use it.
    After all, if we don't do everything we can to stop them, they might take
    over the world and force us all to store our bytes at the little end.
    --
    www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm, May 20, 2006
    #6
  7. wrote:
    > When comparing strings, if a machine is big-endian, even if strings are
    > not aligned, you can do some shifts then do word comparisons rather
    > than byte-by-byte comparisons. Little-endian machines, though, haven't
    > much choice but to read strings byte by byte during comparisons. The
    > expense of those shifts is a little less than the cost of reading
    > things byte-by-byte on 32-bit machines. But on 64-bit machines, the
    > shift-and-compare-words approach is much faster than the byte-by-byte
    > approach.
    >
    > So being big-endian has an advantage, and it's a bigger advantage for
    > 64-bit machines than it is for 32-bit machines. How much does this
    > matter? I know databases spend a lot of time doing comparisons.


    Newbie question:

    What does endianness mean? And what's a big-endian machine?


    Best regards / Med venlig hilsen
    Martin Jørgensen

    --
    ---------------------------------------------------------------------------
    Home of Martin Jørgensen - http://www.martinjoergensen.dk
     
    =?ISO-8859-1?Q?Martin_J=F8rgensen?=, May 20, 2006
    #7
  8. Richard Heathfield, May 20, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. gamehack

    Bit shifts and endianness

    gamehack, Jan 5, 2006, in forum: C Programming
    Replies:
    72
    Views:
    6,994
    Dave Thompson
    Jan 11, 2006
  2. 64 bit Endianness issue

    , May 11, 2006, in forum: C Programming
    Replies:
    17
    Views:
    705
    Ian Collins
    May 12, 2006
  3. Why Tea

    Arithmetic for 32-bit and 64-bit machines

    Why Tea, Jan 9, 2008, in forum: C Programming
    Replies:
    10
    Views:
    722
    cr88192
    Jan 10, 2008
  4. Rob Clewley
    Replies:
    4
    Views:
    2,739
    Martin v. Löwis
    Mar 22, 2009
  5. Sal
    Replies:
    16
    Views:
    203
    Ilya Zakharevich
    May 25, 2010
Loading...

Share This Page