I use Debian Lenny 64-bit. I have 4GB RAM. My biggest challenge is a lot of packages are only available in 32 bit. Some work with 32 bit libraries installed, but not all of them. Some times you have to do more research and find alternative solutions to doing some thing as every thing you normally do only work on 32 bit systems.

The OEM price for 64-bit versus 32-bit versions of Windows Vista and Windows 7 is exactly the same. Retail versions ship with both 32-bit and 64-bit on the same disc. The majority of expense for moving to 64-bit is for upgrading system applications such as anti-virus software and DVD recording software.

The registry issues and directory naming issues are because of moving between Windows XP and newer versions of Windows not because of going from a 32-bit OS to a 64-bit OS. As a practical matter, 64-bit Windows XP was never supported by third party developers enough to make it a good choice. I consider 64-bit XP to be more of a Microsoft experiment than a real product. It was the Vista driver model that officially added and required 64-bit support.

Windows does many internal time and date calculations using 64-bit numbers, though you made a good point about Linux using 32-bit values for time and date.

Some other Windows 64-bit advantages have nothing to do with 64-bit but happen to have been design decisions by Microsoft. Windows 64-bit uses an exception handler table rather than stack based exception handlers. That avoids the possibility of stack overwriting exploits that change exception handler information. Microsoft also enforces driver signing more stringently in 64-bit versions. The most obvious advantage to 64-bit Windows is because of a Microsoft decision to not do something. Microsoft decided to not support PAE extended addressing in 32-bit versions of Windows Vista and Windows 7.

In 64-bit mode, your processor uses something called EPIC, whose aim is to make things faster - a lot faster.
The fact that it only speeds up some software in practice is due to the way it works, and I'm sorry to hear about that (above), because I guess it took them a lot of hard work to put in the chip.

As far as I know EPIC is only in Intel Xenon and Intel Itanium processors.

Do you mean Debian packages? AFAIK everything in the Debian distro is available for both 32 and 64 bits. No big deal because all packages can be recompiled from source by the maintainers.

Adobe Flash is natively 64-bits for Linux.

One non-64-bits package which springs to mind is Skype. But the last time I installed it on a machine with th 32-bits compatibility libs installed, it installed (dpkg --force-architecture) without any problem and worked right away.

I found that my laptop runs just slightly faster and cooler with Debian AMD64 installed, but maybe that is just psychological.

jlinkels

How does the system address the memory then since its physically impossible?

IF you use PAE you can see/use more ram, but there are a number of issues with PAE. It is still limited to 3.something on a per process(not right word) basis. There are also applications that do not like PAE.

There's some good info/links here http://kbase.redhat.com/faq/docs/DOC-6571

Is this true? So what do AMD chips have as their equivalent?

EPIC (or IA-64) is the instruction set used by Intel Itanium processor family. AMD (or anyone else for that matter) does not have anything equivalent. AMD and other Intel 64-bit processors (64-bit Pentium, Core Family processors) use a extended x86 instruction set.

"Per process" is what I would call it as well. It is 3GB user mode virtual address per process.

The "3.something" usually refers to the amount of physical ram that can be used in the first 4GB of physical address space. That is totally different from the amount of user mode virtual address space.

There was also a HugeMem option in RHEL 4 and possibly other Linux distributions/releases that did increase user mode virtual to 3.something.

That had significant overhead and compatibility issues.

PAE support in most distributions/versions does not imply HugeMem.

For most uses of Linux, the 3GB virtual limit per process is far less important than the non PAE limit of 3.something GB physical for the whole system.

If you have 4GB to 8GB physical ram on a system, you probably want to run multiple processes each taking some physical ram, plus some for file caching and some more for the kernel itself. So 3GB virtual (which typically is much less than 3GB physical) may well be enough for any one process even if the whole system is heavily utilizing 8GB physical.

Assuming you mean just PAE, not HugeMem, do you have any examples?

I can imagine some system utility program that digs too specifically into the kernel might fail due to any change in the details of memory management by the kernel. But otherwise, PAE ought to be totally transparent to applications. They work entirely with virtual memory, not physically memory and they have no reason to care which physical memory backs their virtual memory at any specific moment.

HugeMem was a more significant change in the relationship between kernel mode and user mode, so there are many ways that it could be incompatible with specific applications (though it is more likely to be incompatible with device drivers).

Even PAE alone could easily be incompatible with device drivers, except that I expect it got enough testing and attention to find and fix all of that long ago.

Just google linux PAE incompatibility. Vmware and device drivers have commonly had issue with PAE. Although this may be dated at this point, look at Linus' opinion on PAE.

