I don't consider that being "picky". It is being "accurate". The 32-bit instructions are not all emulated in microcode. There are some instructions in both AMD and Intel CPUs that are implemented in microcode because of the complexity of the instructions. That is not "emulation" because all CPUs implement those instructions using microcode. That applies to both 64-bit and 32-bit operation. The majority of the instructions are implemented in the hardware without using microcode.

AMD and Intel both spend a lot of effort (and hardware real-estate) to optimize the performance of the most frequently used instructions. Intel tends to focus on very specific situations, while AMD tends to focus on overall performance of entire classes of instructions or the whole CPU. Without looking at benchmarks it would be hard to say anything definite about performance differences between 32-bit and 64-bit operation on some particular CPU. I expect that many of the 32-bit instructions use the same hardware implementation as the 64-bit instructions with only slight modifications of how the results are masked and carry is handled.

One way that both AMD and Intel got slightly better performance from 64-bit is by eliminating support for segmentation and task selectors. That avoids some extra address translation steps and some privilege checking. Most operating systems use a "flat" memory model and perform their own task switching rather than using the hardware task selectors. Since all 64-bit operating systems on the X86 are new, it was reasonable to prohibit them from using those legacy features in 64-bit mode.

The differences in the size of instructions between 32-bit and 64-bit are complicated, but in most cases the optimization of instruction fetching and execution makes that unimportant for performance. It is mostly the size (not speed) of the software that is affected by 32-bit versus 64-bit.

it is relevant in so far as it limits the amount of physical memory the system can use. (note we are not talking about virtual address space here, nor demand paging.)

I suspect the reason some application may be faster when compiled for 64 bit CPUs is because they're able to use instructions not guaranteed to be available in pre-AMD64 CPUs -- SIMD type instructions, perhaps? In other words they may be faster more because they're compiled for more modern CPUs no because they're 64 bit.

Actually the 800MB (approx.) is the limit on kernel virtual memory space. The limit is the 1GB of process virtual space reserved for the kernel minus the space required to map PCI bus addresses. It does not limit the amount of physical RAM that the kernel or applications can use. The 800MB limits how much physical RAM the kernel can leave permanently mapped for access by the kernel. The kernel doesn't permanently map all of physical RAM. Instead the kernel temporarily maps individual pages or small ranges of pages when it needs to access the physical RAM. The limited kernel virtual space may affect performance but it doesn't limit the amount of physical RAM.

The actual physical RAM limit for a 32-bit kernel is 64GB. That is large enough that very few systems would ever encounter the limit. Note that this is not true of Windows, where Microsoft purposely limited non-server 32-bit versions of Windows to 4GB of RAM (by leaving out PAE support).

In fact the physical RAM on most systems is limited by the chip-set rather than 32-bit software. Intel made a marketing decision to limit their non-server chip-sets to 4GB until recently. Intel, like Microsoft wanted to charge a premium for its "server" chip-sets that supported over 4GB of RAM.

In some respects Intel and Microsoft were both dragged "kicking and screaming" into 64-bit by AMD. AMD used 64-bit as a marketing tool to regain the lead in CPU architecture (though it was temporary). Intel and Microsoft had no choice but to support 64-bit lest they be viewed as lagging behind technology.

There was very little real need for 64-bit CPU architecture, and there still isn't. Most programs do not need over 3GB of permanently mapped memory. Programs can re-map portions of their 3GB to access any amount of physical RAM. Very few calculations require 64 bits, and 32-bit CPUs can perform 64-bit calculations using multiple instructions. Even in 32-bit mode the MMX and SIMD instructions support 128-bit calculations (256-bit recently). Instruction optimization on 32-bit CPUs makes 64-bit calculations happen about as fast as they do on 64-bit CPUs.

So, pretty much any actual limitations of 32-bit software are artificial and apply to Windows rather than Linux. Some limitations of 32-bit hardware and software have occurred because 64-bit exists. They probably would not be limitations if 32-bit hardware continued to be developed. For example, there is no reason why PAE could not be expanded to allow more than 64GB of physical memory on a 32-bit CPU. If Microsoft had not produced 64-bit versions of Windows, they might have added full PAE support to 32-bit versions of Windows.

Usually AMD64-capable CPUs don't use the older x87 FPU for floating point math anymore, but SSE2 instead. So any distro compiled for AMD64 will make use of those SIMD instruction set.

That would make sense. A friend recently switched to 64 bit for music recording and 64 bit seems to handle it much better -- I wondered whether it was due to the SIMD instructions having fewer denormals and dealing with them better.

Yes it does unless you compile in high memory support.

It does what you say only if you compile in high memory support.

Only if you compile in PAE support on top of high memory support. PAE is a kludge. You're better off using 64 bit mode if the hardware allows it.

So you say. A lot of people disagree.

1 members found this post helpful.

actually the labtop is about 6 or 7 years old and it had Windows XP on it. It was my wife's. She got sick of its slowliness and bought a new computer. As far as I remember it was slow. I'd say it is now 4 four times faster with linux !

thank you very much for all your replies

as far as I understand there is no hurry switching to a 64bits kernel

I agree with Martinus2u.

As for performance benefits, there are some benchmarks:
http://www.phoronix.com/scan.php?pag...204_3264&num=1

1 members found this post helpful.

64bit mode should be faster; if for no other reason than the doubling of gp registers to 16.

After taking a look at the benchmarks, I was puzzled by the huge difference in disk performance between 32-bit and 64-bit. After a little investigation I found that the 64-bit C library memory copying functions have been optimized to use some of the newer instructions. Although those instructions are available to 32-bit CPUs they are not used in 32-bit versions of the C library.

From a performance standpoint that makes 64-bit Linux a much better choice on any CPU that supports it. It looks like more effort is being invested in optimizing 64-bit versions of the C compiler and libraries than 32-bit versions. As time goes on 64-bit software will continue to be developed and 32-bit software will receive less and less attention. That's a practical aspect of 64-bit versus 32-bit that I hadn't considered. It means that 32-bit software will probably never use all of the hardware capabilities of modern CPUs even if it could theoretically come close to 64-bit software performance.

2 members found this post helpful.

As I mentioned I think it's a CPU generational thing -- an AMD64 bit CPU can be guaranteed to have certain features that only "may be" or "ought to be" in x86 CPUs. So, rather than compiling a few different x86 or even i686 versions they code to an average.

This has been an informative thread and as a result I've decided to stick with Slackware64. Since my machine only has 3GB RAM I assumed that it wouldn't make much difference (and also I'm a little resistant to change) but the bottom line seems to be that if your hardware supports it you should go with 64-bit.

* I will say that flash player seems to perform better in 64-bit but that might just be in my head.