64 bit Vs 32 bit

[quaker13]

For game play in general is there a whole lot of difference between 32 bit and 64 bit systems...windows 7.

Ive been told that 64 bit is slower than 32 bit even though you can use 8 gb of ram compared to the 3gb or so that 32 bit can recognize. \

Read all kinds of stuff but cant be sure just from reading reviews

[Foo]

With Windows 7, only install 32-bit if your CPU cannot handle 64-bit. E.g. if you're running a first-gen Atom netbook.

In absolutely all other situations, install 64-bit.

[quaker13]

CPU can handle 64 bit. Why do you say to definately use 64 bit

[obsidian]

Whoever told you that 64-bit is slower than 32-bit doesn't know his ass from his mouth. If your processor is designed to do 64-bit that is what your processor prefers to use. It will certainly not be slower for games or anything else, in many cases it will actually be faster.

[quaker13]

thanks

[Foo]

CPU can handle 64 bit. Why do you say to definately use 64 bit

Because it's just a business-as-usual migration onto a higher-bit architecture. We've been here before with 8-bit, 16-bit, 32-bit and now 64-bit. In 10 years time we'll be phasing across to 128-bit. The furore around it seems comical when you've seen it all before.

Unfortunately it always requires a wholesale overhaul of hardware and software, so the change never happens overnight, and there's always the 'omg *insert new thing here* is slower! Don't upgrade' nonsense flying around.

There was a 64-bit version of XP available, but it was made available late into the product cycle, and required new drivers which few vendors bothered to issue and support. By contrast, 64-bit is supported pretty much as the default now that windows 7 is around, so it makes sense to go with 64-bit and there are few if any reasons not to do so.

[^misantropia^]

In 10 years time we'll be phasing across to 128-bit.

Fun fact: SSE is 128-bits (but not for memory addressing, of course).

[^misantropia^]

And another, completely unrelated but fun fact: I wrote some code in college for the DEC PDP-15, an 18-bits machine. Wave of the future, man!

[Scarface]

And another, completely unrelated but fun fact: I wrote some code in college for the DEC PDP-15, an 18-bits machine. Wave of the future, man!

liar

back on topic: as stated before, if it's designed for 64bit, install 64bit, duhhhh

[^misantropia^]

It's true! Bytes had 9 bits on that beast.

[Eraser]

Isn't it true that if you have less than 4GB of memory in your PC, 64 bits doesn't really offer any real advantages over 32 bits? Also, all your memory pointers are twice the size of a 32 bit system so the memory footprint of 64 bit apps is larger than that of 32 bit apps.

[AmIdYfReAk]

its true that the memory usage is basically doubled when running 64-bit, but... What computer DOESN'T have 4 gigs now'n'days?

[bitWISE]

* Some operating systems reserve portions of process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and other user mode OS components are mapped into each process's address space, leaving only 2 to 3 GB (depending on the settings) address space available. This limit is currently much higher on 64-bit operating systems and does not realistically restrict memory usage.

* Memory-mapped files are becoming more difficult to implement in 32-bit architectures. A 4 GB file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures; only a region of the file can be mapped into the address space, and to access such a file by memory mapping, those regions will have to be mapped into and out of the address space as needed. This is a problem, as memory mapping remains one of the most efficient disk-to-memory methods, when properly implemented by the OS.

* Some programs such as data encryption software can benefit greatly from 64-bit registers (if the software is 64-bit compiled) and effectively execute 3 to 5 times faster on 64-bit than on 32-bit.

[Scarface]

its true that the memory usage is basically doubled when running 64-bit, but... What computer DOESN'T have 4 gigs now'n'days?

mine

[quaker13]

May stick with windows XP. I am better off staying with 32 bit with XP. Playing Everquest

[U4EA]

Playing Everquest

"There's your problem."

[Silicone_Milk]

Hey, there's nothing wrong with EverQuest. At least there wasn't back in 1999. The world has moved on.

