How much better are 64 but platforms

[Bill Moran]

David Schwartz wrote:
>>I've never used FreeBSD on a 64 bit platform, and with a recent
>>project I've got
>>a client asking me, "How much faster would this run if we put it
>>on an Itanium."
>>
>>So, in the future, I'll probably be getting a 64 bit machine to
>>try this out on.
>>
>>But it got me thinking, what should I _expect_ to see in
>>improvement?  This
>>application is mostly comparing strings, there are no 64 bit
>>integers or floats
>>to be obvious bottlenecks on a 32 bit platform, so (lacking
>>actual experience)
>>how much can I expect the application to speed up if I move it to a 64 bit
>>platform?
> 
> 	Applications that primarily manipulate strings are not faster on 64-bit
> platforms and, in some cases, run more slowly. We suspect this is because,
> in relative terms, single byte accesses are more expensive.

I was wondering about that, specifically.  I guess it depends on how the compiler
does things.  If it could do strcmp() 64 bits (8 bytes) at a time, it could
probably be faster, but I don't know how feasable that is with regard to string
operations.
Perhaps there's a way to optimize my code by casting strings as 64 bit integers
and comparing them.  Hopefully I'll get a chance to try that theory out.  Of course,
strings longer than 8 bytes will have to be compared 8 bytes at a time, but in
this particular case, the strings should never be that long anyway. Hmmm ...

> 	Applications that manipulate small integers (that fit in 32-bits) generally
> run at about the same speed. We do see slight slowdowns simply because of
> extra memory bandwidth being used due to 64-bits values taking twice as much
> space on the bus as 32. Applications that deal with large numbers (like
> cryptography) or bulk data (like compression) tend to get a boost. Database
> applications generally do get a performance boost because of the better
> ability to deal with large amounts of memory.

Well ... I seriously doubt that my percentage calculating code would benefit at
all then.

> 	In previous steps, 8-bit to 16-bit and 16-bit to 32-bit, quantities that
> previously had to be manipulated as multiple units could now be handled as a
> single unit. Most counters and integers exceed 8-bits, to moving to 16-bits
> halved the work for almost anything. Still, many such things didn't fit in
> 16-bits, so 32-bits halved the work for many things. However, almost
> everything fits in 32-bits. So 64-bits either gets no benefit for most
> things or just results in dragging extra bytes across the memory bus, which
> doesn't get any faster.

Now that you've got me thinking of it, metaphones shouldn't ever be any longer
than 4 bytes anyway, so (as it stands now) I could cast them as integers and
compare the ints instead of using strcmp(), which should be faster.   Still
doesn't demonstrate any need for a 64 bit system, though.

> 	However, we'll all need to smoothly handle more than 4Gb of memory real
> soon now. Memory mapping an 8Gb database may speed things up as well. It's
> too early for me to tell about these kinds of things yet.

Well, that's likely as well.

Thanks for the reply, David.  I appreciate the input.

-- 
Bill Moran
Potential Technologies
http://www.potentialtech.com