What does 64 bits do for you??

[moemac8]

All I know is that a 64bit OS will address alot more memory than a 32 bit will. What else will it do. Will it be alot faster if you have a 64bit OS and program?? Will it have better security?? Can someone explain this to me...just the basics please.

 

[Wicked2010]

The registers on the CPU will now be 64-bits. Meaning, you can push around twice the amount of data than before. So basically the bandwidth is doubled. Think of it as a highway. If you had 32 lanes for traffic before, you are definitely going to get more cars down the highway with 64 lanes instead.

And as you said, you can now address more memory. Before we could address up to 4 GB of memory... with 64 bits it will now be 17179869184 GB of memory. Which will last until the year 3000 probably... lol. Although 128 bit will come someday just to increase bandwidth.

That's it!!

 

[Acanthus]

Originally posted by: Wicked2010
The registers on the CPU will now be 64-bits. Meaning, you can push around twice the amount of data than before. So basically the bandwidth is doubled. Think of it as a highway. If you had 32 lanes for traffic before, you are definitely going to get more cars down the highway with 64 lanes instead.

And as you said, you can now address more memory. Before we could address up to 4 GB of memory... with 64 bits it will now be 17179869184 GB of memory. Which will last until the year 3000 probably... lol. Although 128 bit will come someday just to increase bandwidth.

That's it!!

It is my understanding that the A64 cannot address memory in 64 bit, although it does address more than 32bit (4GB) its somewhere in the neigborhood of 42-48bit (ive heard but dont remember).

 

[Wicked2010]

Even if it's 33 bit instead of 32 bit, then we now have at least 8 GB of addressable space. It keeps doubling for each bit you add.

We clearly won't need all 64 bits until ... well.. possibly never.

 

[Acanthus]

Originally posted by: Wicked2010
Even if it's 33 bit instead of 32 bit, then we now have at least 8 GB of addressable space. It keeps doubling for each bit you add.

We clearly won't need all 64 bits until ... well.. possibly never.

I agree we dont even need 40 bit addressing, was just making sure it was clear.

I have no idea if intel is the same with memory addressing or not, but im guessing that because its the same x86-64 extensions as AMD, that they are identical in addressing capability.

 

[Leper Messiah]

its more effiecent, but really useless until programming that is capable of ulitzing it comes out.

 

[DAPUNISHER]

Search for posts on the topic by Vee, very illuminating stuff Panorama Factory and Cakewalk SONAR 4 are already showing impressive results from going 64bit, and even games look to benfit from it. We'll get a chance to see with FarCry 64bit shortly how/if/what it can do in that area. The screenies they released are low res so hardly an indication of what to really expect from IQ IMO, and perhaps a nice FPS boost will accompany, or at least similar FPS with more details. Besides, 64bit is just sweet icing, what these AMD 64bit CPUs do in 32bit is the fluffy, warm, and moist cake underneath, and the glass of cold milk!

 

[kylef]

Originally posted by: Wicked2010
The registers on the CPU will now be 64-bits. Meaning, you can push around twice the amount of data than before. So basically the bandwidth is doubled. Think of it as a highway. If you had 32 lanes for traffic before, you are definitely going to get more cars down the highway with 64 lanes instead.

This is very, very misleading. Please do not spread statements like this, because it simply promotes more 64-bit ignorance.

Increasing register size from 32-bit to 64-bit has virtually no effect on I/O performance as you are claiming. If programs simply shuffled data around in registers with the goal being to maximize the amount of data transferred, you would be correct. But the vast majority of programs do not work this way!

Think about a simple operation like this (adding two numbers together):

load r1, @r3 # a = value1
load r2, @r4 # b = value2
addu r1, r1, r2 # a = a + b

For these instructions, you have gained *nothing* by moving from 32-bit to 64-bit. This takes exactly the same amount of time to execute on a 32-bit platform as a 64-bit platform for ALL values that can be stored in a 32-bit register. The ONLY case where the 64-bit platform is faster is for values of a and b that cannot be stored in 32-bits (i.e., greater than 4 billion). But that is a very uncommon case.

