Linked by Jordan Spencer Cunningham on Wed 7th Oct 2009 19:15 UTC, submitted by JayDee
Permalink for comment 388247
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.





Member since:
2006-01-25
On 64-bit systems, you already pay a performance penalty for dealing with pointers that are twice as large. I know this penalty is on the order of 20% in Java, and it's probably not much better for native code.
About the only only practical uses I could see for 128-bits are for filesystems, or for ultra-high-end compute clusters that run thousands or hundreds of thousands of virtuals.
Im not arguing for moving to 128-bit memory addressing - we are pretty far away from that becoming useful by any stretch of the imagination. But 128-bit GPRs might be quite useful. But you point about 64-bit being slower...
Its not slower because of having to work on 64-bit registers. Doubling the size of registers had virtually no detrimental effect on clock speeds. Its slower simply because you in are doubling the amount of data that needs to be moved around the system. The slowdowns are almost completely isolated to the following areas:
1. Moving data from the CPU to the caches and main memory and back again takes longer because there is simply more bits to move. And since this is already a bottleneck to performance, the effects are amplified.
2. executable images take up more space, so loading them from disk can potentially take longer.
This is sometimes counteracted by the increase in available registers that came with x86-64, but not often. Regardless, as caches get bigger and faster the difference will shrink. That is already happening, i7 still has the same problem - but the difference is much less pronounced because the memory subsystem has gotten so much better. And if you happen to actually need to operate on 64-bit integer values routinely, the increase in performance completely trumps all those concerns.