64-Bit

[Frew]

Can somone tell me what is technically differnt between 32-bit and 64-bit?

 

[GoHAnSoN]

64 bit is 2x of 32 bit ?

 

[Wahsapa]

it depends on the cpu, because 'technically' theres a whole lot different from cpu to cpu. not all 64bit cpus are the same. ibm 64bit cpu's do things different then intel 64bit cpus do things different then amd 64bit cpus. the realtive difference is that its able to handle one giant chunk of 64bit data as compared to 32bit cpus only being able to process a 'smaller' 32bit chunk.

 

[Frew]

Originally posted by: Wahsapa
it depends on the cpu, because 'technically' theres a whole lot different from cpu to cpu. not all 64bit cpus are the same. ibm 64bit cpu's do things different then intel 64bit cpus do things different then amd 64bit cpus. the realtive difference is that its able to handle one giant chunk of 64bit data as compared to 32bit cpus only being able to process a 'smaller' 32bit chunk.

If it supossivly can handle twice as much data... Shouldn't there be twice the performance gain?

 

[JeremiahTheGreat]

Not twice.. 2 X 2^32 does not equal 2^64 !!

It does not yield double the performance either, it just means you can address 2^64 bits of memory, or store a integer thats upto 2^64 in magnitude. You could say 32bit is like a car, and 64bit like a truck - one can carry more - but if you're only delivering pizzas, it doesn't matter. (ok, ignore the weight differences and stuff, concentrate on carrying capacity).



then again, I did only ever do 2 months of computer science before going over to biochemistry lol

 

[Dinominant]

wouldn't you be able to preform an operation on a full 64 bit number in one clock cycle? So couldn't you just slap 2 32 bit numbers side by side, and do an operation on both at the same time (where applicable). Wouldn't that give you a 2x performance gain (once again, where applicable)?

 

[imgod2u]

Originally posted by: Dinominant
wouldn't you be able to preform an operation on a full 64 bit number in one clock cycle? So couldn't you just slap 2 32 bit numbers side by side, and do an operation on both at the same time (where applicable). Wouldn't that give you a 2x performance gain (once again, where applicable)?

Problem is, most programs don't deal with numbers of that size. Doing 2 operations on smaller numbers is not the same, and cannot, in most cases, be replaced by doing 1 operation on a large number. Programs are typically very simple instructions on small pieces of data, there just happens to be a lot of instructions and a lot of data. Making these simple, small operations very very fast is much more important typically than making calculations on huge numbers fast. We see this idea behind Netburst.

 

[cKGunslinger]

If you have a CPU-bound application that has a lot of 64-bit math operations, then you will see a performance boost from an equivalent 32-bit CPU. Otherwise, a true 64-bit CPU will offer no speed advantage (and most likely, a reduction in performance.)

The reason AMD's 64-bit CPUs benchmark faster are because of other architectural changes, like additional registers and the memory interconnects.

 

[Sahakiel]

Originally posted by: Dinominant
wouldn't you be able to preform an operation on a full 64 bit number in one clock cycle? So couldn't you just slap 2 32 bit numbers side by side, and do an operation on both at the same time (where applicable). Wouldn't that give you a 2x performance gain (once again, where applicable)?

That's what SIMD engines do. However, they can only operate in specific circumstances.

 

[Vee]

Originally posted by: LeadFrog
Can somone tell me what is technically differnt between 32-bit and 64-bit?

The short answer is the addressing capability! 64-bit software can handle larger data models.
For a more complete answer you might be interested in this:
(This mainly concerns x86-64, 64-bit for the PC, but that's maybe what you're interested in.)

The things you need to know:

Q: Why would we need a 64-bit processor?
A:
In order to be able to run 64-bit software.

Q: Why would we need to run 64-bit software?
A:
Because 32-bit applications and OSes are at the end of the line. They basically can't evolve much farther, from where they are today.

Q: Do you need a 64-bit OS to run 64-bit applications?
A:
Yes. Due to the way hardware is handled in our modern days, there won't be the option of launching a 64-bit app in DOS mode, as were the case with 32-bit DOS games. It has to run under an OS.
Neither is it possible to even imagine some kind of 'emulator' running 64-bit apps under a 32-bit OS, because of much the same reasons you can't ever transport a 747 jumbojet in the trunk of a car.

Q: Are there many 64-bit apps around?
A:
No, not yet, but there can't really be, until there's 64-bit PCs out there on the market, ready to run them. Intel introduced 32-bit mode with the '386 long time ago. But it really wasn't used as 32-bit much, until Win95 and Linux came along much later. But there wouldn't have been any Win95 or Linux, without 32-bit cpus out there, ready to run them.

