NewHerb: Memory addressing is one of the least of the benefits you theoretically gain from the architecture. There are definitely other benefits for the consumer. There are ways to get around the memory addressing problem even with 32-bit processors. Large mainframes and supercomputers have been doing it for years, but they require cost-prohibitive complex architectures to work efficiently. The first IBM-PC was 8-bits and if you could only address memory from that, you could only access 256 bytes. (To access 4K of memory, you need 12 bits and you can see why nobody saw the need to invent hard drives until we had 16-bit computers. 360K on a floppy was plenty)
There are other low-level advantages at the assembler level. The CPU can process more complex instructions in a single clock cycle. This made advances from 8-bit to 16-bit and 32-bit highly significant in terms of speed.
For instance, if I want to add a number less than 256 to a register, I need two clock cycles. One for the command, and one for the number. If the result goes over 256, a carry flag gets set and you can use that to increment another number. Multiplication can only be done by multiple additions, and the compiler developer will need to develop his own complex algorithms for division and other mathematical functions.
With 16-bits I can push both the command and the number simultaneously, and then I only have a carry flag if the number goes over 65536. Or I can push two commands together in the same clock cycle like "increment by 1, increment by 1" (which is a single command). Then the chip designer with the increased flexibility will add a bunch of new commands to the chip which are done internally.
With 32-bits, you can push division and multiplication in one clock cycle, and the chip designer now adds a bunch more commands to the chip, that weren't feasible in 16-bits because the command parameters were too complex before. Or you can push 4 simple commands, 2 intermediate commands or 1 complex command through in a single clock cycle.
The problem of continually going further is that eventually you run out of increasingly complex generic commands that would make the chip more useful to low-level developers. In other words, you don't need more complex commands as practically all of the commands can be done in 32-bits or less. And under the philosophy of RISC architectures, you don't want more complex commands anyway.
So that leaves the advantage of possibly pushing more commands through the chip in the same clock cycle, theoretically twice as fast as you can push command A+B at the same time. Except that if B is dependant on A, you have to wait for the result to process B, so the chip might guess on the result of A and it saves a clock cycle if it is right, or B gets recalculated on the next clock cycle if it is wrong. Then there is the bottleneck of how fast you can get command B to process, or if they come too fast you need to store them until the CPU is ready. This is where chip caches and disk caches and pipeline stages make the motherboard designs and other architectural designs significant.
The point is, a 64-bit processor can theoretically double the performance of a 32-bit processor given the perfect algorithm and program conditions, which are never met. And they are held back by other bottlenecks in the computer anyway.
With the new G5's, I would suggest that the ability to bring the frontside bus speeds up to the GHz level is probably more significant in the short term than the 64-bit architecture. As the chip is refined, and the motherboards are refined, and the software is refined, everything will be fine-tuned and benefit down the road.
News 
Market Data 
Discover 
AI
