Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > endianness and 64-bit machines

Reply
Thread Tools

endianness and 64-bit machines

 
 
bob_jenkins@burtleburtle.net
Guest
Posts: n/a
 
      05-17-2006
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.

 
Reply With Quote
 
 
 
 
pete
Guest
Posts: n/a
 
      05-17-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
 
 
 
Gordon Burditt
Guest
Posts: n/a
 
      05-17-2006
>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
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      05-17-2006
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/>


 
Reply With Quote
 
RSoIsCaIrLiIoA
Guest
Posts: n/a
 
      05-19-2006
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

 
Reply With Quote
 
Malcolm
Guest
Posts: n/a
 
      05-20-2006
"Gordon Burditt" <(E-Mail Removed)> 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




 
Reply With Quote
 
=?ISO-8859-1?Q?Martin_J=F8rgensen?=
Guest
Posts: n/a
 
      05-20-2006
(E-Mail Removed) 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
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      05-20-2006
Martin Jørgensen said:

<snip>

> Newbie question:
>
> What does endianness mean? And what's a big-endian machine?


http://www.catb.org/~esr/jargon/html/B/big-endian.html
http://www.catb.org/~esr/jargon/html...le-endian.html
http://www.catb.org/~esr/jargon/html...le-endian.html
http://www.catb.org/~esr/jargon/html...I-problem.html

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Bit shifts and endianness gamehack C Programming 72 01-11-2006 06:01 AM
Endianness and streams kelvSYC C++ 8 06-06-2005 12:08 AM
memcpy() and endianness Case C Programming 26 05-12-2004 02:47 PM
endianness and sscanf/sprintf pramod C++ 22 01-06-2004 01:02 PM
endianness and sscanf/sprintf pramod C Programming 22 01-06-2004 01:02 PM



Advertisments