What Improvements Will 64-Bit Processors Bring?

RyanG asks: "Everyone always looks at numbers (MHz, RAM, HD) when they're considering buying a new computer. Recently, more users have been eyeing bits, as in 64-bit processors, namely the Itanium and to a lesser extent the G5. A lot of people remember the performance increases that were seen when moving from 16 to 32-bit processors and some people seem to think similar performance increases will be realized when moving from 32 to 64-bit pocessors. From what I've read this isn't going to be the case given that 64-bit percision isn't needed in all but a few cases and that moving around that extra data can actually hurt the performance of 64-bit processors when compared to 32-bit processors. Anyone care to comment?"

Comments

Average Joe Doesn't Push It

[Nater]

Think about what the average home/office user is doing on the computer and how much processing power it really takes to make that cursor blink. The simple fact is that for a typical office suite and web browser, current technology is overkill. Some people like to play audio, video, or games on their computers and that takes some more processing power, but it's nothing that pushes the limits of modern hardware (you gamers who say you can tell the difference between 100 and 125 FPS are lying... that's 1.5 to 2 times your monitor's refresh rate).

People are going to get the hot new toys because they're hot new toys and then be really disappointed when everything they've been doing doesn't get any better.

Somebody somewhere might develop the killer app that makes a 64-bit processor make sense for home and desktop users, and I can think of a few things that have the potential to take off like that, but until then the new hardware will basically be a "my dick is bigger than yours" type of thing. I honestly hope that killer app comes sooner rather than later because whatever it is, it'll be killer.

Not really about performance

[Ribbit]

The move from 32 to 64 bits isn't so much about performance as it is about ...size, I guess. The ability to hold huge databases and datasets in a flatly addressable space. The ability to do maths with larger and/or more accurate numbers. That kind of thing.

As I recall, a 286 was slightly faster than a 386 at the same clockspeed. The 486 was the first x86 that was actually designed to go fast. The big deal about the 386 was that it did memory management properly, and had the multitasking abilities, and to do that it needed a large addressable flat memory space (hence 32-bit pointers). The 32-bit registers were that size mainly so they could hold pointers and offsets and things. (Yes, I'm simplifying, I know.)

64-bit CPUs will be faster at a few things, like copying memory and crunching RC5, but most performance benefits in future CPUs will have nothing to do with word-size (clock speeds, cache sizes, clever pipelines, etc.).

Re:Not really about performance

[acidblood]

64-bit CPUs will be faster at a few things, like copying memory and crunching RC5,

Sorry buddy, but you're wrong.

Taking an example from the x86 world: since the Pentium MMX, there exists the ability to copy memory in 64-bit chunks, using the MMX instructions. The Pentium 4 adds SSE2 instructions into the mix, being able to address data in 128-bit chunks, plus some ``Cacheability Control'' instructions. These hint the processor on the nature of the data, so it can handle caching better. (Although some PREFETCH instructions, found e.g. in the Athlon, already have some of these capabilities.) In the end, a ``plain'' 64-bit processor can't possibly use memory bandwidth as efficiently as these 32-bit designs shown above.

Now for the issue of RC5. First, I assume you're talking about the distributed.net client. (The RC5 cypher itself is parameterizable, so this discussion might not apply to real-life RC5 implementations.) I do have some knowledge on this area, and I can assure you, 64-bit will only slow down RC5 implementations, when the word size parameters are specified at 32 bits. Which, BTW, is the value set by RSA on all their Secret Key Challenges, this being the stuff distributed.net is cracking.

This is mostly related to the fact that arithmetic must be done modulo 2**32, and this cannot be done effectively with 64-bit instructions. With ADD instructions, that's fairly easy -- just mask out the 32 most significants bits, i.e. AND REG, 0x00000000FFFFFFFF (still, you're executing an ``useless'' instruction, as in ``unrelated to the algorithm at hand'', and which will slow you down.) However, RC5 relies heavily on rotation instructions, and unless the ISA in question allows for working with 32-bit chunks of registers, we're back to the slow {shift left by n, shift right by 32-n, OR} procedure. Again, that's not a flaw in the algorithm -- it allows you to specify many parameters, word size being one of them, and RSA picked 32-bit in their contests.

