32-bit vs 64-bit

[Red Squirrel]

I just want to ensure I understand things properly, what are the main differences between coding 32-bit and 64-bit? Also how do I even compile a 64-bit app, is it automatic if I'm on a 64-bit platform? I'm talking mostly about C++ using gcc, but knowing in general would be nice too.

With that covered, from my understanding, a 32-bit app is limited to long ints of 0xFFFFFFFF values, while 64-bit is 0xFFFFFFFFFFFFFFFF so it enables to have much larger numbers. It also enables to have more memory used as memory addresses are 32-bit ints while in 64-bit well, they're 64-bit.

Am I correct on this?

 

[Ken g6]

Let me take this backwards...

It also enables to have more memory used as memory addresses are 32-bit ints while in 64-bit well, they're 64-bit.

Am I correct on this?

Correct, on this.

from my understanding, a 32-bit app is limited to long ints of 0xFFFFFFFF values, while 64-bit is 0xFFFFFFFFFFFFFFFF so it enables to have much larger numbers.

Not exactly. You can work with 64-bit numbers in 32-bit, with the "long long" type. It just takes more instructions and is slower in 32-bit. Technically, you can work with near-unlimited-precision numbers in 32-bit. I guess you could work with bigger numbers in 64-bit, but only if you have more than 4GB of memory for each number. 😱

I just want to ensure I understand things properly, what are the main differences between coding 32-bit and 64-bit?

1. More memory address space. (Particularly, per-program.) With this, all pointers become 64 bits long.
2. Faster processing of large numbers.
3. In Linux, a "long" becomes 64 bits. In Windows, it's still 32 bits. 🙄

Also how do I even compile a 64-bit app, is it automatic if I'm on a 64-bit platform? I'm talking mostly about C++ using gcc, but knowing in general would be nice too.

With gcc, "-m64", which is the default. To compile for 32 bits in a 64-bit Linux, use "-m32". I've not yet compiled anything 64-bit with any other compiler.

 

[degibson]

... a 32-bit app is limited to long ints of 0xFFFFFFFF values, while 64-bit is 0xFFFFFFFFFFFFFFFF...

A 32-bit unsigned maximum value is 0xFFFFFFFF. A 32-bit signed int's max is 0x7FFFFFFF. Similarly for 64-bit, a 64-bit unsigned has a maximum value of 0xFFFFFFFFFFFFFFFF; a 64-bit signed has a maximum value of 0x7FFFFFFFFFFFFFFF.

Were you to use 0xFFFFFFFF instead of 0x7FFFFFFF, you'd end up with -1.

Anyway, eschew all of the above and use INT_MAX, LONG_MAX, etc., instead from limits.h.

 

[Red Squirrel]

Thanks for the info, now I have a better idea what to expect. I will probably start taking advantage of 64-bit when coding.

 

[degibson]

Thanks for the info, now I have a better idea what to expect. I will probably start taking advantage of 64-bit when coding.

Actually, I had an interesting chat with a colleague about this the other day. One of his important apps runs substantially slower in 64-bit mode because all of their pointers become 8 bytes, and the L1-D is overflowed as a result. So bear in mind it can have negative side effects, too (and yes, there are still come compatibility problems *gasp*)

 

[Red Squirrel]

Actually, I had an interesting chat with a colleague about this the other day. One of his important apps runs substantially slower in 64-bit mode because all of their pointers become 8 bytes, and the L1-D is overflowed as a result. So bear in mind it can have negative side effects, too (and yes, there are still come compatibility problems *gasp*)

Yeah I was thinking that too, so there is some overhead to be considered given pointers being bigger.

 

[Markbnj]

Actually, I had an interesting chat with a colleague about this the other day. One of his important apps runs substantially slower in 64-bit mode because all of their pointers become 8 bytes, and the L1-D is overflowed as a result. So bear in mind it can have negative side effects, too (and yes, there are still come compatibility problems *gasp*)

I don't see the point, personally, unless you have to work with very large numbers or allocate a ton of memory (more than 4GB, which is what you get with a 32-bit process under 64-bit windows with the right flags set). I have been running Windows 64-bit here for some time, and my impression is that overall it is less stable than the 32-bit versions. This is probably due to issues with drivers for the most part. I'm not sure what the experience has been for users of 64-bit nix versions, since I run 32-bit Debian here.

 

[Crusty]

I don't see the point, personally, unless you have to work with very large numbers or allocate a ton of memory (more than 4GB, which is what you get with a 32-bit process under 64-bit windows with the right flags set). I have been running Windows 64-bit here for some time, and my impression is that overall it is less stable than the 32-bit versions. This is probably due to issues with drivers for the most part. I'm not sure what the experience has been for users of 64-bit nix versions, since I run 32-bit Debian here.

