Slashdot Mirror
AMD64 Surpasses i386 As Debian's Most Popular Architecture
An anonymous reader writes with a quick note about the changing tides of computer architecture. From the article: "Bill Allombert announced [yesterday] via the Debian-devel mailing list that the X86_64 version of Debian has now surpassed all of the other supported architectures by a narrow margin. The most surprising part of this announcement however, and accompanying info-graphics provided on the Debian Popularity Contest page, is that this was not already true."
considering lots of people use older machines to install Linux on to breathe life into them, to act as servers, etc.
Erm... AMD64 doesn't mean AMD proc's.
It has started to actually work this year in Debian and *buntu distributions (on Debian use testing or unstable). Though you should be warned: You will likely end up with duplicates of all major libraries.
You should check up on PAE kernels.
Microsoft's flawed implementation (or lack of implementation) of PAE modes means that 32bit Windows can access and manage only 4GB of address space in total, even on a 64bit processor. Linux, BSD, and others implemented PAE correctly, and 32bit Linux can access and manage 64GB of RAM on a 64bit machine. Since it is rare for a single process to require more than 4GB of its own address space, there is not much reason to migrate from i386 to amd64 on Linux. On 32bit Windows, however, the total address space of all processes including the base OS and hardware I/O space cannot exceed 4GB. Hence the rapid shift from 32bit to 64bit in Windows, but the much more leisurely migration on Linux and BSD.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
Oh dear, you must've been posting from a 32 bit Debian install.
"If anyone needs me, I'm in the angry dome."
Microsoft's flawed implementation (or lack of implementation) of PAE modes
PAE has worked fine on Windows Server. Microsoft just disables PAE on 32-bit client operating systems because developers of drivers for desktop PC peripherals have been even slower to make their drivers PAE-clean.
"Who owns a system that still cannot run 64bit software?"
I have plenty of them. Two routers that are still 32 bit only. I have several embedded PC104 industrial computers that are running robotics that are 32 bit only.
you know, those of us doing REAL work with computers. We need the older 32 bit Linux OS builds.
Do not look at laser with remaining good eye.
Was some AMD fanboy trying to make a point or did someone post this pre-coffee?
Debian gave moniker "AMD64" to the Intel/x64 systems to honor the facts that (1) AMD had introduce it and (2) without AMD we would never had the affordable 64-bit systems. (Intel's version of the 64-bit future was the IA-64.)
Similar sentiment btw was shared by Linux kernel folks, but they decided (== Linus decided) in the end to use vendor-neutral 'x86-64' moniker.
All hope abandon ye who enter here.
It's really just that naming is a mess.
The 32-bit architecture is known, variously, as "x86", "x86-32", "x32", "i386", "i686", or "IA-32".
The 64-bit architecture is known, variously, as "x64", "x86-64", "Intel 64", "IA-32e" ("IA-64" was taken by Itanium), "AMD64", "EM64T", and I think VIA has their own name for it.
Intel, obviously, uses the term "Intel 64" in marketing, "IA-32e" in technical writing. AMD obviously uses "AMD64", but as they were the first, many open-source projects were started under that name, and the term remains in use for historical purposes. Proprietary software tends to use the vendor-neutral "x64", while technical literature tends to use the more precise "x86-64" (as it is, after all, not the only 64-bit architecture around).
Executable files are slightly larger and there is no speed gain.
That depends on what applications you are running. Things that are math heavy can run significantly faster in 64-bit mode. As an example, RSA requires modular exponentiation of very large numbers. Algorithms to do this are comprised of a number of multiplications of equally large numbers. Since these numbers are on the order of 2048 bits, they need to be chunked into machine size blocks in order to actually do the multiplication. Having a 64-bit integer size already gives you at least a 2x speedup here because you have half as many blocks. Multiplication algorithms are also not quite linear (close to n log(n)) so it really gives you a bit more speed than that.
What I found more interesting is, if you look at the graphs, i386 installs are not decreasing. The rise of 64-bit installs appears to be coming either from new users or from other architectures. The level of i386 installs has remained fairly constant for the past several years. This suggests to me that people are no abandoning 32-bit builds.
You do know that no 64-bit OS can run 16-bit applications without a virtual machine emulation on AMD64, right?
Once the processor is in 64-bit mode it cannot get back to 16-bit mode without a processor reset. Not even Linux can thunk from 64-bit back to 16-bit, because the processor architecture makes that impossible.
Your suggestion that "windows flopped" due to this is horse shit.
"His name was James Damore."
Stop spreading FUD. 64 bit executables have smaller code. The larger executable size is due not to the increase in code size but to the unwind tables. On i386 executables are typically compiled with the frame pointer model, where functions store the current frame address (the start point for local variables) on the stack. On x86_64 the normal method is to let the compiler figure out where the local variables are based on the stack pointer. This way there is at least one memory access removed.
Omitting frame pointers incurs the cost of emitting a table of function information to allow C++ exceptions to walk back up the stack. This information is stored in the .ehframe section of the executable and only needs to be loaded when the application throws an exception. This section is not part of the working set. It is also not used by pure C programs. So, although the executable size is larger on x86_64, the extra space it is consuming is on the disk, not your CPU cache.
Yes, you always benefit from building everything for x86_64 if your OS is x86_64. And unless you are running some application where benchmarks definitively show a performance decrease in the 64 bit version, there is no reason whatsoever to run 32 bit any more. Drivers are no longer a problem. So stop spreading FUD!