Q: Is there any 64-bit OS available?
A:
Yes, there's a beta version of WindowsXP64, that works pretty ok. And there's Linux of course.

Q: Why should anyone buy a 64-bit processor now then?
A:
For right now, primarily as a fast 32-bit cpu, with a 32-bit OS. Same as '386 and '486, in the old days, which were mostly used as fast 16-bit cpus.
But this time, migration could be much faster. Reason is need. The number of developers for the iAMD'86-64 ISA passed 1000, on the 11 of February '04.
Games, Tech/Engineering, 3D modeling and various Cinematic applications will lead the way. And there's currently an explosive growth of demand in AMD64 servers and workstations.

Q: Is 64-bit about processing larger/wider chunks of data at time, thus increasing performance?
A:
- Oh NO! - Not at all! No matter how many times this bullshit is repeated by PC-rags, journalists, analysts or whatever authorities people tend to trust. - This is bullshit and just something that is commonly assumed. - wrongly!
Data widths and paths are exactly the same as in 32-bit cpus today.
Character is 8bit or 16bit (unicode).
Integer still defaults to 32 bit, even if integer registers are now 64bit wide.
Fp is still 32bit and 64bit (double precision).
Vectors also remain, for now, 64 and 128bit.
Now, on the other hand: The Instructions' address fields, used to refer to location of data, is 64bit instead of 32bit. This is the difference!
Software pointers are 64 bit long, instead of 32 bit. To handle pointer arithmetic efficiently, integer registers are 64 bit wide.

Q: But 64-bit will be faster, right?
A:
Yes, somewhat faster.

Q: But why then?
A:
Because new addressing needs a new ISA, new binaries. Since we have to define a new instruction set anyway, might as well make it a little bit more modern, clever and rational than Intel's old '86 ISA. So we've got more flexible registers, more of them, and instructions making use of them. In 64-bit mode that is. That's one reason why it will be faster. Another reason is that memory mapping is simpler and more streamlined.
Some early ports hint at 40-50% improvements, but this is really up to the compiler's ability to optimize for the additional registers.

Q: Is that why 64-bit cpus run 32-bit code faster?
A:
No, not at all. 32-bit applications run on AMD'86-64 processors just like on 32-bit processors, with all the same limitations. The reason AMD's 64-bit cpus are so fast, even on 32-bit mode, is that they're a new generation of processor technology, K8 core, that is more efficient and higher performing. Again it's analogous to the old '386 and '486, that were faster than '286 in 16-bit mode, for exactly the same reason.

Q: Will we need 64-bit applications then, if it's only "somewhat" faster?
A:
- Oh, big YES! Definitly!
32 bits can only address 4GB. (without a terrible segmented memory model noone wants)
There's a 2GB memory limit imposed on 32-bit Windows apps! This is not just a limit on ram, it's the absolute limit of the virtual memory model available to an app. So it's quite serious. Remember, that a virtual memory map is highly fragmented.
For all the bullshit from Intel and the likes of tomshardware, pretending 32-64 bits is no issue, the harsh truth is that PC computing will go nowhere at all, from where it is today, on 32 bits. We absolutely need 64-bit to move on!
Consider the old 640KB limit of 8086. This is where we are again today.
And it's not just the application. The hardware, OS and it's various objects, also need to be mapped into other sections of the 32 bit's 4GB space.
Consider for instance the case of memory for increasingly advanced 3D graphic cards. Today we're already at 256MB. This competes with other OS services for space in one single GB of Windows 32-bit map. Will 32-bit tolerate more? Well, not much more, anyway. You can count on that. Just as you can count on increasingly advanced 3D graphics technology to demand more.

Q: But the PC managed to get by with Windows16 for many years, while Mac and others were 32-bit. Won't it be the same this time?
A:
No. The 16-32 bit migration and 32-64 bit migration are two completely different aspects of addressing technology. 16-32 bits were about moving from a segmented addressing model to a flat linear 32-bit memory model. While 16-bit computing was contorted, slow and buggy, it could well perform the type of tasks that were feasible on the amounts of RAM that were affordable in those days. We're talking about 2 - 16MB.
This is not the case now. Both 32 and 64 bit are linear addressing. This time it's about the size of the memory model. And while you could have a 16-bit Photoshop on Windows3.11, even while a 32-bit version performed better on a Mac, that won't be the case with 32/64 bit. There is no chance of a 32-bit app being able to perform the kinds of tasks that 64-bit computing will bring.