I've been running 64-bit Linux since the first Athlon 64's came out and aside from the lag in getting most of the flash, multimedia codecs and proprietary drivers working it was definitely usable. The majority of OSS software was already ready to be compiled for 64-bit and even then you can always run a 32-bit userland on top of a 64-bit kernel.

What has been happening with Windows that makes you think it's less stable? I've had very little trouble with 64-bit windows since I started using it(right after Vista SP1 was released). I missed out on all the early issues with Vista and didn't even bother with XP-64 due to the driver issues.

 

[Rangoric]

I've been running 64-bit Linux since the first Athlon 64's came out and aside from the lag in getting most of the flash, multimedia codecs and proprietary drivers working it was definitely usable. The majority of OSS software was already ready to be compiled for 64-bit and even then you can always run a 32-bit userland on top of a 64-bit kernel.

What has been happening with Windows that makes you think it's less stable? I've had very little trouble with 64-bit windows since I started using it(right after Vista SP1 was released). I missed out on all the early issues with Vista and didn't even bother with XP-64 due to the driver issues.

Early Vista and XP-64 had huge driver issues. But after a few months Vista was "ok" driver wise. Zune didn't install out of the box on any x64 for the longest time either (which pissed me the hell off).

However yeah I don't see the stability issue now for x64 platforms. I think the only 32/64 bit issue I have ATM is that the Windows Virtual PC will only host 32 bit OSes.

 

[Markbnj]

Well I should probably back off a bit, since I am running Windows 7 Enterprise 64-bit. There may be lingering problems with that which aren't really related to it being a 64-bit system. In any case, I am running a pretty much vanilla Q8500/P43 system with 8 gigs and a GTS250. I see fairly regular bsods related to the graphics drivers, and have seen one or two bsods that I couldn't pin on any one driver, including a couple out of ntfs.sys. Overall it's a solid system, and at its code is probably as solid or more so than the 32-bit version, but I think the 3rd-party world that orbits it is where the problems creep in.

 

[Crusty]

Well I should probably back off a bit, since I am running Windows 7 Enterprise 64-bit. There may be lingering problems with that which aren't really related to it being a 64-bit system. In any case, I am running a pretty much vanilla Q8500/P43 system with 8 gigs and a GTS250. I see fairly regular bsods related to the graphics drivers, and have seen one or two bsods that I couldn't pin on any one driver, including a couple out of ntfs.sys. Overall it's a solid system, and at its code is probably as solid or more so than the 32-bit version, but I think the 3rd-party world that orbits it is where the problems creep in.

That is really surprising IMO. You're using relevant hardware that should have excellent driver support. I have yet to see a BSOD from my P35 w/ 8GB of ram and an 8800GT since I built it and put Vista SP1 on it. Perhaps you have a bad RAM module or maybe you just found a combo of parts/brands that don't play well together 🙁

 

[exdeath]

The biggest immediate issue with 32 bit vs 64 bit isn't really word size but the virtual address space being crowded. Normally it's a 2/2 GB split, and system libraries and such being mapped into the apps half, etc. Operating system can't really give much up because devices like video cards are pushing 1 GB+ addressable memory, file caches for increased file sizes for high res textures and HD video files, etc.

The biggest reason to go from 32 bit to 64 bit is the same reason XMS > EMS; large flat address space without crowding or the need to window/map.

 

[Red Squirrel]

Actually I noticed in the windows world the transition to 64-bit has been rather slow. XP 64 is aparantly very buggy, vista is a bit better (besides it's regular issues but those arn't due to 64-bit). Not sure about 7.

 

[Rangoric]

Actually I noticed in the windows world the transition to 64-bit has been rather slow. XP 64 is aparantly very buggy, vista is a bit better (besides it's regular issues but those arn't due to 64-bit). Not sure about 7.

For XP 64 it was software support and drivers. It was also not pushed all that much. Vista was the first Windows to really push 64 for the desktop while 7 you likely should just opt for the 64bit one if getting a new comp.

 

[degibson]

I don't see the point, personally, unless you have to work with very large numbers or allocate a ton of memory (more than 4GB, which is what you get with a 32-bit process under 64-bit windows with the right flags set). I have been running Windows 64-bit here for some time, and my impression is that overall it is less stable than the 32-bit versions. This is probably due to issues with drivers for the most part. I'm not sure what the experience has been for users of 64-bit nix versions, since I run 32-bit Debian here.

This was my Win XP/64 experience as well. I bought a new machine with it factory installed... and grew irritated with its driver issues inside of ten minutes and wiped it.

I would not be surprised if more modern windows's 64's were more stable. As usual, its not so much the Windows code, but everything else that runs with PRIV=1.