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.
what an utterly pointless tidbit of information.
Simple news is so....simple! Last year the most common 10 year old computer was a 386. This year the most common 10 year old computer is an AMD sled?
Really eye opening. Was some AMD fanboy trying to make a point or did someone post this pre-coffee?
Who owns a system that still cannot run 64bit software?
I was really surprised that windows 8 will still be published in a 32bit flavor. Considering the only semi-recent x86 line to not support 64bit is some of the older atoms, why did they bother to keep it around? Maybe it has something to do with ARM and winRT, which is pretty much 32bit only.
Aside from the above mentioned atom CPUs (And perhaps intel's new phone oriented SoC designed to compete with ARM SoCs of the same nature), you'd have to have an older P4 based system to not enjoy a 64bit OS (P4s got 64bit about half-way through through the product line's lifetime).. And P4s are starting to look pretty damn long in the tooth.
How far is multiarch support, i.e. being able to install 32 and 64 bit packages along side each other, and that not just on the Intel architecture but any CPUs which support both 32 and 64bits?
Have any other distros pulled this off?
m68k, as in Motorolla 68000 support? The same chip that went in to pretty much every mac until the power macs were released in 1992 or so? I've heard of m68 linux, but their repos hadn't been updated since 2003 or so. Or is there another popular 68k platform I'm forgetting...
moox. for a new generation.
I have a Debian installation running on my very modern main desktop. I run i386.
The installation has been migrated through several hardware configurations (3 major changes and some incremental) for 7 years now. This has resulted in minimum maintenance time. When the installation took place, I had a P4.
I believe I tried a run-time upgrade to amd64 once in 2006 with new hardware. I also think I spent several hours to reverse it. Multiarch is something I'm looking forward to, and it seems to be developing quickly, but I just don't have a reason to upgrade right now.
Debian i386 - stable as a rock, and with PAE definitely good enough on my Core 2 Duo with 8GB RAM. On a new installation (such as my newer laptop), I'd without a doubt go amd64. It is the modern way.
The most common wallpaper image on Debian desktops is of a green field. The most popular flavor of ice cream is vanilla. Thank you.
Maybe now Canonical will finally recommend 64-bit. Not only because of this, but also because Ubuntu 12.10 uses Unity3D over LLVMpipe on computers without hardware 3D, and LLVMpipe is much more efficient on AMD64.
Going slightly off-topic, can Intel and AMD start deprecating i386, to save transistors? They could do it on stages.
First, release CPUs where half of the cores implement i386 on microcode, and the other half implement i386 in full speed; then, release CPUs where half of the cores implement i386 in microcode, and the other half do not implement i386 at all; then, get rid of i386.
Oh dear, you must've been posting from a 32 bit Debian install.
"If anyone needs me, I'm in the angry dome."
This isn't the most massive surprise. I run 32-bit Linux on 64-bit processors in some cases. If the machine has 4 GB or less RAM (and in some cases, 64-bit machines have a maximum RAM capacity of 4 GB anyway), then there is no point in running a 64-bit distribution. Executable files are slightly larger and there is no speed gain.
Of course, if you have a 64-bit CPU and your machine has or can accept more than 4 GB RAM (and in the latter case, you plan to expand it to 8 GB or more at some point), it makes sense to start with 64-bit installs at the beginning. Yes, you could use a 32-bit install with a PAE kernel but it seems more sensible to me in that case to just use 64-bit Linux to begin with.
Also, the points made above that Debian is not bleeding edge and that people often run Linux on older hardware are absolutely valid.
I'm not the most current person, but my most modern two machines are an i7 and a Core 2 Quad. The latter is maxed out at 4 GB and so runs a 32-bit distro. The i7 has 8 GB so it runs a 64-bit. The server is an old PIII that is doing just fine on 32-bit, and the netbook is an N270 Atom so again, 32-bit.
The figures discussed in TFA are from popularity-contest. Debian gives you the option of whether or not to participate in that. If you do, certain information(including architecture) is sent back to the mothership. If not, it isn't.
I wonder how representative popularity-contest users are of debian users in general, and (to the degree that they aren't) what causes the non-representative behavior?
I know, just by way of example, that HP ships a bunch of thin clients based on their somewhat butchered version of debian, and it isn't wildly uncommon to find debian or variants in various other not-exactly-hidden-but-fairly-quiet locations. I assume that those generally don't participate in popularity-contest. Individual desktop users, by contrast, probably participate more frequently. Any other speculation on who might be overcounted and who might be undercounted?
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 AMD stock slips below $4 per share losing about half of its value in the last year. I've always been an AMD fan but never an ATi fan and I don't think they ever recovered after that tragic acquisition.
If you have that old program made for Windows 3.1 then you still need a 32bit OS.
Then run the 32-bit operating system in a virtual machine on the 64-bit operating system, such as the XP Mode powered by Windows Virtual PC that is available to all Windows 7 Professional users, or run the 16-bit applications in Windows 3.1 in a real emulator such as DOSBox.
While a lot of people thinks that a 64bit CPU deserves a 64bit OS for the sake of speed, it seems it's not so clear that it'd be a good move.
First, you need to have at least a single thread that requires more than 4GB RAM at once.
Say after me: "a single thread that requires more than 4GB RAM at once".
Probably an heavy loaded DB (to load a lot of indices in RAM) or a computer graphics imagery application or some other application with very very large data set to be worked on at once. Not impossible, but not so widespread. Maybe very large Java application can swallow all that RAM.
For a general understanding of CPU horsepower, give a look to a very simple observation (I wouldn't call it a real TEST) you can find in Linux from Scratch documentation
a 64-bit build is only 4% faster and is 9% larger than the 32-bit build
This also means that you have (more or less) 9% more chances that your code won't fit into the CPU cache, making that 4% extra speed less effective. And that you'll need (more or less) 9% more RAM to execute 64bit programs.
So, in my extremely humble opinion, unless you are running an heavy duty, heavy loaded server, you won't benefit that much from a 64bit OS on a 64bit6 CPU.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Although Debian and the chart refer to AMD64, it's really generic x86 64-bit support, not AMD-specific. I.e. even though there are differences between AMD 64 and Intel 64, Debian AMD64 will run on both. It would have been clearer had it been named x86-64, and indeed it used to be until it was changed with some tortured logic and desire to give AMD credit for being first with 64-bit extensions rather than have clarity of names and purpose.
Maybe now Canonical will finally recommend 64-bit.
How is the web site supposed to know whether the computer on which the install disc will be run supports 64-bit? If it suggests 64-bit by default, people will complain that the install disc does not boot and that they wasted 700 MB of their monthly cap.
Going slightly off-topic, can Intel and AMD start deprecating i386, to save transistors? They could do it on stages.
First, release CPUs where half of the cores implement i386 on microcode, and the other half implement i386 in full speed; then, release CPUs where half of the cores implement i386 in microcode, and the other half do not implement i386 at all; then, get rid of i386.
That's a horrible idea, for several reasons.
First, they already implement it "in microcode". They implement 16-bit and 64-bit in microcode as well - no modern (ie. post-2000) processor actually implements x86 in hardware. They all implement some secret RISC-like internal architecture, and translate x86 code into that on-the-fly. Gives you the benefits of CISC and the benefits of RISC, with relatively few drawbacks.
Second, you don't want to have different core implementations on different cores. That's just asking for trouble. And if you've gone through the work of making an x32 "emulator" or whatever, why use it on only some cores? People specifically looking for 32-bit support will ignore your product; people who don't care about 32-bit support won't get anything out of having half the cores support it "for reals".
Third, they can't remove x86-32 completely. They can't even remove x86-16 completely - every processor on the shelf right now turns on in 16-bit mode. Either the BIOS/EFI runs some commands to set it into 32-bit and then 64-bit mode, or the bootloader does.
Not any time soon. Also more than likely the x86 instructions are translated into 64 bit uops anyway. They translate them anyway so what is one translation vs another... Negligible. Also remember those CPUs still probably support 8bit/16bit operations. You probably could get the cpu to act like a super powerful 80186. While the desktop/server market is huge for them. They also have a huge other market they want to support. Never mind taking it in the shorts in a bunch of benchmarks...
Most modern x86 style cpus have long been translators anyway. All the way back to the first 686. The atom processor is a sort of throwback but they are moving it to a 686 style in the next gen or two.
Also these days 40-50% of the cpu die is cache. They would just use the 'saved space' for some other instruction or to make an existing one run faster. The instruction decoder part is actually about 1/4th the cpu (or core these days). The memory controller is probably bigger.
They are getting close to SoC with these things. Next up is probably the bridge chip and all of its legacy I/O. At that point they will just add memory as that is all that is left to integrate in. Then it will just be a matter of density of the memory. At that point the CPU/GPU becomes a negligible part of the die.
Perhaps Canonical should recommend by default that you buy CD's from them since they can't know that you have a CD burner in your computer. Or floppies since they can't know if you have a CD drive in the machine you'll be trying to install on. Or just recommend that they'll sell you a whole new computer since they can't know if what you're going to try to install on will even run it.
"I use a Mac because I'm just better than you are."
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 need to have at least a single process that requires more than 4GB RAM at once.
FTFY.
Say after me: "a single process that requires more than 4GB RAM at once, including kernel space, which can leave 3GB or even 2GB to the process".
FTFY.
a 64-bit build is only 4% faster and is 9% larger than the 32-bit build
This also means that you have (more or less) 9% more chances that your code won't fit into the CPU cache, making that 4% extra speed less effective.
No - isn't that already taken into account in the 4% number?
And that you'll need (more or less) 9% more RAM to execute 64bit programs.
No - is most of the memory consumed by the binary, or the data structures it creates once loaded?
So, in my extremely humble opinion
No - not humble enough.
SOMEONE ON THE INTERNET IS WRONG.
I wonder how many people with intel 64bit CPUs assume that AMD64 is only for AMD cpus, and then download the i386 version. http://www.debian.org/CD/http-ftp/ does not make it particularly clear for none CPU nerds. maybe the different architectures could be labelled with descriptive names, rather than the short names. The ubuntu download page is simpler, offering a choice only between 32bit and 64bit, though it unfortunately still recommends 32bit. Fedora also just lists them as 32 and 64 bit.
Canonical should recommend by default that you buy CD's from them
They provide that as an option on the Ubuntu Desktop landing page.
since they can't know that you have a CD burner in your computer.
If a novice is trying to decide whether to download or buy, it's easy to tell whether or not the optical drive can burn CDs by looking for the CD-RW, DVD-RW, or DVD+RW logo on the disc tray. And even if not, a CD image can be turned into a bootable USB image; at least one of my machines got Ubuntu through UNetbootin. How can a novice easily determine whether a PC has a 64-bit CPU without opening the case?
Or just recommend that they'll sell you a whole new computer
They provide that as an option, though it's slightly harder to find than buying CDs.
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!
My little headless Debian box has been running the same i386 installation since 2006, which is just as well since it's a 32-bit CPU. It's also just as well, since it usually never uses more than about 85 MB of memory. Viva la Debian!
/* No Comment */
I re-installed my desktop end of 1996 and have only done in-place updates/upgrades since then.
Or maybe there is a way to do an in-place upgrade to amd64 or a mixture.
amusing 64 bit PC computing only recently popular on desktop, and 64 bit clean also only recent in the realm of x86-64. I've been on 64 bit unix desktops since the mid 90s....
I run both 32-bit and 64-bit Debian systems and a couple of times in the last year I've encountered a problem with Large File Support on 32-bit. Not in core libs or apps but in libdca-utils (DTS audio decoder & tools) and normalize-audio (audio file volume normalizer). I reported the bugs and both are now fixed but it does show that even on a machine that doesn't have >4GB RAM it may be a good idea to run 64-bit if the hardware supports it and you expect to work with large files.
You should pick Debian for 'new hotness'.
You also will if you're running the Debian version named Sid.
That is in fact the version used by Mint and Ubuntu when they roll their distributions.
So, it is in fact both hotter and cooler.
Still read this http://raphaelhertzog.com/2010/12/20/5-reasons-why-debian-unstable-does-not-deserve-its-name/
Really sorry. It's still x86. I downloaded several million AMD64 business card cd's last month for various personal reasons. Didn't mean to skew the statistics.
This signature intentionally left blank.
Am I reading that graph right that X86-64 is rising about as fast as ARM is falling? Most of the graph lines are holding fairly steady, with X86-64 rising and another brownish line (ARM? I'm having trouble reading the legend) falling at about the same rate. Considering that the Y-axis is marked in powers of 2 per increment I'm probably mis-interpreting this. On the other hand, it's certainly not stealing share from 32-bit X86. Hopefully it represents a bunch of new installs, and the year of the Linux desktop is finally upon us =)
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
I think that installing and administering a Linux distribution - even one as easy as Ubuntu - is much more difficult than finding out if your PC supports 64-bit.
So if the user is smart enough to switch to Ubuntu, he is smart enough to determine whether his computer supports 64-bit.
Installing and administering Ubuntu isn't any harder than installing and administering Windows in my experience, provided that the operating system has drivers for your hardware. Yet I'm not sure that a lot of owners of home PCs running Windows are aware whether the CPU is capable of 64-bit operation or not.
I think they fixed that around the 586 or 686, but sine you're usually choosing between i386 or AMD64
I'm under the impression that most Linux distributions compiled for "i386" are actually compiled for i686 because pre-1999 PC hardware isn't worth supporting anymore except in very specialized distros. Ubuntu, for example, dropped i586 support in 2010.
Why would you want a default that is optimal for a slim majority of users and completely unusable for a substantial minority, as opposed to a default that is optimal for a substantial minority of users and working yet slightly sub-optimal for the slim majority? If the news story were that x86 had fallen to 10 percent, I could see, but it's just a hair behind x86-64.
Here's the closest approximation I can think of that's an improvement over recommending 32-bit for everybody: "Did your computer come with at least 4 GB of RAM? If so, you probably want the 64-bit version. If not, or if you don't know, get the 32-bit version, which also works on 64-bit computers."
Well the x32 abi exists for a reason. Basically as when you get into anything into serious detail, the correct answer is typically "it depends".
Executable files are slightly larger and there is no speed gain. http://www.bollywudfunda.com/2012/09/nach-le-nach-le-full-song-bachchan.html