Q: When are we ready to migrate to 64-bits?
A:
- Well, we still need the apps to make use of it, ok? But in general terms, like yesterday. We're late. For all their market bullshit again, protecting their P4s and Itanium, Intel originally intended the desktop to migrate in like 2002-03. But they didn't get their cpu stuff together. Got caught up in a GHz cpu war with AMD and figured the P4 was the right answer for that. Now we will migrate while banging our heads into the 2GB barrier, rather than before, in good time and comfort.

Q: But why would we need all that memory. Isn't it just for bloatware?
A:
No. Explained in detail it goes like this:
The software and forms of use of the PC, that are available at any given time, are defined by memory needed for models/objects being handled.
Thus, simple writing, editing, calculating could be done on a 16-64KB CP/M text only display 8-bit PC.
There were lots of people around at the time who figured 128KB and 8 bits were enough for all PC use forever. But that is just because they couldn't fit into their mind to use computers as WYSIWYG publishing tools. Or editing pictures. (-"Photographs in a computer?! - Ho, ho it would need like a MEGABYTE ram for graphics! - Ha! Impossible!")
Creating/editing music and sound. Rendering realistic images. Editing video. Solid modeling. Physics simulations. Voxel handling/displaying (Adam & Eve, CAT-scan etc).
All these new uses for the computer came about as the necessary amounts of memory became available.
So it's ultimately the price of RAM and harddrives that dictates what we will use a computer for!
So, take a good look at that limit of about 1.5GB (practical, remember fragmentation) and compare to prices on RAM and capacity of harddrives. And compare it to how much memory (Including swap! It's important to understand that it's about the size of the virtual map! Not just ram!) you yourself tend to use today. And by all means, how much recent games require. Then, looking backwards for historical guidance, try figure where we will be in 12-18 months.

Q: So what's the memory limit for 64-bit code then?
A:
Well, the virtual space to rumble around in, is fully 16 ExaBytes.
But "only" 4 PetaBytes in that space can be mapped, so that's the limit.

However, that is for AMD'86-64 as such, not for the current K8's.
Current K8's have 256 Terabytes space to rumble around in, but "only"
a total of 1 TeraByte can be mapped, so that's the limit of virtual memory. But again, the space is much bigger, which should be a help for many things, including fragmentation.

Finally, WindowsXPx64 puts on some further limits. You have 16GB memory (per process, I assume) from a virtual space of 16TB. Yes, 16GB seems a bit on the low side, but it's only "currently", so hopefully it's not a definite limit.

One ExaByte is 1024 PetaBytes.
One PetaByte is 1024 TeraBytes.
One TeraByte is of course 1024 GigaBytes, which you might already be familiar with.

More immediately, current implementations of iAMD'86-64 processors, both AMD and Intel, are of course more limited in physical address space. In case of AMD, the most constrictive component is the integrated memory controller. But the important thing is that the software memory model is not limited. It will have enough addresses.

Q: So we're not likely to see 128-bit or 96-bit addressing soon then?
A:
No, if it happens at all in our lifetime, we're probably going to be in a state where we don't care much anymore anyway.
We are most certainly though, going to see increased widths of paths and vector processing though. This is the width that is intuitively mostly mistaken for being the "bit -issue". Take for instance the case of marketing game consoles. Currently, on the PC, on our "32-bit" cpus, that width is 128-bits. But rest assure, that this will increase to 256, 512, 1024... on "64-bit" cpus.

Q: When should I get a 64-bit system?
A:
Well, it's up to you.
One advantage of a 64-bit system is that it will eventually be useful for running 64-bit apps.
Still, maybe one should consider this as a question of what level of 32-bit performance you'd like to pay for. Just like any other ordinary PC purchase.
It's not like you're really paying anything extra or premium prices for 64-bitness.

 

[CTho9305]

Originally posted by: Vee
Q: Is 64-bit about processing larger/wider chunks of data at time, thus increasing performance?
A:
- Oh NO! - Not at all! No matter how many times this bullshit is repeated by PC-rags, journalists, analysts or whatever authorities people tend to trust. - This is bullshit and just something that is commonly assumed. - wrongly!
Data widths and paths are exactly the same as in 32-bit cpus today.

I think the datapath is 64 bits. I'm pretty sure you can use 64 bit values in the R** registers (RAX, RBX, etc) for just about every instruction. In general, though, you don't need to use integers for numbers this big for regular data.

