AMD64 Surpasses i386 As Debian's Most Popular Architecture 216
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."
Re:Not surprising... (Score:5, Interesting)
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.
Re:Talking about Debian and AMD64 (Score:4, Interesting)
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.
Re:Not a huge surprise. (Score:5, Interesting)
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.
More interesting (Score:3, Interesting)
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.
Re:Not surprising... (Score:5, Interesting)
On Ubuntu's download page [ubuntu.com] 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.
Re:Wow! (Score:2, Interesting)
In reality, while you can access 64GB on a 32bit x86 kernel with linux, there are issues. You will find that memory used to store those (massive) page tables will want to be used by other things, and running out of kernel space memory and crashing is pretty much the same as running out of memory generally and crashing, when looking at the final outcome.
I've tried 64GB + PAE on the blacksheep RH box in the corner running commercial 32 bit software (that was only supported on RH), and saw this very issue. Reducing mem with a kernel boot param to 16GB made things stable (something in between may have worked too; the box was purchased for a different purpose and will only temporarily be running this work load-- so spec'd for its ultimate purpose [which will be running a distro that doesn't suck-- Debian, of course]).
Debian packages 64bit kernels on 32 bit archs which solves the problems of PAE by avoiding them completely.
RH is (as usual) a bit behind the times with their solution-- to overcome this PAE issue they map the entire address space into both user and kernel, and do swaps at every user/kernel context switch (slow-- so slow that folks like VMWare recommend against using these RH kernels, as I guess between the RH kernel overhead and VMWare's overhead, things start really sucking badly. Never personally tried "hugemem" kernels on that RH box after reading the VMWare article about it-- the RH patch also never went mainline which probably says something about it too; besides the temp workload fits in 16GB just fine.
Of course none of this refutes your comments on M$'s issues. Part of M$s problem is with 3rd party drivers that just don't work in PAE mode, though.
The other M$ problem over the years has been, if you talk to some of their developers in person, they seem competent (or at least the two people I personally know do), so I'm guessing must be organizational issues that prevent solutions from competent devs being implemented. Things like font rendering occurring in kernel space so kernel level exploit vector to just include a funky font in any document is crazy talk. Things like not adding salt to pwords even though others were doing it since the 70s, seems to show either NIH on steroids, or an insular society where nothing others are doing is even looked at. Things like making pword hashes pword equivalent, so you could use the _hash_ of the pword to gain any access the real pword could (using 3rd party client tools; all the "security" in the M$ solution was an illusion that required the official M$ clients that "prevented this access client-side"-- yeah right! Apparently nobody with a security background had anything to do with their "security" implementation) etc. etc. etc.
All new Deb boxes, at my work, were 64bit for years (depending upon arch) before M$ offered a 64bit implementation. But, it is just so damn easy to upgrade a deb box, the older stuff stayed on 32 (we have boxes that while being migrated to newer hardware (dump |ssh | restore), have been upgraded all the way from potato without issues (I think debian potato was from win95 days for the M$ crowd). I don't understand this clean install stuff the M$ and RH folks do.
Mulit-arch (for you RH folks, NO multiarch is NOT just including a lib32 dir which has been around since the first days of the amd64 arch; it means seamless mixing of 32 bit and 64 bit arch bins [look it up is is quite a bit more than lib32]) allows a migration path without reloading to a 64 bit system; Also, I bet multiarch will incorporate the new 32bit address space with 64bit registers abi that just came out too, which will allow better perf than either i386 or amd_64 with the ability to run those few programs that need a huge address space on the same box where the majority of userspace is small 32 bit address space + amd 64 register bins). Multiarch will probably be avail when wheezy goes stable, so it will be an easy transition to 64 bit (or armel to armhf etc.) without a re-load on debian, so for the zillion legacy boxes we have-- we can wait (also, we can use 64bit kernels on these 32bit userspace boxes which gives us most of the benefits anyway.