Actually, the above code will usually execute SLOWER on the 64-bit platform because the code size has increased to handle 64-bit pointers and registers. On AMD64, the average instruction length for 64-bit instructions has increased by roughly 0.7 bytes. This extra overhead accomplishes nothing for most data sets, and causes two serious performance hits: 1) the instruction cache is less effective (its capacity is reduced, and locality has decreased) and 2) page fault probability has increased.

The ONLY factor that offsets this increase in average instruction length for the AMD64 instruction set is that the total instruction count for AMD64 programs is smaller than that for IA32, because the extra 8 general purpose registers available to 64-bit instructions allows compilers to generate fewer register load/stores (more storage for temporaries).

 

[Duvie]

Originally posted by: kylef

Originally posted by: Wicked2010
The registers on the CPU will now be 64-bits. Meaning, you can push around twice the amount of data than before. So basically the bandwidth is doubled. Think of it as a highway. If you had 32 lanes for traffic before, you are definitely going to get more cars down the highway with 64 lanes instead.

This is very, very misleading. Please do not spread statements like this, because it simply promotes more 64-bit ignorance.

Increasing register size from 32-bit to 64-bit has virtually no effect on I/O performance as you are claiming. If programs simply shuffled data around in registers with the goal being to maximize the amount of data transferred, you would be correct. But the vast majority of programs do not work this way!

Think about a simple operation like this (adding two numbers together):

load r1, @r3 # a = value1
load r2, @r4 # b = value2
addu r1, r1, r2 # a = a + b

For these instructions, you have gained *nothing* by moving from 32-bit to 64-bit. This takes exactly the same amount of time to execute on a 32-bit platform as a 64-bit platform for ALL values that can be stored in a 32-bit register. The ONLY case where the 64-bit platform is faster is for values of a and b that cannot be stored in 32-bits (i.e., greater than 4 billion). But that is a very uncommon case.

Actually, the above code will usually execute SLOWER on the 64-bit platform because the code size has increased to handle 64-bit pointers and registers. On AMD64, the average instruction length for 64-bit instructions has increased by roughly 0.7 bytes. This extra overhead accomplishes nothing for most data sets, and causes two serious performance hits: 1) the instruction cache is less effective (its capacity is reduced, and locality has decreased) and 2) page fault probability has increased.

The ONLY factor that offsets this increase in average instruction length for the AMD64 instruction set is that the total instruction count for AMD64 programs is smaller than that for IA32, because the extra 8 general purpose registers available to 64-bit instructions allows compilers to generate fewer register load/stores (more storage for temporaries).

Good read!!!

By the way what are those "uncommon cases".....It appears that graphics intensive apps like complex 3d rendering have a bit of an increase...can you explain how this is....

That is the area I am more likely to need in a 64bit environment...otherwise there is not much of a need for me to change OSes

 

[Wicked2010]

Agreed kylef.

Just trying to dumb it down for others.

Basically multimedia applications will benefit when going to 64 bit.

 

[Jeff7181]

Originally posted by: Duvie

Originally posted by: kylef

Originally posted by: Wicked2010
The registers on the CPU will now be 64-bits. Meaning, you can push around twice the amount of data than before. So basically the bandwidth is doubled. Think of it as a highway. If you had 32 lanes for traffic before, you are definitely going to get more cars down the highway with 64 lanes instead.

This is very, very misleading. Please do not spread statements like this, because it simply promotes more 64-bit ignorance.

Increasing register size from 32-bit to 64-bit has virtually no effect on I/O performance as you are claiming. If programs simply shuffled data around in registers with the goal being to maximize the amount of data transferred, you would be correct. But the vast majority of programs do not work this way!

Think about a simple operation like this (adding two numbers together):

load r1, @r3 # a = value1
load r2, @r4 # b = value2
addu r1, r1, r2 # a = a + b

For these instructions, you have gained *nothing* by moving from 32-bit to 64-bit. This takes exactly the same amount of time to execute on a 32-bit platform as a 64-bit platform for ALL values that can be stored in a 32-bit register. The ONLY case where the 64-bit platform is faster is for values of a and b that cannot be stored in 32-bits (i.e., greater than 4 billion). But that is a very uncommon case.

