OK, let's put it simply.
You're saying moving from 32-bit to 64-bit does not inherently make your processor better. I see that you like your analogies, so I'll give you one.
Let's say your 32-bit is a 4-cylinder car and your 64-bit is an 8-cylinder car. If they have the same horsepower, then fine, no big difference. However, having the 8-cylinder increases your "capacity" for improvement.
What's the cost of having 8-cylinders? Less gas efficiency: you need more memory to power this 64-bit processor. However, as you may or may not see, some cars have the option of running on 4-cylinders.
Note: this analogy is not perfect (duh?)
That's a horrible analogy; the move from 64-bit to 32-bit has very few negative effects, if any. I challenge you to find one realistic negative of switching to 64-bit from 32-bit other than the initial upgrade.
Here is a a realistic negative of switching to 64-bit from 32-bit.
64-bit addresses take up twice the space of 32-bit addresses.
64-bit code is almost always larger that 32-bit code because of the number of addresses used in the assembly code.
Thus more cache is used up by the same "amount" of code (# of instructions) and more memory bandwidth is used up in transfering that code.
SO. Here is my take on 64-bit vs 32-bit CPUs.
Migrating from 16-bit to 32-bit was a big step.
So is migrating from 32-bit to 64-bit.
Going from 16-bit to 32-bit didn't improve things for existing applications (except a few that used slow hacks to pretend to be 32-bit), it instead ALLOWED NEW APPLICATIONS!
Thus in 32 bit..
- you could now multi-task much better.
- you could now support better graphics (larger resolutions, bit depths, etc).
- you could now run entirely new kinds of software that were unfeasable in 32-bit.
BUT. this only occurred when most/many applications were bumping up against the limits of 16-bit.
SO. going from 32-bit to 64-bit will allow an entire new class of software to be run.
- video editting of high quality (ie loading the 4+ GB movie in ram, or editting HD movies, 35+ GB)
- server operations involving massivly higher users/database sized (databases of 100 GB cached in ram)
- data manipulations unheard of on desktop 32-bit machines (weather prediction, true AI)
The point is, very few people needed 32-bit while most software was 16-bit. But after moving to 32-bit and getting a whole new class of applications, very few people would even think of going back.
The same will be true a few years after moving to 64-bit applications.
Imagine what virtual worlds our 64-bit games will be 5-10 years, and how impossible they would have been in a
measly 2 GB of ram.
Imagine in 5-10 years when you are making 3-d movies in HD resolution, changing the actor in a scene and having it re-render the entire movie IN RAM! Then imagine going back to only 32-bit.
The point is, you only need to move from one capability to a larger capability when you have exhausted the potential of the previous generation, and the cost is now not prohibative. ie ram is cheap enough you can afford > 4 GB.
So for the person that said that why don't we just go to 512-bit NOW, the answer is because we can afford to max out the capabilities of 64-bit now, but we can afford to max out 32-bit, or will in a couple years. When everyone had 1 or 2 meg of ram, much of it barely accessable do to 16-bit cpus, then the time was ripe to move to 32-bit. When most people have 2 GB of ram, and many have 8 GB using hacks, then the time is ripe to move to 64-bit.
Also to use a 512-bit CPU, you would need a 512-bit DATA bus which would require more pins then our technology can support.
PS, very little of the Conroe is still 32-bit anyway.
The memory bus is now 64-bit even if the address bus isn't.
The SSE memory bus is now 128-bit.
The integer registers may be 32-bit, but the floating point registers have been much larger for years.
The only thing that isn't 64-bit in our 32-bit mode is integer registers, address bus and address sizes. Remember that the 8-bit CPUs used 16-bit addresses, and the 16-bit CPUs (8088, 80286) had 24 effective addresses. (though it used 16-bit segments).
We could have gone to use 16 bit segment numbers and 32-bit segments. But our transister budget now allows us to go to full 32-bit addresses without paying TOO much of a penalty.
It is possible though that we need to migrate to a 128-bit data bus to take true advantage of 64-bit CPUs. But that could have been done even with current 32-bit CPUs that use 128-bit data such as floating point and SSE.
You bring up a good point with BR disks and HD DVD disks on the way working with 35-40GB's of data will pretty much force people to move to 64bit or they will suffer while a disk image is chopped up and processed one peice at a time. The closest thing I can remember is Win9X and its 2GB's limit for a file size... ugghh what a pain that was.