How do you explain 64-bit processors to people in laymens terms?
- Thread starter Nocturnal
- Start date
Put it in terms of Zip codes...
When zip codes were 5 digits, the number of areas you could address was 99,999.
If you doubled the number of digits, you could address 9,999,999,999 areas.
While this isn't at all accurate, it's at least a fairly good description of going from 32 bit addressing to 64 bit addressing...
When zip codes were 5 digits, the number of areas you could address was 99,999.
If you doubled the number of digits, you could address 9,999,999,999 areas.
While this isn't at all accurate, it's at least a fairly good description of going from 32 bit addressing to 64 bit addressing...
arcenite
Lifer
- Dec 9, 2001
- 10,660
- 7
- 81
I like to use cars. If you have one car, and are trying to move 4 people and two cars moving 8 people, what is the difference?
Two cars will be able to process double the "information" at the same speed as one car with half the information, but will not get those 8 people there any quicker than the 1 car carrying 4 people.
edit: woo I rock, this was for dual core processors. Excuse me
Two cars will be able to process double the "information" at the same speed as one car with half the information, but will not get those 8 people there any quicker than the 1 car carrying 4 people.
edit: woo I rock, this was for dual core processors. Excuse me
thescreensavers
Diamond Member
- Aug 3, 2005
- 9,916
- 2
- 81
I say that there is 32 doors for info to come in now in a 64 bit cou there is 64 doors so info can get in faster thuse making a faster cpu
HardWarrior
Diamond Member
- Jan 26, 2004
- 4,400
- 23
- 81
The previous version of PC processors manipulated data in 32-bit chucks. Now they see things in 64-bit units. Of coure you'll have to explain what a bit is, but that isn't hard to understand.
StrangerGuy
Diamond Member
- May 9, 2004
- 8,443
- 124
- 106
With 32-bit you can fit up to 4 people into a car. Now with 64-bit, you can fit up to 8 people into a car. Note the "up to".
Kougar
Senior member
- Apr 25, 2002
- 398
- 1
- 76
Yeah... take Stranger's analogy but mention there are 32 people waiting on that car to take them to wherever. The work just gets done faster.
What's neat is from the Conroe/Woodcrest benches I've seen, 64-bit computing seems to finally be proving it's advantages over the same apps running in 32bits. Looking forward to the official benchmarks on this to be beyond a doubt certain though.
What's neat is from the Conroe/Woodcrest benches I've seen, 64-bit computing seems to finally be proving it's advantages over the same apps running in 32bits.
Looking forward to the official benchmarks on this to be beyond a doubt certain though.
secretanchitman
Diamond Member
- Apr 11, 2001
- 9,352
- 23
- 91
cant wait for conroe...looks promising especially in 64 bit. doesnt the NDA get lifted on june 4th?
Jeff7181
Lifer
- Aug 21, 2002
- 18,368
- 11
- 81
Depends on whether you're talking about 64-bit processors in general, or AMD64 and EMT64.
If you're talking in the general sense, what it does is allow the CPU to work with bigger numbers. Now instead of being limited to 32 digit numbers, they can use 64 digit numbers. Obviously as amounts of memory increase, the use of larger numbers will be required... but it also allows for greater precision.
The need for that isn't really here today, however, AMD made a few improvements along with going to 64-bit wide registers, like doubling the amount of general purpose registers as a 32-bit x86 CPU. If you want an in detail explanation of that, Arstechnica has some GREAT articles explaining it. But in the most basic sense, a GPR is an extremely fast type of memory (because it's VERY close to the actual execution core) where data values are stored that are currently being processed. For example, simple math... 1+1=2... 1 and 1 are stored in GPR's, the CPU combines whatever is in those GPR's, and the sum is stored in another GPR. When it runs out of GPR's it has to send data to memory (including L1 cache, L2 cache, L3 cache if it exists, system RAM, and finally virtual memory on the hard drive if necessary) which is MUCH slower than GPR's. Adding more GPR's basically means it needs the cache less for the same task, so the task gets done sooner... or... it can do more in the same amount of time. But again, this is not applicable to ALL 64-bit processors, this has to do with other architectural chances AMD made while moving to 64-bit processing.
If you're talking in the general sense, what it does is allow the CPU to work with bigger numbers. Now instead of being limited to 32 digit numbers, they can use 64 digit numbers. Obviously as amounts of memory increase, the use of larger numbers will be required... but it also allows for greater precision.
The need for that isn't really here today, however, AMD made a few improvements along with going to 64-bit wide registers, like doubling the amount of general purpose registers as a 32-bit x86 CPU. If you want an in detail explanation of that, Arstechnica has some GREAT articles explaining it. But in the most basic sense, a GPR is an extremely fast type of memory (because it's VERY close to the actual execution core) where data values are stored that are currently being processed. For example, simple math... 1+1=2... 1 and 1 are stored in GPR's, the CPU combines whatever is in those GPR's, and the sum is stored in another GPR. When it runs out of GPR's it has to send data to memory (including L1 cache, L2 cache, L3 cache if it exists, system RAM, and finally virtual memory on the hard drive if necessary) which is MUCH slower than GPR's. Adding more GPR's basically means it needs the cache less for the same task, so the task gets done sooner... or... it can do more in the same amount of time. But again, this is not applicable to ALL 64-bit processors, this has to do with other architectural chances AMD made while moving to 64-bit processing.
zephyrprime
Diamond Member
- Feb 18, 2001
- 7,512
- 2
- 81
FelixDeCat
Lifer
- Aug 4, 2000
- 30,957
- 2,670
- 126
This is pretty depressing. :disgust:
Despite my occasional personal crusade for getting people to correctly understand this, almost EVERY poster in this thread posts the WRONG answer.
Viditor has it correct in the second post in this thread. Then comes a lot of cheerful but misleading answers along the easily presumed, but nevertheless oh so false, "twice as fast" analogies.
Salutes Zephyrprime though for "Simple. I don't. I might as well try to explain reading to monkeys. " Indeed, he has a point here!
Since Anantech has, for some reason, deleted the thread that contain my main exhaustive articles on this matter, I cannot post a link to a correct technical description. Most PC-magazines and websites also publish misleading, irrelevant and incomplete information on this topic.
"In layman terms" ? As Zephyrprime suggests that is a pretty tall order. Unless you're ok with Viditors simple answer.
Let me start with the wrong answers:
An ancient custom refered/refers to computer and CPU architectures' n-bit property by the length of their registers. This was relevant in the very early days when processors were very spartan and simple and only consisted of some thousands of transistors. This was these processors' width of computing. So from this also comes the understanding that this n-bit property is about width of computing. Like that the "processor operates on 64 bit data at a time instead of 32-bit". (And thus supposedly is twice as fast).
However this picture of what goes on inside a general computing CPU has not been much relevant for at least 15 years. And it ever was mostly relevant on (today) weird things like 8-bit and 40-bit computers. It has very little to do with what goes on in modern CPUs or what we consider with 16-32-64-bit computing.
Modern CPUs operate on data in whatever widths are appropriate for the type of data! And they possess registers that are wide enough for that purpose.
A character is either 8 or 16 bit long.
An integer, index or counter is usually 16 or 32 bit long.
A floating point number is 32 or 64 bit long.
Thus a "32-bit" Pentium 4, for instance, has 64-bit floating point registers for operations on floating point numbers. Because 64-bit registers are appropriate for the purpose.
Of course it seems a bit overkill to use a 32-bit register to perform operations on 8-bit pieces of data, one at a time. But why not do four 8-bit data ops in one go? So it suggests also the interesting possibility of performing an identical operation on several pieces of data at once. This exists since MMX and is called SIMD or vector operations.
And again, thus a "32-bit" Pentium 4, for instance, has 128-bit SIMD registers for vector operations on almost anything from sixteen 8-bit integers to two 64-bit floating point numbers. This is the type of width of computing that has any relation at all to width of registers. And as you see it is long used by CPU designers for performance reasons and has nothing whatsoever to do with the Pentium 4's "32-bitness".
Another type of width of computing is the fact that modern processors have several parallel lines of execution. The Pentium 4 has two execution pipelines. Athlon64 has three and Conroe aka Core2 has four. Again I hope you see that the "width of computing" is something that is aggressively pursued by CPU's for the obvious performance benefits, and that is has absolutely nothing to do with the CPUs 32-bit or 64-bit property.
So what is the 64-bit issue about then?
The first thing to understand is that it is a property of the program code. A 64-bit processor does not operate as a 64-bit processor unless it is fed 64-bit software. The very fact that AMD86-64 is backward compatible with old 32-bit code and the fact that we still (at least on Windows) are using almost exclusively 32-bit software may have served to hide this fact from many.
An Athlon64 that runs on 64-bit software is a new, different processor executing new, different machine code than an Athlon64 running 32-bit software. Running 32-bit software, it operates basically the same way as everything dating back to the '386.
Quite a few things are different, but the key issue that has to do with the "64-bitness" is the way the program refers to itself. A program needs to identify and refer to each piece of data it manipulates, as well as each program instruction itself is made up of.
The executable code and the data lives in something called virtual space. Every byte inside this space is assigned a virtual address.
Then every virtual address that is actually used by the software for holding something, is connected to a unique hardware byte location in either RAM or swap area on the HD. This is done by the OS with a paged mapping process, and the application software has nothing to do with it. And I will not concern myself or 64-bit computing any more with this hardware mapping. Because 16-32-64 bit is all about virtual memory space, not RAM.
In 16-bit software machine instructions can only refer to data with a 16-bit number. Since a 16-bit number only covers a 64KB range, a 16-bit program always have to make sure that the correct segment of the virtual space is selected. This segment is set by a certain register in the CPU.
In most 32-bit software (like Windows32 for example) we have chosen to have the entire virtual space made up of one single segment. Machine instructions refers to each byte of data with a single unique 32-bit number.
This is so much better and makes address arithmetic perfectly linear and so much simpler.
But there are still problems when we need to use large amount of memory. Theoretically the application can use as much memory as the virtual space allows (in Windows32 2GB). Hardware memory, RAM and swap, does not become fragmented thanks to the paging that the mapping process employs. But the virtual space does become fragmented. The program may ask for a 300KB block and while there may be like 800KB unused virtual space left, there might not be any 300KB large continuous free space.
Then we also have the other more obvious problem: We can't ever use more memory than the size of the virtual space which is maximum 4GB for 32-bit (and in fact Windows32 only allows 2GB normally and 3GB for some applications).
The current need for more memory is thus what forces a change in software format. The logical and technically best choice is 64-bit software.
64-bit software use and generate 64-bit virtual addresses. This means that we now have a phenomenally large virtual space. And this time it's also vastly much larger than the amount of memory we can use. The current K8 Athlon64, for instance, allows you to use 1 TB memory. But this total 1 TB of memory can be put anywhere inside a 256 TB large range in virtual space. So we don't have the problem of possible fragmentation of the virtual space that we have with 32-bit addressing.
Ultimately, AMD86-64 allows use of 4 PetaByte memory inside a 16 ExaByte large space.
From this use of 64-bit addresses now follows the new explicit need to do 64-bit address arithmetic in a rational manner. For that very reason, the 64-bit CPU now also comes with 64-bit integer registers and 64-bit integer operations.
Those 64-bit operations can of course be used for some other purposes as well.
But if there ever were a real need for 64-bit integer operations for performance reasons before, rest assured our processors would have received 64-bit integer registers and operations in some kind of extension long before. Just as it has received 64-bit FP registers and 64/128-bit SIMD registers.
But if we did not also get a new ISA with 64-bit addressing, that would not have made those 32-bit processors any "64-bit" at all, in the sense that we today refer to 16-bit, 32-bit and 64-bit computing.
Though I might well imagine there would have been a lot of very tiresome arguments with some people that persist in clinging to highly misleading, irrelevant and utterly meaningless associations with the bit width of "general purpose registers".
:disgust:Despite my occasional personal crusade for getting people to correctly understand this, almost EVERY poster in this thread posts the WRONG answer.
Viditor has it correct in the second post in this thread. Then comes a lot of cheerful but misleading answers along the easily presumed, but nevertheless oh so false, "twice as fast" analogies.
Salutes Zephyrprime though for "Simple. I don't. I might as well try to explain reading to monkeys. " Indeed, he has a point here!
Since Anantech has, for some reason, deleted the thread that contain my main exhaustive articles on this matter, I cannot post a link to a correct technical description. Most PC-magazines and websites also publish misleading, irrelevant and incomplete information on this topic.
"In layman terms" ? As Zephyrprime suggests that is a pretty tall order. Unless you're ok with Viditors simple answer.
Let me start with the wrong answers:
An ancient custom refered/refers to computer and CPU architectures' n-bit property by the length of their registers. This was relevant in the very early days when processors were very spartan and simple and only consisted of some thousands of transistors. This was these processors' width of computing. So from this also comes the understanding that this n-bit property is about width of computing. Like that the "processor operates on 64 bit data at a time instead of 32-bit". (And thus supposedly is twice as fast).
However this picture of what goes on inside a general computing CPU has not been much relevant for at least 15 years. And it ever was mostly relevant on (today) weird things like 8-bit and 40-bit computers. It has very little to do with what goes on in modern CPUs or what we consider with 16-32-64-bit computing.
Modern CPUs operate on data in whatever widths are appropriate for the type of data! And they possess registers that are wide enough for that purpose.
A character is either 8 or 16 bit long.
An integer, index or counter is usually 16 or 32 bit long.
A floating point number is 32 or 64 bit long.
Thus a "32-bit" Pentium 4, for instance, has 64-bit floating point registers for operations on floating point numbers. Because 64-bit registers are appropriate for the purpose.
Of course it seems a bit overkill to use a 32-bit register to perform operations on 8-bit pieces of data, one at a time. But why not do four 8-bit data ops in one go? So it suggests also the interesting possibility of performing an identical operation on several pieces of data at once. This exists since MMX and is called SIMD or vector operations.
And again, thus a "32-bit" Pentium 4, for instance, has 128-bit SIMD registers for vector operations on almost anything from sixteen 8-bit integers to two 64-bit floating point numbers. This is the type of width of computing that has any relation at all to width of registers. And as you see it is long used by CPU designers for performance reasons and has nothing whatsoever to do with the Pentium 4's "32-bitness".
Another type of width of computing is the fact that modern processors have several parallel lines of execution. The Pentium 4 has two execution pipelines. Athlon64 has three and Conroe aka Core2 has four. Again I hope you see that the "width of computing" is something that is aggressively pursued by CPU's for the obvious performance benefits, and that is has absolutely nothing to do with the CPUs 32-bit or 64-bit property.
So what is the 64-bit issue about then?
The first thing to understand is that it is a property of the program code. A 64-bit processor does not operate as a 64-bit processor unless it is fed 64-bit software. The very fact that AMD86-64 is backward compatible with old 32-bit code and the fact that we still (at least on Windows) are using almost exclusively 32-bit software may have served to hide this fact from many.
An Athlon64 that runs on 64-bit software is a new, different processor executing new, different machine code than an Athlon64 running 32-bit software. Running 32-bit software, it operates basically the same way as everything dating back to the '386.
Quite a few things are different, but the key issue that has to do with the "64-bitness" is the way the program refers to itself. A program needs to identify and refer to each piece of data it manipulates, as well as each program instruction itself is made up of.
The executable code and the data lives in something called virtual space. Every byte inside this space is assigned a virtual address.
Then every virtual address that is actually used by the software for holding something, is connected to a unique hardware byte location in either RAM or swap area on the HD. This is done by the OS with a paged mapping process, and the application software has nothing to do with it. And I will not concern myself or 64-bit computing any more with this hardware mapping. Because 16-32-64 bit is all about virtual memory space, not RAM.
In 16-bit software machine instructions can only refer to data with a 16-bit number. Since a 16-bit number only covers a 64KB range, a 16-bit program always have to make sure that the correct segment of the virtual space is selected. This segment is set by a certain register in the CPU.
In most 32-bit software (like Windows32 for example) we have chosen to have the entire virtual space made up of one single segment. Machine instructions refers to each byte of data with a single unique 32-bit number.
This is so much better and makes address arithmetic perfectly linear and so much simpler.
But there are still problems when we need to use large amount of memory. Theoretically the application can use as much memory as the virtual space allows (in Windows32 2GB). Hardware memory, RAM and swap, does not become fragmented thanks to the paging that the mapping process employs. But the virtual space does become fragmented. The program may ask for a 300KB block and while there may be like 800KB unused virtual space left, there might not be any 300KB large continuous free space.
Then we also have the other more obvious problem: We can't ever use more memory than the size of the virtual space which is maximum 4GB for 32-bit (and in fact Windows32 only allows 2GB normally and 3GB for some applications).
The current need for more memory is thus what forces a change in software format. The logical and technically best choice is 64-bit software.
64-bit software use and generate 64-bit virtual addresses. This means that we now have a phenomenally large virtual space. And this time it's also vastly much larger than the amount of memory we can use. The current K8 Athlon64, for instance, allows you to use 1 TB memory. But this total 1 TB of memory can be put anywhere inside a 256 TB large range in virtual space. So we don't have the problem of possible fragmentation of the virtual space that we have with 32-bit addressing.
Ultimately, AMD86-64 allows use of 4 PetaByte memory inside a 16 ExaByte large space.
From this use of 64-bit addresses now follows the new explicit need to do 64-bit address arithmetic in a rational manner. For that very reason, the 64-bit CPU now also comes with 64-bit integer registers and 64-bit integer operations.
Those 64-bit operations can of course be used for some other purposes as well.
But if there ever were a real need for 64-bit integer operations for performance reasons before, rest assured our processors would have received 64-bit integer registers and operations in some kind of extension long before. Just as it has received 64-bit FP registers and 64/128-bit SIMD registers.
But if we did not also get a new ISA with 64-bit addressing, that would not have made those 32-bit processors any "64-bit" at all, in the sense that we today refer to 16-bit, 32-bit and 64-bit computing.
Though I might well imagine there would have been a lot of very tiresome arguments with some people that persist in clinging to highly misleading, irrelevant and utterly meaningless associations with the bit width of "general purpose registers".
An absolutely superb bit of writing Vee!!
:wine:
Mods...if you could find a place to sticky this, I'm sure that it would be appreciated by many posters.
One thing to note that will be apparent if you try to visualize what Vee has said here...
The performance difference between 32 and 64 bit is almost non-existent when you are using a smaller amount of the virtual space...but as you begin to use larger amounts of virtual space, 32 bit becomes slower while 64 bit does not (relatively speaking).
Think of a 10 GB HDD that gets fragmented and slows down as you use a larger percentage of it's available space...if you perform the same functions on a 100 GB HDD, you won't see the same drastic slowing. Of course this is also subject to available physical storage, but all things being equal there should be a greater and greater difference as you increase your memory usage.
:wine:
Mods...if you could find a place to sticky this, I'm sure that it would be appreciated by many posters.
One thing to note that will be apparent if you try to visualize what Vee has said here...
The performance difference between 32 and 64 bit is almost non-existent when you are using a smaller amount of the virtual space...but as you begin to use larger amounts of virtual space, 32 bit becomes slower while 64 bit does not (relatively speaking).
Think of a 10 GB HDD that gets fragmented and slows down as you use a larger percentage of it's available space...if you perform the same functions on a 100 GB HDD, you won't see the same drastic slowing. Of course this is also subject to available physical storage, but all things being equal there should be a greater and greater difference as you increase your memory usage.
Jeff7181
Lifer
- Aug 21, 2002
- 18,368
- 11
- 81
Originally posted by: Vee
This is pretty depressing.
Despite my occasional personal crusade for getting people to correctly understand this, almost EVERY poster in this thread posts the WRONG answer.
... etc. etc. etc.
Nice dissertation, but I doubt a layman would get past, "An ancient custom refered/refers to computer and CPU architectures' n-bit property by the length of their registers."
They don't care that SIMD registers are 128 bits wide, or that the external data bus has been 64 bits wide since the original Pentium (and is now 128 bits wide with dual channel memory). They want to know why they're buying an Athlon 64 and Windows XP x64 edition instead of an Athlon 32 and Windows XP x32 edition.
FelixDeCat
Lifer
- Aug 4, 2000
- 30,957
- 2,670
- 126
Originally posted by: Jeff7181
Originally posted by: Vee
This is pretty depressing.
Despite my occasional personal crusade for getting people to correctly understand this, almost EVERY poster in this thread posts the WRONG answer.
... etc. etc. etc.
Nice dissertation, but I doubt a layman would get past, "An ancient custom refered/refers to computer and CPU architectures' n-bit property by the length of their registers."
Ding...ding...ding..winnah!
HardWarrior
Diamond Member
- Jan 26, 2004
- 4,400
- 23
- 81
You impress easily. It was an exercise is overblown grandstanding that in no way addressed the OP.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 22K
-
News NVIDIA and Intel to Develop AI Infrastructure and Personal Computing Products- Started by poke01
- Replies: 369
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
Facebook
Twitter