endianness and 64-bit machines

[bob_jenkins]

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.

 

[pete]

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:

 

[Gordon Burditt]

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

 

[CBFalconer]

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/>

 

[RSoIsCaIrLiIoA]

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

 

[Malcolm]

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.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

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

 

[Richard Heathfield]

Martin Jørgensen said:

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/L/little-endian.html
http://www.catb.org/~esr/jargon/html/M/middle-endian.html
http://www.catb.org/~esr/jargon/html/N/NUXI-problem.html