Archived from groups: comp.sys.ibm.pc.hardware.chips (
More info?)
On Thu, 09 Sep 2004 10:23:11 -0400, JK <JK9821@netscape.net> wrote:
>Tony Hill wrote:
>
>> On Wed, 08 Sep 2004 09:44:13 -0400, JK <JK9821@netscape.net> wrote:
>>
>> >It isn't just the ability to run more than 4 gigs of ram. Here is one example
>> >where
>> >the 64 bit version of the software finishes a task 25% faster than the 32 bit
>> >version.
>>
>> And given that the target market for these chips has absolutely ZERO
>> to do with performance, how does this help exactly?
>>
>> >In the future we will probably see differences of much greater than 25%
>> >for some applications.
>>
>> In some very rare situations, yes. In fact, it's not at all difficult
>> to show a 100% improvement when going from 32-bit to 64-bit, but
>> that's definitely not the norm.
>
>i'm not talkking about 32 bit software on a 64 bit OS, which still might show a
>performance increase of 10-20% or more in some instances,
Under extreme situations maybe, but generally speaking 32-bit apps on
a 64-bit OS will see absolutely no improvement at all.
> I am talking
>about 64 bit applications. Anything that does complex calculations will
>be much faster with 64 bit software.
That depends entirely on what the calculations are doing. If they
need integer calculations that require a range of more than 4 billion,
then yes, they will be considerably faster (that was the 100%
improvement I was referring to above). Basically all other
calculations will see absolutely no difference at all from the
64-bitness, though the extra registers might give you a bit of a boost
(usually about 5%). Doing complex calculations with floating point
code won't give you any improvement at all, nor SSE or MMX code.
>> Average is, and will continue to be,
>> about 5%
>
>Not quite. Average might be 40% or more. We will have to see.
Keep dreaming!
>> , and some applications will always be slower as 64-bit apps
>
>How can a well written 64 bit application be slower than its 32 bit version
>on an Opteron or Athlon 64?
VERY easily! 64-bit code = 64-bit pointers, and guess what? Those
are twice as big as 32-bit pointers! Twice as big means you have
effectively half as much bandwidth and cache space to shuffle those
pointers around in.
If all else were equal, 64-bit code is usually about 5-10% SLOWER than
32-bit code. This is a well known fact and has been demonstrated on
SPARC and PowerPC at the very least. The only reason why AMD64 code
isn't usually slower is that AMD also doubled the number of integer
registers in the chip. This helps counteract the performance loss
associated with 64-bit code and actually means that it's usually a
little bit faster, usually about 5%.
>> than 32-bit ones.
>>
>> Still, as mentioned above, the target market for this chip is NOT
>> looking at performance, so a small improvement is totally meaningless.
>> If anyone cared about a 25% improvement in performance
>
>25% faster execution is extremely important.It is a 33% performance improvement.
Uhhh... that's some funny math you're doing there! Or at best some
funny wording of things.
>On desktop systems, to get that performance boost
>one might have to choose a 3.6 ghz Pentium 4 instead of a 2.4 ghz one.
>That would mean buying a cpu that is four times the price of the other.
Now you're math is getting even funnier... not to mention the fact
that we're not talking about top-end processors but rather an extreme
low-cost chip for developing markets!
-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
) and 1GHz clock.
Facebook
Twitter
Instagram