8 more registers, and 1 specifically for efficient PIC code is a real benefit.
AMD64 Subpage
x86-64 - Wikipedia, the free encyclopedia
The baseline hardware is much improved over old i386, which is rather old design. Being able to assume hardware features like high resolution timers, may help application developers.
Do we really want to be stuck with a very old lowest common denominator?
PAE introduces extra complications to kernel page table management.
PAE will require use of bounce buffers.
Having 32 bit libraries on disk, is not a reason to stick with 32 bit architecture for most ppl.
> 8GB memory (32 bit PAE kernel supports that so you might
> consider staying 32 bit)
True, but PAE goes into meltdown above that. The kernel ppl, aren’t very keen on PAE.
Dropping PAE support, and running 32 bit, also has marginal performance drawback on a 4 GiB system, as kernel data structures were smaller. Some kernel modules provided as binary for default kernel, were not available with PAE enabled.
PAE is only really needed by a small number of ppl, who have 6 or 8 GiB RAM, and a 32 bit CPU. Above that it failed to deliver.
> I might just buy a PC using an AMD Athlon AM2 X2 5200 any minute now.
I’m using an AMX X2 5600+, 4GiB and it runs very well under 64 bit or 32 bit.
In performance terms, for general desktop, the differences are likely swamped by disk accesses.
The 64 bit arch is cleaner, and 32 bit compatability is excellent, there’s only a slight increase in object code size :
movl $symb, %eax # 5 byte instruction
movq $symb, %rax # 7 byte instruction
fir:~ # cd /mnt/bin
fir:/mnt/bin # ls -l ls
-rwxr-xr-x 1 root root 97768 Dec 3 11:56 ls
fir:/mnt/bin # ls -l /bin/ls
-rwxr-xr-x 1 root root 89484 Sep 22 2007 /bin/ls
Most of the time 32 bit, will perform very well as will 64 bit, but some applications and code will like 64 bit very much where 32 bit object is kludgy, so why not use 64 bit?
The download figures for openSUSE showed x86-64 DVD is nearly as popular as the i586 one, and still growing.