Re:I need bits! More bits!

[OmegaDan]

there are *so* many factors that affect performance its scary ... theres no clear answers in this field ... its so complicated, as part of the coursework for my BS in CS, I had to take a course on performance evaluation!

Case in point: My Celeron 500 boots win2k about 30 seconds faster then my Athlon 1700 ... Of course, after they're booted the athlon rocks the socks off the celeron ... The answer is: The celeron has a faster hd then the athlon, but can you buy a computer based on HD speed? Could a Best Buy salesman even *tell* you the speed of a machines hd? :)

Re:Other new features of 64-bit processors

[acidblood]

Sorry I'm sounding like an Intel brochure,

You are. That's my biggest grip with your post (that, and your downplaying of AMD's x86-64 architecture.) The guy asked about the advantages of 64-bit computing in general. In particular, he didn't ask for features specific to a single architecture. None of the features you talked about couldn't be implemented on a 32-bit processor, or an 8-bit microcontroller for that matter. Based on that, your post is completely off-topic and should be moderated accordingly.

Mind you, I might stop here, but I do have some other problems with your post.

Heavy use of ILP (Instruction Level Parallelism) - speaks for itself.

SPEC results also speaks for themselves, and louder.

Itanium 800, SPEC base=314, SPEC peak=314. Athlon XP 1600, SPEC base=677, SPEC peak=701.

You don't need to tell me that the Itanium crushes everyone else in floating point applications in a clock-for-clock comparison. That makes it great for scientific computations, but what about everything else? (Nobody's playing Quake on a multi-thousand-dollar CPU.) Still, the 1 GHz Alpha 21264 is 11% faster than the 800 MHz Itanium on SPECfp, and even the newest P4s beat Itanium in this benchmark. While, of course, completely trashing it in the integer benchmarks. Seeing as how Itanium can't scale either, it won't regain the performance crown soon, if ever.

Predication - less branches taken and hence stalling. The conditional handling is done through a controlling predicate, rather than jumping. look at this C code:

There are enough examples out there that show the x86 in a bad light in this regard, however, you didn't choose one. A real programmer would rather write:

movl VALUEA, %ebx
testl %eax, %eax
cmovzl VALUEB, %ebx

Just as fast as your code, cycle-wise. Note: a 2 GHz processor has a 2.5x smaller cycle time than an 800 MHz processor.
(The above code only runs on 6th+ generation processors, and requires VALUE[A-B] to be stored in registers; not a problem, I'd say.)

I really wished to debunk the rest of your points, but I've got better stuff to do. Not that I think those were the only flaws on your post.

Face it, Itanium is doomed. McKinley will be the first IA64 processor to be taken seriously. Particular implementations notwithstanding, it's a flawed architecture. VLIW has proved NOT to be a panacea, while OOO, which has proven time and again to work, was laughed at by the Intel PR machine. Now, with benchmarks available, they're just reaping the bitter results of their strategy.

Finally, the fact that ``[t]he Hammer series processors are really just an x86 extension'' is, in fact, its most advertised feature, and you didn't seem to have gotten it. Only time will tell whether AMD will succeed, and most factors are outside of AMD's control (and quite a bit of those are non-technical.) If Intel didn't have as much power as it does, hardly would the Itanium suceed in the marketplace. But then again, Sun hardware has always been a bad performer; technical factors do not play a major role in market economics, apparently.

Re:Other new features of 64-bit processors

[jbridge21]

Perhaps you should go read the manual for an Alpha CPU. It has had almost all of these improvements for a decade now. And modern Alpha CPUs are kicking the Itanium's ass in performance. These might be new ideas to you, but they aren't exactly new to the industry...

I guess I just find it really annoying when M$/Intel/Whatever come out with some "innovation" that is not.