Character is 8bit or 16bit (unicode).
Integer still defaults to 32 bit, even if integer registers are now 64bit wide.
Fp is still 32bit and 64bit (double precision).
Vectors also remain, for now, 64 and 128bit.

True, but now you can use 64 bit integers. In the past, if you wanted to represent 4*1024*1024*1024, you had to do some ugly stuff. Now, you can represent it precisely.

There's a 2GB memory limit imposed on 32-bit Windows apps! This is not just a limit on ram, it's the absolute limit of the virtual memory model available to an app. So it's quite serious. Remember, that a virtual memory map is highly fragmented.

3GB with some switch, I believe. I'm not sure what you're talking about with fragmentation. Any good malloc implementation gives you pretty high usage.

Current K8's have 256 Terabytes space to rumble around in, but "only"
a total of 1 TeraByte can be mapped, so that's the limit of virtual memory. But again, the space is much bigger, which should be a help for many things, including fragmentation.

I thought all K8 cores had 40 bit physical addresses (opterons, A64) (or is it 48?).

One ExoByte is 1024 PetaBytes.

Exabyte

More immediately, current implementations of iAMD'86-64 processors, both AMD and Intel, are of course more limited in physical address space. In case of AMD, the most constrictive component is the integrated memory controller. But the important thing is that the software memory model is not limited. It will have enough addresses.

I think the AGUs on the actual CPUs chop addresses to 40 bits on AMD, and 36 bits on Intel. I don't believe it has anything to do with the integrated memory controller (or, to put it another way, if AMD redesigned the memory controller to handle 64 bit physical addresses, I still think the CPUs only generate 40 or 48 bits).

 

[imgod2u]

There's a 2GB memory limit imposed on 32-bit Windows apps! This is not just a limit on ram, it's the absolute limit of the virtual memory model available to an app. So it's quite serious. Remember, that a virtual memory map is highly fragmented.

3GB with some switch, I believe. I'm not sure what you're talking about with fragmentation. Any good malloc implementation gives you pretty high usage.

With paging, memory utilization is pretty good these days. However, without it, the best malloc implementations wouldn't be able to use more than roughly 50% of memory without being slow (defragment memory upon call). Again, paging helps this a lot and is used in almost all OS models these days. But there is still quite a bit of fragmentation, especially internal fragmentation.

 

[Vee]

Originally posted by: CTho9305

Originally posted by: Vee
Q: Is 64-bit about processing larger/wider chunks of data at time, thus increasing performance?
A:
- Oh NO! - Not at all! No matter how many times this bullshit is repeated by PC-rags, journalists, analysts or whatever authorities people tend to trust. - This is bullshit and just something that is commonly assumed. - wrongly!
Data widths and paths are exactly the same as in 32-bit cpus today.

I think the datapath is 64 bits. I'm pretty sure you can use 64 bit values in the R** registers (RAX, RBX, etc) for just about every instruction. In general, though, you don't need to use integers for numbers this big for regular data.

This is true, but datapaths can be, and are in many cases already larger than 32 bits in a 32-bit CPU. It doesn't have much to do with 64 bitness. Though there is a lot of 64-bit generalization in the K8.

Character is 8bit or 16bit (unicode).
Integer still defaults to 32 bit, even if integer registers are now 64bit wide.
Fp is still 32bit and 64bit (double precision).
Vectors also remain, for now, 64 and 128bit.

True, but now you can use 64 bit integers. In the past, if you wanted to represent 4*1024*1024*1024, you had to do some ugly stuff. Now, you can represent it precisely.

Yes, again true. But while useful, still not the big issue.

There's a 2GB memory limit imposed on 32-bit Windows apps! This is not just a limit on ram, it's the absolute limit of the virtual memory model available to an app. So it's quite serious. Remember, that a virtual memory map is highly fragmented.

3GB with some switch, I believe. I'm not sure what you're talking about with fragmentation. Any good malloc implementation gives you pretty high usage.

That 3GB is pretty much for special cases. Not universially useful. Secondly, that extra GB doesn't really solve anything, now does it?
I'm not sure what malloc has to do with the application's virtual memorymap? The application self has to move it's memory blocks, if we want to defragment the virtual map.

Current K8's have 256 Terabytes space to rumble around in, but "only"
a total of 1 TeraByte can be mapped, so that's the limit of virtual memory. But again, the space is much bigger, which should be a help for many things, including fragmentation.

I thought all K8 cores had 40 bit physical addresses (opterons, A64) (or is it 48?).