Actually, the above code will usually execute SLOWER on the 64-bit platform because the code size has increased to handle 64-bit pointers and registers. On AMD64, the average instruction length for 64-bit instructions has increased by roughly 0.7 bytes. This extra overhead accomplishes nothing for most data sets, and causes two serious performance hits: 1) the instruction cache is less effective (its capacity is reduced, and locality has decreased) and 2) page fault probability has increased.

The ONLY factor that offsets this increase in average instruction length for the AMD64 instruction set is that the total instruction count for AMD64 programs is smaller than that for IA32, because the extra 8 general purpose registers available to 64-bit instructions allows compilers to generate fewer register load/stores (more storage for temporaries).

Good read!!!

By the way what are those "uncommon cases".....It appears that graphics intensive apps like complex 3d rendering have a bit of an increase...can you explain how this is....

That is the area I am more likely to need in a 64bit environment...otherwise there is not much of a need for me to change OSes

It's not the size of the GPR's, it's the amount. There's twice as many GPR's available in 64-bit mode. The GPR's being 64-bits wide rather than 32 only allows larger numbers (integers) to be used, which is almost useless at this point.

*Edited for clarity*

**EDIT** I think the floating point units in processors have been 64-bits wide for some time now... haven't they?

 

[Duvie]

Originally posted by: Jeff7181

Originally posted by: Duvie

Originally posted by: kylef

Originally posted by: Wicked2010
The registers on the CPU will now be 64-bits. Meaning, you can push around twice the amount of data than before. So basically the bandwidth is doubled. Think of it as a highway. If you had 32 lanes for traffic before, you are definitely going to get more cars down the highway with 64 lanes instead.

This is very, very misleading. Please do not spread statements like this, because it simply promotes more 64-bit ignorance.

Increasing register size from 32-bit to 64-bit has virtually no effect on I/O performance as you are claiming. If programs simply shuffled data around in registers with the goal being to maximize the amount of data transferred, you would be correct. But the vast majority of programs do not work this way!

Think about a simple operation like this (adding two numbers together):

load r1, @r3 # a = value1
load r2, @r4 # b = value2
addu r1, r1, r2 # a = a + b

For these instructions, you have gained *nothing* by moving from 32-bit to 64-bit. This takes exactly the same amount of time to execute on a 32-bit platform as a 64-bit platform for ALL values that can be stored in a 32-bit register. The ONLY case where the 64-bit platform is faster is for values of a and b that cannot be stored in 32-bits (i.e., greater than 4 billion). But that is a very uncommon case.

Actually, the above code will usually execute SLOWER on the 64-bit platform because the code size has increased to handle 64-bit pointers and registers. On AMD64, the average instruction length for 64-bit instructions has increased by roughly 0.7 bytes. This extra overhead accomplishes nothing for most data sets, and causes two serious performance hits: 1) the instruction cache is less effective (its capacity is reduced, and locality has decreased) and 2) page fault probability has increased.

The ONLY factor that offsets this increase in average instruction length for the AMD64 instruction set is that the total instruction count for AMD64 programs is smaller than that for IA32, because the extra 8 general purpose registers available to 64-bit instructions allows compilers to generate fewer register load/stores (more storage for temporaries).

Good read!!!

By the way what are those "uncommon cases".....It appears that graphics intensive apps like complex 3d rendering have a bit of an increase...can you explain how this is....

That is the area I am more likely to need in a 64bit environment...otherwise there is not much of a need for me to change OSes

It's not the size of the GPR's, it's the amount. There's twice as many GPR's available in 64-bit mode. The GPR's being 64-bits wide rather than 32 only allows larger numbers (integers) to be used, which is almost useless at this point.

*Edited for clarity*

**EDIT** I think the floating point units in processors have been 64-bits wide for some time now... haven't they?

How is it useless if I am seeing programs like I mentioned running a bit faster???

 

[Jeff7181]

Originally posted by: Duvie

Originally posted by: Jeff7181

Originally posted by: Duvie

Originally posted by: kylef

Originally posted by: Wicked2010
The registers on the CPU will now be 64-bits. Meaning, you can push around twice the amount of data than before. So basically the bandwidth is doubled. Think of it as a highway. If you had 32 lanes for traffic before, you are definitely going to get more cars down the highway with 64 lanes instead.