So has technology. Move along.

[Foo]

Isn't it true that if you have less than 4GB of memory in your PC, 64 bits doesn't really offer any real advantages over 32 bits?

No. Here's why:

1: Now that 64-bits is becoming the mainstream choice (this wasn't the case in XP by a long way, and arguably not in Vista, either), more things will start popping up as 64-bit only. Conversely, you can run all the 32-bit stuff you always could on a 64-bit OS. So why would you artificially limit your flexibility?

2: Re-installing your whole OS if you add a few extra Gbs of RAM in the future? Why would you set yourself up for that extra hassle?

3: CPUs with 64-bit instruction sets are running 32-bit instructions either under emulation, or on daughter chips, or 32-bit instruction sets which are just included for compatibility. This means that if you're running your whole OS and software stack as 32-bit on an x64 chip, you're not taking advantage of much of its extra abilities. In fact, you're probably missing out on a whole fuck-ton of them because nobody's gonna bother bringing those features back down for the x32 instruction set, just for the sake of it.

Also, taken from Squickipedia:

A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GB of main memory. This is not entirely true:

* Some operating systems and certain hardware configurations limit the physical memory space to 3 GB on IA-32 systems, due to much of the 3–4 GB region being reserved for hardware addressing; see 3 GB barrier. This is not present in 64-bit architectures, which can use 4 GB of memory and more. However, IA-32 processors from the Pentium II onwards allow for a 36-bit physical memory address space, using Physical Address Extension (PAE), which gives a 64 GB physical address range, of which up to 62 GB may be used by main memory; operating systems that support PAE may not be limited to 4GB of physical memory, even on IA-32 processors.

* Some operating systems reserve portions of process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and other user mode OS components are mapped into each process's address space, leaving only 2 to 3 GB (depending on the settings) address space available. This limit is currently much higher on 64-bit operating systems and does not realistically restrict memory usage.

* Memory-mapped files are becoming more difficult to implement in 32-bit architectures. A 4 GB file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures; only a region of the file can be mapped into the address space, and to access such a file by memory mapping, those regions will have to be mapped into and out of the address space as needed. This is a problem, as memory mapping remains one of the most efficient disk-to-memory methods, when properly implemented by the OS.

* Some programs such as data encryption software can benefit greatly from 64-bit registers (if the software is 64-bit compiled) and effectively execute 3 to 5 times faster on 64-bit than on 32-bit.[citation needed]

The main disadvantage of 64-bit architectures is that relative to 32-bit architectures, the same data occupies more space in memory (due to swollen pointers and possibly other types and alignment padding). This increases the memory requirements of a given process and can have implications for efficient processor cache utilization. Maintaining a partial 32-bit model is one way to handle this and is in general reasonably effective. For example, the z/OS operating system takes this approach currently, requiring program code to reside in 31-bit address spaces (the high order bit is not used in address calculation on the underlying hardware platform) while data objects can optionally reside in 64-bit regions.

Currently, most proprietary x86 software is compiled into 32-bit code, with less being also compiled into 64-bit code (although the trend is rapidly equalizing[citation needed]), so much does not take advantage of the larger 64-bit address space or wider 64-bit registers and data paths on x86 processors, or the additional registers in 64-bit mode. However, users of most RISC platforms, and users of free or open source operating systems (where the source code is available for recompiling with a 64-bit compiler) have been able to use exclusive 64-bit computing environments for years due to the likelihood of the existence of someone willing to compile the code thusly. Not all such applications require a large address space nor manipulate 64-bit data items, so they wouldn't benefit from the larger address space or wider registers and data paths. The main advantage to 64-bit versions of such applications is the ability to access more registers in the x86-64 architecture.

Source: http://en.wikipedia.org/wiki/64-bit#32-_vs_64-bit

[bitWISE]

looks familiar foo

[Foo]

Wrote it yourself eh?