The first processor to support more than 1MB of physical address space was the Intel 286 CPU. It used a 16-bit protected mode to allow processes to access an arbitrary 64KB range of memory through each segment register. The segment registers were extended to support a 24-bit address and access up to 16MB of physical RAM.

The first processor to support 32-bit execution was the Intel 386 CPU. It was also the first CPU to support virtual memory (arbitrary mapping between a process virtual address space and physical RAM).

The first processor to support PAE (64GB of physical address space) was the Pentium Pro. Over 10 years after that time (1996) Microsoft has failed to support the use of PAE in Windows to address the full 64GB of address space. Intel and other chip-set manufacturers also have not supported more than 4GB of RAM until recently. It was even common for some non-server chip-sets to be limited to less RAM (like 256MB or 512MB).

Another less known hardware feature often poorly supported by Windows device drivers is DMA mapping registers in PCI bus bridges. The addresses used by PCI bus devices to access memory are not necessarily the same as the physical RAM addresses although that was usually true of early PCI bus systems. PCI bus bridges support mapping registers to translate the PCI addresses to physical RAM addresses but that only works if a Windows device driver follows the rules for setting up DMA transfers.

Linux is a multi-platform OS and has not suffered from some problems simply because other architectures vary greatly in how they access memory and how DMA transfers work. Linux had to start out with much more flexibility and less assumptions than Windows. The Windows driver design was less flexible, and in spite of supporting the Dec Alpha for a while Windows NT was modeled after DEC VAX/VMS. Many of the assumptions were the same for how the PC and DEC Alpha hardware worked. The rest was pushed down into the HAL (Hardware Abstraction Layer). The HAL wasn't a Microsoft idea. DEC VAX used something similar to support the various VAX models all with slightly different hardware. Dave Cutler brought that and many other ideas with him to Microsoft when he left DEC.

It is really a combination of marketing decisions by Microsoft and Intel that have driven the 4GB RAM limitation on most 32-bit systems, not any actual limitation in the CPU architecture or instruction set. Except for the fact that AMD threw in the 64-bit wild-card, we might very well still be using 32-bit Windows operating systems and PAE mode to address up to 64GB of RAM. Intel was content to sell 64-bit using a different CPU architecture that was more expensive and saw no need for home PCs to have 64-bit. Microsoft was not thinking of 64-bit any time soon and was happily selling a 32-bit kludge for Windows Server to address RAM above 4GB (using only Microsoft server applications of course). Technically Intel was correct about 64-bit not being needed, but they didn't consider the marketing implications. AMD grabbed the home PC 64-bit market first. This is another case where being first does not provide any permanent marketing advantage, since people don't think of AMD as a better 64-bit CPU than an Intel CPU. It only gained AMD a temporary advantage.

The bottom line is that neither Intel nor Microsoft have tried to give customers the most possible from the capabilities of the hardware. Their decisions have been marketing driven. Linux fully supports the capabilities of a 32-bit CPU including PAE extended addressing. That makes using a 64-bit Linux OS less important than using a 64-bit Windows OS even though there are still advantages to 64-bit. Ironically Linux has less backward compatibility issues moving from 32-bit to 64-bit than does Windows.

Sloppy Windows drivers that did not use correct compiler data types for memory addresses and drivers that did not support PCI mapping registers would not work with a 64-bit OS if they were simply recompiled. Much of Windows assumed that window messages had 32-bit parameters and those were often used to pass addresses as well as 32-bit data values. I think those are part of the reason why 64-bit Windows XP did not fare very well.

Microsoft released a new driver model in Vista partly to address those driver issues. Unfortunately Microsoft didn't support PAE extended addressing in 32-bit Windows along with that new driver model. It would have been the perfect time to do so, while companies were rewriting drivers to support both 32-bit and 64-bit Windows Vista.

It's understandable that there is a lot of confusion over the advantages of 64-bit and what were actual limitations of 32-bit versus just marketing decisions. Linux is not totally free from arbitrary decisions either, since choices are often affected by availability of technical information, time available to make changes and perceived demand from users. So far I think that Linux has done a better job of fully supporting the features of the core hardware, if not always supporting every possible hardware device available.

Having PAE extended addressing in 32-bit CPUs for PCs is really more luck than planning. At the time Intel released the Pentium Pro they were still thinking in terms of using the same CPUs for both home PCs and server computers. Once the feature became a standard part of the Pentium design it was difficult to remove without affecting some applications. However Intel decided not to support the 64GB address space in home PC chip-sets. In 1996 the only chip-sets to support over 4GB were the Intel 450GX and 450KX. Intel continued to limit the RAM in less expensive chip-sets and most other PC chip-set manufacturers didn't bother to support over 4GB of RAM.

1 members found this post helpful.

Taken from wikipedia:

