OS: To go 64 bit or not to go?

Hi everyone,

i'm building a new PC and i was wondering if i should choose a 64-bit operating system or not. What are the risks and benefits ? Because i must say, right now, i don't see much benefits from it (except using the full 4 Gb of memory i'll have) since I don't see much 64bit applications out there (but I might be wrong - or blind). And what about drivers ?

The operating system I am looking at is Windows Vista Business 64bit (which i can get for free and completely legal; installing Windows XP is not really an option since i don't have any license left). I'll also install Ubuntu 8.04 64bit. Or i could install the 32-bit version of Vista with the 32-bit version of Ubuntu. I have numerous choice. What do you think ? Not installing Vista is not option, nor is not installing Linux.

It seems a bit odd to me to see that there is so few 64bit software even if it's been a couple of years that 64bit processor are on the market. I was too young to see the 16bit/32bit transition, but I'm curious, was it long ?

For people who might be interested, here's the highlight of my new system:

• Core 2 Duo E8400
• GA-EP35-DS3R motherboard
• 2x2GB of PC2-6400
• 8800GT

Thanks

In Linux I would say go for 64-bit - there's little or no drawback to it, particularly if it's a "starting from scratch" system.

In Windows, there's probably little benefit of 64-bit.

And note that if you have 4GB in the machine, a 32-bit OS can still use all (and more), just not in ONE PROCESS (a process is normally limited to 2GB, which, if you want, can be extended to 3GB, but only processes that exhibit the "LARGE_MEMORY_SUPPORTED"[or similar] flag in the .EXE header will be able to use this).

--
Mats

You should absolutely not go for a 64-bit Vista. Its driver support is abysmal.

The 16-bit -> 32-bit transition was indeed long and gradual. 32-bit support was introduced with the 80386, but for compatibility reasons, DOS was never updated to actually use it. It remained 16-bit right until the very end.
There were 32-bit extenders, like DOS4GW used in many games or Win32s that allowed writing 32-bit applications for Windows 3.x, but in general, these applied to a single application only.
Windows NT was developed and ran the system in 32-bit mode, but it was never very widespread, at least on home computers. Probably a bit more on workstations.
Windows 95, finally, ran mostly in 32-bit mode, although parts of its core were still based on DOS and thus 16-bit. Windows ME was the last of the Win9x family.
Windows XP, the successor of Windows 2000 (and thus Windows NT) was the first operating system to almost completely displace Windows 98 and ME from home computers.
The 80386 was released in 1986. Windows XP was released in 2002. That's 16 years of transition.

The 64-bit transition will take even longer, though, I think. The 32-bit transition brought immense side-effect advantages: protected memory, virtual memory, preemptive multitasking, linear addressing, native large-integer calculations, and probably more.
The 64-bit transition brings no such advantages. All it does is extend the address space even more, and few applications actually need that much memory. As such, there is less incentive to actually make the transition.
We'll see. The clock started ticking with the release of the Intel Core 2 in 2006. I think it's safe to say that every CPU henceforth will support 64-bit mode.

Quote:

---

Originally Posted by CornedBee

We'll see. The clock started ticking with the release of the Intel Core 2 in 2006. I think it's safe to say that every CPU henceforth will support 64-bit mode.

---

AMD had a 64-bit CPU on the market a long time before that..

Quote:

---

And note that if you have 4GB in the machine, a 32-bit OS can still use all (and more), just not in ONE PROCESS

---

Really? I always thought that a 32-bit OS could never address more than 4GB memory at one time?

Quote:

---

Originally Posted by Neo1

AMD had a 64-bit CPU on the market a long time before that..

---

Yes, and Intel had P4 processors capable of 64-bit for a while before the Core2's too - but only certain models.

Quote:

---

Really? I always thought that a 32-bit OS could never address more than 4GB memory at one time?

---

Yes and no. You can't have access to more than 4GB at any given moment in time. The PAE mode of 32-bit x86 processors allows up to 64GB of RAM, but only 4GB can be used at any given time - in portions of 4KB. However, PAE is only in use when you have Server type OS's.

And the process itself (in windows standard configuration) can not use more than 2GB without trickery stuff, because Windows itself "uses" the 31st bit of the address to delineate kernel and user mode code. User-mode addresses are always less than 0x8000000, and kernel addresses always above this. With the /3GB on the command line of the kernel, this limit changes to 0xC0000000 - so one GB is used for kernel space, and 3GB for user-mode code. This doesn't work well with high-end graphics cards and such, because there isn't enough memory to map a 256MB+ graphics card's frame buffer in kernel-space. These are VIRTUAL addresses, and any of that virtual memory can be mapped anywhere in the 4GB (or 64GB) physical memory.

--
Mats

the 2/3/4 gb per process limit only effects 32 bit applications running under 64 bit OS's, if you have a 64 bit application it has full access to the whole 16 billion gigabytes. For an application to be 64 bit though it has to be specifically compiled as an x64 application. Few applications need access to the additional ram and running in 64 bit mode does incure a small processing overhead as some of the opcodes are a byte or two larger, on the order of a few percent. So most developers just write for 32 bit. Currently the only applications I am aware of that need 64 bit are media editing software, engineering modelers, database servers and some HPC applications. I don't know of any game clients that need 64 bit, although some of the server engines might.

Actuall, the overhead of 1 byte more for certain opcodes [1] is, largely, hidden by the changes in registers and ABI - the calling convention allows for 5-6 registers as parameters, instead of 2-3 in 32-bit. Since loading a register is almost always simpler (in code-size) than loading the data onto the stack and cleaning up the stack afterwards.

Clever compilers will attempt to get things into the right register early on, so no overhead is needed for getting the data in the right place except where the compiler runs out of registers.

The bigger issue, from a performance perspective, is that 64-bit pointers take up twice as much memory, and thus twice as much space in the cache. That slows things down when you have lots of pointers (linked lists and arrays of pointers for example).

And as pointed out, most applications don't actually need 2 or 3 GB of memory anyways, so the push for using 64-bit in applications is not heavy.

The limit for a single 32-bit app in 64-bit is just under 4GB, because alost all the kernel-space stuff is now 64-bit, so it can be "hidden out of the way" from the 32-bit space.

--
Mats

I believe it is 256MB shy of 4GB, the 256MB that is reserved for NULL pointer detection IIRC.

I've had absolutely no issues with Vista Business 64-bit. No driver issues to my knowledge at least.

I was having some fun with it when I initially set up the machine with rendering maya animations to see performance differences. Huge from core duo 2.14 -> core 2 quad (8+ hour render time to under 40 minutes) I'd assume some of that was from the 64-bit support not just 2 extra cores. Since then I haven't really done much more than DirectX 10 programming and playing with various OS's in virtual machines. But I haven't had any issues with the system. So far I have yet to blue screen the computer (knock on wood) and it's a few months old.

Quote:

---

Originally Posted by Neo1

Really? I always thought that a 32-bit OS could never address more than 4GB memory at one time?

---

It's not a question of whether the OS can address it, but if the application can. It's perfectly possible to set up page tables for an application which let it access memory that isn't (currently) mapped in the kernel's own page table. The inherent limitation is the 32-bit size of a pointer. The CPU itself has ways of accessing more than 4 gigabytes of total memory, it just can't be done without altering the page tables. In essence you only ever see a 4 gigabyte "window", but this window can be manipulated.

Back in 16 bit DOS, applications were certainly able to access more than 64 kilobytes of memory, they just had to use tricks. Same goes these days, the numbers are just bigger.

Quote:

---

Originally Posted by Neo1

AMD had a 64-bit CPU on the market a long time before that.

---

Yes, but I started the count where there were no more non-64-bit-capable CPUs to come, because it's hard for the industry to support something that only a part of even the new products actually support.

I agree on the whole "don't use vista" business. Vista is slow, unstable and I would never trust an OS which cannot even copy files correctly.
Vista is bloat, bloat, bloat and no more. It has some nice eye candy and (some) nice features, but not enough to make it a viable option over XP/Linux.
Go for Linux instead.

Quote:

---

Originally Posted by abachler

I believe it is 256MB shy of 4GB, the 256MB that is reserved for NULL pointer detection IIRC.

---

256MB for NULL pointer detection? What amazing algorithm is this?

One that also detects null pointer access of this kind:

Code:

---

void foo(int *ar, int sz)
{
  printf("%d\n", ar[100]);
}

int main()
{
  foo(0, 150);
}

---

How is that a null pointer access? And how does that take 256MB?

Or maybe I'm not getting the joke. :p

Well, it's not like the OS eats 256 MB. The process just can't use those extra 256 MB.
But I guess you knew that, huh?

But, the point is, I think, that it helps catch more "invalid pointers" errors.

Quote:

---

Originally Posted by robwhit

How is that a null pointer access? And how does that take 256MB?

Or maybe I'm not getting the joke. :p

---

first parameter of the function is null pointer
a[100]
results in 0+100*sizeof(int) = 0x00000190 or 0x00000320 address access

oh I see... null pointer base, not null pointer.

It may be that some memory around address zero is used, but the OS also needs a small thunking layer to implement the 32-to-64-bit conversion for system calls, which also eats a bit of memory.

Conventional .exe files start around 0x400000, which is "only" 4MB into memory.

By experimenting using VirtualAlloc on Win2K, I can allocate memory at 0x30000 (but no lower), so I expect that 192KB is the "minimum" that the OS refuses to give to you to preven null-pointers. Note that these 192KB doesn't really occupy any memory - it's just "not present" in the page-table entry.

--
Mats

Well, thanks for these interesting replies. I'll install Vista 32bit instead of the 64bit version. I'll be playing on the safe side and like some mention, there's not much to win (especially for my needs), and more to lose.

As for the Linux OS, I migth still go 64bit, but I'm no more entirely convinced. Maybe i should look a bit further for more informations. Or i might install 2 different version of Linux since I have plenty of space on this new drive, even if it might be a bit (a lot?) useless.

I also want to have one "data" partition. This may looks odd, but which file system do you advise me to choose for this, since i want my data to be accessible on both Windows and Linux ? NTFS ? Anyone has suggestions ?

I don't believe NTFS in Linux is robust, even if the latest versions allow writing as well as reading. I'd go for old-fashioned FAT for a shared partition.

As to 32 or 64-bit Linux, I have been using both for a long time, and there are very few things that are "worse" in 64-bit, but a lot of things that are better (faster load of .so's for exmaple, because there is nearly no relocation need, since PC-relative addressing is part of x86-64, which also means that the code is more efficient in PIC (position independent code), whereas the 32-bit version needs to use a register (I believe EBX) to hold a base-pointer to access things relative within the .so).

32-bit apps will work just fine on 64-bit OS (same applies in Windows), so there's no direct need to worry about applications being compatible or not.

But please make your own decision, as you are the one living with the machine.

--
Mats

It's a null pointer access because memory is accessed through a null pointer, even if it is offset first.

And 256MB is what the designers decided was a good compromise between catching accesses even into very large imagined arrays and not taking up too much of the virtual address space.

There is no joke.

Edit: Totally missed the second page.

Linux NTFS is still not really done. The in-kernel NTFS driver still refuses to write unless you specifically enable that support, and even then the writing is very limited. The out-of-kernel NTFS driver provides more writing capabilities, but there are still limits.
Then there's NTFS-3g, an entirely separate project, only available as a FUSE module. They support all write operations, but not for encrypted or compressed systems. I don't know about their stability, but I believe it's very good. Their main "problem" with acceptance is one of politics, I think.

Quote:

---

Originally Posted by CornedBee

It's a null pointer access because memory is accessed through a null pointer, even if it is offset first.

And 256MB is what the designers decided was a good compromise between catching accesses even into very large imagined arrays and not taking up too much of the virtual address space.

There is no joke.

---

Although it ISN'T 256MB at the beginning of a normal Windows executable, as there is only 4MB before the code starts. And as I wrote in the last post, if you really want to squeeze every single bit (pun intended) out of the virtual memory range, you can VirtualAlloc() down to 192KB from zero.

In a 64-bit system, I expect it to be bigger range around zero that is "unused for the purpose of catching NULL accesses".

--
Mats

Quote:

---

Originally Posted by foxman

I'll install Vista 32bit instead of the 64bit version. [...] As for the Linux OS, I migth still go 64bit, but I'm no more entirely convinced.

---

You shouldn't be too worried with this issue, particularly on Linux. If Vista 64-Bit versions are indeed lacking on drivers, then you should go 32 bit, definitely. However, it should be expected that only new hardware suffers from this and within a few more months most, if not all, major hardware vendors have made their drivers available. Meanwhile, as far as I know, a 64-bit operating system can run on 32-bit drivers.

As for Linux (and Macintosh, btw) full 64-bit support is provided. It probably will be a mistake NOT to go 64-bit as this is the new direction the operating system is taking. Sure there will be 32 bit versions for a long time to come. But since a) 64-bit Linux can run any 32-bit application and b) 64-bit applications run faster than 32-bit ones (at least on Intel processors), there is very little doubt on my mind that 64-bit Linux is what most everybody will be investing their time on.

Quote:

---

Originally Posted by Mario F.

b) 64-bit applications run faster than 32-bit ones (at least on Intel processors), there is very little doubt on my mind that 64-bit Linux is what most everybody will be investing their time on.

---

They certainly almost always do on AMD CPU's too - and I'm sure it's possible to find ones that run slower in Intel CPU's too - typically the ones using long linked lists that have small content (e.g. a linked list of a record of 6-7 integers/pointers).

--
Mats