This is very, very misleading. Please do not spread statements like this, because it simply promotes more 64-bit ignorance.

Increasing register size from 32-bit to 64-bit has virtually no effect on I/O performance as you are claiming. If programs simply shuffled data around in registers with the goal being to maximize the amount of data transferred, you would be correct. But the vast majority of programs do not work this way!

Think about a simple operation like this (adding two numbers together):

load r1, @r3 # a = value1
load r2, @r4 # b = value2
addu r1, r1, r2 # a = a + b

For these instructions, you have gained *nothing* by moving from 32-bit to 64-bit. This takes exactly the same amount of time to execute on a 32-bit platform as a 64-bit platform for ALL values that can be stored in a 32-bit register. The ONLY case where the 64-bit platform is faster is for values of a and b that cannot be stored in 32-bits (i.e., greater than 4 billion). But that is a very uncommon case.

Actually, the above code will usually execute SLOWER on the 64-bit platform because the code size has increased to handle 64-bit pointers and registers. On AMD64, the average instruction length for 64-bit instructions has increased by roughly 0.7 bytes. This extra overhead accomplishes nothing for most data sets, and causes two serious performance hits: 1) the instruction cache is less effective (its capacity is reduced, and locality has decreased) and 2) page fault probability has increased.

The ONLY factor that offsets this increase in average instruction length for the AMD64 instruction set is that the total instruction count for AMD64 programs is smaller than that for IA32, because the extra 8 general purpose registers available to 64-bit instructions allows compilers to generate fewer register load/stores (more storage for temporaries).

Good read!!!

By the way what are those "uncommon cases".....It appears that graphics intensive apps like complex 3d rendering have a bit of an increase...can you explain how this is....

That is the area I am more likely to need in a 64bit environment...otherwise there is not much of a need for me to change OSes

It's not the size of the GPR's, it's the amount. There's twice as many GPR's available in 64-bit mode. The GPR's being 64-bits wide rather than 32 only allows larger numbers (integers) to be used, which is almost useless at this point.

*Edited for clarity*

**EDIT** I think the floating point units in processors have been 64-bits wide for some time now... haven't they?

How is it useless if I am seeing programs like I mentioned running a bit faster???

As I said... the performance increase is more likely due to the number of GPR's available, not the size of them.

*EDIT* I'm assuming the things you mentioned won't benefit (yet if at all) from increase dynamic range. If they do, awesome. But the majority of performance increases will be due to the number of GPR's, not the size.

 

[AnarchyAT]

Very good read. Thanks for the info. I know there is a lot of confusion about 64 bit, so everyone read up on it!

 

[kylef]

Originally posted by: Duvie
By the way what are those "uncommon cases".....It appears that graphics intensive apps like complex 3d rendering have a bit of an increase...can you explain how this is....

Well first of all, you always want to compare two identical platforms: one running 32-bit and one running 64-bit. But comparing identical platforms is VERY complicated.

First, you need to compare the binary when running under an identical OS. Simply comparing both binaries on the same Windows x64 machine is NOT a fair comparison!

In fact, many 32-bit binaries running under SysWOW64 will be somewhat slower than the same 32-bit binaries running under native 32-bit Windows for two reasons: 1) The processor must be switched between "64-bit Native Mode" and "Compatibility mode" at each kernel transition and 2) each system call argument and return value must be converted to/from 64-bit. Although these operations are fast and the system calls themselves might even execute faster due to the extra registers, there is an unavoidable nonzero overhead for each system call executed by a 32-bit app running in Windows x64. This overhead can hurt performance depending on how many are made, and in what sequence, etc. (For more information on AMD64 operating modes, see this DevX page.)

Second, you really should compare a 32-bit binary and a 64-bit binary using the same underlying compiler technology. When some applications are recompiled for 64-bit, the new AMD64 compilers exploit the fact that all AMD64 (and x64) processors support Intel's SSE instruction set and registers and therefore avoid using x87 floating point instructions entirely. This isn't really a fair comparison either, because you *could* recompile your 32-bit app to use these registers too; it's just that most app vendors don't do this because they don't want to break compatibility with older processors. So you might see speedups in your 64-bit binary that are NOT attributable to the AMD64 instruction set, but rather are a side effect of the compiler taking advantage of SSE instructions.