That's what I said. - K8s can map 1 Terabyte of virtual memory from a 48 bit space (256TB) to 1 Terabyte physical space (40 bits)
AMD'86-64, however, ultimately allows mapping 4 PetaBytes from a full 64-bit space to a 52-bit physical address.

One ExoByte is 1024 PetaBytes.

Exabyte

Thankyou!

More immediately, current implementations of iAMD'86-64 processors, both AMD and Intel, are of course more limited in physical address space. In case of AMD, the most constrictive component is the integrated memory controller. But the important thing is that the software memory model is not limited. It will have enough addresses.

I think the AGUs on the actual CPUs chop addresses to 40 bits on AMD, and 36 bits on Intel. I don't believe it has anything to do with the integrated memory controller (or, to put it another way, if AMD redesigned the memory controller to handle 64 bit physical addresses, I still think the CPUs only generate 40 or 48 bits).

Well, I only meant that the integral memorycontroller, as of today, can only handle 4GB ram. And that then becomes the most constrictive component.
That has indeed nothing to do with the memory manager, as you said, which can handle 1 Terabyte, or physical address space which is 40 bits. And if later AMD'86-64 implementations allow mapping from the full 64 bits, that would map into 52 bits.

 

[CTho9305]

Originally posted by: Vee
This is true, but datapaths can be, and are in many cases already larger than 32 bits in a 32-bit CPU. It doesn't have much to do with 64 bitness. Though there is a lot of 64-bit generalization in the K8.

Well, stuff like the floating point unit used 80-bit datapaths in previous designs, but the integer execution units (which handle the majority of instructions in normal code) were 32 bits wide, but I'm starting to nitpick .

I'm not sure what malloc has to do with the application's virtual memorymap? The application self has to move it's memory blocks, if we want to defragment the virtual map.

I'm still not sure what you mean by defragment. Fragmentation caused by code like this?

foo = malloc(100)
bar = malloc(100)
free(foo)
foobar = malloc(101)

That will always be a problem, but good malloc implementations can help reduce the space waste. The problem will be just as bad at 64 bits - you just have about 4 billion times more space available to waste.

Well, I only meant that the integral memorycontroller, as of today, can only handle 4GB ram.

Ah, I did not know that.

 

[Vee]

I'm still not sure what you mean by defragment. Fragmentation caused by code like this?

quote:

--------------------------------------------------------------------------------
foo = malloc(100)
bar = malloc(100)
free(foo)
foobar = malloc(101)
--------------------------------------------------------------------------------


That will always be a problem, but good malloc implementations can help reduce the space waste. The problem will be just as bad at 64 bits - you just have about 4 billion times more space available to waste.

No, the problem is of course not at all as bad?
The problem should pretty much just go away. The reason is that you can put the blocks anywhere in a space that is 256 times larger than you could ever use.

In the case of our 32-bit addressing, I would say the 2GB limit is the real problem. But I did want to point out that you will never get to use all those 2GB, because of the fragmentation of the applications virtual map.
It seems to be a widely held belief that 32-bit cpus are good enough, as long as we don't need more than 4GB physical RAM (!?!). I wanted to stress that the problem of 32-bitness is different, and quite more serious than that. And when we approach the limits of addressing, the fragmentation of the virtual map will always be a very real and tangible fact.

This in sharp contrast with AMD'86-64 addressing, where, I think, we will never see fragmentation of the virtual map as a relevant issue. Not even when we use up the full 1 TeraByte.

 

[CTho9305]

But fragmentation will be an issue when/if we ever use up a large percent of the 18446744073709551616 addressable bytes, correct?

 

[Vee]

Originally posted by: CTho9305
But fragmentation will be an issue when/if we ever use up a large percent of the 18446744073709551616 addressable bytes, correct?

Well, we don't have 18446744073709551616 (ouch!) addressable bytes. If we had, you'd be right. So yes, correct.

But there is the 'mapping-to-52-bit' resp. 'mapping-to-40-bit' by paging, working as a limit before fragmentation should be an issue.
If we consider the case of full 64-bit addressing (rather than the current '48-bit'(sic)) we have "only" 2^52 addressable bytes. I suppose, if we need more, we'll have to migrate to 128-bit addressing.

Edit: P.S. However, it might well be time to consider that the Windows64 implementation, which I know nothing about sofar, will have it's say about limits too.

Edit2: Well, WindowsXPx64 supports 16GB from a virtual space of 16TB. Hopefully, this will increase in future versions, because it seems a little bit on the low side. (It might be Intel's cludged EM64T have something to do with this...)