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."
Erm... AMD64 doesn't mean AMD proc's.
And Debian, no less. You don't pick Debian for 'new hotness'.
I still carry i386 minimal install CD's with me, but it's been feeling odd lately to have to use them on servers. Even some of my Atom machines can handle the AMD64 instruction set. It looks like i386 (especially -proper not i586+MMX) is destined to become a 2nd-rung arch along with MIPS, PPC, etc. At the same time kernel ARM support (e.g. OMAP) is really starting to mature. It looks like the two dominant arches the not-too-distant future will be ARM and AMD64.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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
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.
And Debian, no less. You don't pick Debian for 'new hotness'.
Ubuntu has less amd64 installs than i386: http://popcon.ubuntu.com/
sudo dpkg-reconfigure popularity-contest and "Yes" to join the contest (mine was disabled for some reason).
"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.
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!
On Ubuntu's download page it doesn't recommend using amd64, it recommends x86.
That's probably why Ubuntu shows less amd64 installs than x86. They could get with the times and recommend amd64 -- my 6 (or was it 7?) year old laptop even supports the amd64 instruction set.