Without further qualification, a 64-bit computer architecture generally has integer and addressing registers that are 64 bits wide, allowing direct support for 64-bit data types and addresses. However, a CPU might have external data buses or address buses with different sizes than the registers, even larger (the 32-bit Pentium had a 64-bit data bus, for instance). The term may also refer to the size of low-level data types, such as 64-bit floating-point numbers.

Speed is not the only factor to consider in a comparison of 32-bit and 64-bit processors. Applications such as multi-tasking, stress testing, and clustering—for HPC (high-performance computing)—may be more suited to a 64-bit architecture when deployed appropriately. 64-bit clusters have been widely deployed in large organizations such as IBM, HP and Microsoft, for this reason.

Basically this allows larger chunks of data to be pushed/pulled into the cpu during every fetch and execute cycle. the cpu works by rapidly fetching and executing chunks of data. Now instead of fetching and executing 32-bit chunks you fetch and execute 64-bit chunks. There is more to it than this, but with this I'm sure you will get the idea.

Using a proper X86-64 linux distro will give you great results, such as Gentoo or Sabayon Linux for example. Now, don't expect to see your system run twice as fast, it doesn't work that way. It will be a little faster and just use the cpu to its full potential a little more than 32-bit. And if you use Gentoo or Sabayon, you don't have to worry about packages only for 32-bit machines as for every 32-bit package there is a 64-bit package for Sabayon, and if you wish to use portage you can just emerge it and let it compile as a 64-bit application if available or 32-bit (as they both will run on a 64-bit system). Sabayon=portage and/or entropy w/automagic updates | Gentoo=portage_only

and

Technically, EPIC is a philosophy (see http://en.wikipedia.org/wiki/Explici...tion_computing) and the Itanic is an example of a processor which uses such an instruction set philosophy. At some time, someone else could also design an EPIC processor, but with the success (or otherwise) of the Itanium you might feel that they would be well advised to feel disinclined to do so.

So, you could say IA-64 uses an EPIC instruction set, but not that EPIC is the name for the instruction set of the Itanium.

Note also:
I know nothing of the operation of Microsoft's marketing depeartment (and have a suspicion that I will be happier if I can leave it that way, if you don't mind), but the issue for us here is that Intel were trying to push their rather ill-starred Itanium in the face of the increasing performance of their own cheaper x86 arch and seemed to want to do whatever they could to keep the x86 crippled in server/big iron type apps, while still engineering performance increases in 'home', 'office desktop' and 'small server' apps.

In that context, it is unsurprising that AMD, uninhibited by the need to protect a struggling higher-end, more expensive arch, showed more enthusiasm for attacking the higher-end market with x86. Even if you ignore the 64 bit/memory space issue, I can't see any other way in which you can explain the crippling of virtualisation performance in 64 bit Core 2 arch products, but not 32 bit.

It should be unsurprising to learn that the system does not do the impossible. Essentially, the processor addresses pages using 32 bit addressing, but the chipset uses a system of pages to extend the addressing to allow more memory. The processor has to change pages, as appropriate, and there is some small OS overhead in doing this, but the apps don't have to bother about this, as the OS takes care of it.

The first x86 processor, surely?

Assuming that you mean Xeon, it has never had an explicitly EPIC (if you see what I mean) instruction set, although being a philosophy, someone in marketing would probably say that it has 'the advantages of EPIC without the overheads', or something. In general, though, as Xeons are server-orientated x86s (vaguely, a brand position like 'Opteron' in the AMD system), they have the same instruction set philosophy as the more mainstream x86 parts, but individual members of the series may have different clock speeds, cache sizes, memory compatibility and pre-fetch tuning. Err, and sockets and chipsets, of course.

Not really. The address and data buses remain the same size, so the maximum amount of data that gets transferred on the buses remain the same. The registers change in size, but that really doesn't change the situation with data buses and cache or the pre-fetcher, except to make things worse in the situations in which all that is required is a 32 bit (or smaller) number except that now you have to care about fetching 32 bits of what should be 'don't care' data.

Please do read johnsfine's comments earlier, particularly:

And while GCC can be used to compile for various sub-variants of the x86 arch, it is often not done. Given that the 64-bit arch doesn't have this issue for application compilation (at least, today), it is unsurprising that this will not be an issue with 64 bit code. I believe that this is a major part of the speed-up seen, when a speed-up is seen, in using 64 bit. At least, in those very few benchmarks that I have seen, and which have not involved memory sizes that could imply swapping, it has always been the programs which obviously could make use of SSE that showed significant benefit and the ones that seemingly were unlikely to use SSE that were slower. (Although, most things turned in about the same times, and the speed difference was only something you'd notice in benchmarking.)