So a truly accurate comparison would involve running two separate Windows installations for comparison: one running Windows x64 edition, and the other running Server 2003 Sp1 (which is the codebase that Windows x64 is based on; Windows XP Sp2 has a very different codebase). Then the binaries should be compiled using as similar a compiler as you can get, with "extra instruction set" optimizations disabled (things like SSE). THAT would be a good 64-bit vs. 32-bit platform comparison.

But I seriously doubt anyone actually takes the time to compare their apps in this manner.

Now that I've cleared the air about platform parity, I'd like to point out that for any given binary, predicting performance without analyzing instructions is very difficult to do. So while I can suggest possible reasons for why you are seeing some 64-bit binaries outperform their 32-bit counterparts, we won't really know what's going on until someone actually examines the instructions that are being executed.

If you perform a "fair" platform comparison as I suggest above and you still detect a noticeable speedup for the 64-bit binary, my guess is that the app's code happens to benefit more from the 8 new general purpose registers in AMD64 than it is hindered by the increase in instruction length.

 

[VirtualLarry]

Excellent posts kylef. I made some similar ones a while ago on a different messageboard, about how 64-bit code (running with 64-bit opcode / operand sizes) might well actually be slightly slower than the same code compiled and running in 32-bit mode (due to cache effects). They didn't like that suggestion, however. But I had also mostly neglected to consider the win that the extra 8 GPRs would likely bring, which would definately greatly reduce the memory pressure, especially the stack, because of current compiliers having to do lots of extra load/store operations and using temporaries in memory due to the current lack of registers in x86. So considering both together, I think one might somewhat make up for the other, and when using the extra 8 GPRs, but still using more cache-efficient 32-bit operand sizes, you would get the best of both worlds. I am slightly disturbed at how more recent AMD64 chips are being released with smaller L2 cache sizes, because once actual 64-bit code starts to arrive, users are going to see the real performance benefit from those larger cache sizes. Although simply running current 32-bit code, there isn't that much of a win going above a 512KB L2 size right now it seems, for most tasks, which is probably why AMD has been trimming them, both to save costs and increase production yields. I'm going to hold off until dual-core, by then... wow, those things will likely make killer compilier workstations. Maybe throw in a 15K SCSI scratch/compile disk too. Nah, now I'm just dreaming.

 

[bersl2]

In addition to 8 more GPRs, there are also 8 more SSE registers too.

 

[kylef]

Originally posted by: bersl2
In addition to 8 more GPRs, there are also 8 more SSE registers too.

Correct, and those should help compilers generate faster floating-point code. But again, those should only be factored in when comparing SSE-enabled 32-bit apps to SSE-enabled 64-bit apps.

Originally posted by: VirtualLarry
So considering both together, I think one might somewhat make up for the other, and when using the extra 8 GPRs, but still using more cache-efficient 32-bit operand sizes, you would get the best of both worlds.

I agree, but unfortunately the extra registers are only available when running 64-bit code because addressing new registers requires new opcodes (i.e., the extra byte that prefaces each 64-bit instruction). So you either get 16 registers and fatter 64-bit code, or 8 registers and leaner 32-bit code. We can't have the best of both worlds in this case...

I am slightly disturbed at how more recent AMD64 chips are being released with smaller L2 cache sizes, because once actual 64-bit code starts to arrive, users are going to see the real performance benefit from those larger cache sizes.

Yep, I would agree with that. I think they should consider increasing the L1 instruction cache size. (From my recollection of "cache architecture 101" in grad school, extra unified L2 cache doesn't really help instruction execution that much). But I'm sure that their cache designers are experimenting with all sorts of configurations, and anything we can come up with has probably already been tried. If they need to squeeze more performance out of their cache architecture, I'm sure they can. (AMD is still the only company mass producing an orthogonal L2 cache on their CPUs from what I understand: Intel still uses the traditional hierarchical type I believe. And NUMA is a pretty radical change over SMP. So AMD has a history of trying some unusal architectures in an attempt to improve performance. Granted, they aren't the first to come up with these ideas, but they may be the first to re-examine them in quite some time.)