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.
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?
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."
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.
you mean not confusing long int with int in C programs? Which, by the way, is WRONG, but works on i386 because sizeof(long) = sizeof(int) whereas sizeof(int) may be sizeof(uint32) while sizeof(long) is sizeof(uint64) on amd64. In C, long long >= long >= int >= short >= char. On one platform long > int, and on another long = int.
Here's a tip: say what you god damn mean; if you want a long int, declare a long int instead of just an int. If you want a short int, declare a short int instead of just an int. If you declare just an int, declare just an int everywhere where that interface is going to come into play.
Programmers do a lot of allocating something big and shoving it into something generic, and it works because the generic thing is also big. But then they change platforms and the generic thing is now big but the big thing is now HUGE, and they put something HUGE in the big thing and then copy that into the generic thing and lose half of their storage space and get weird values out and the program doesn't work. Programmers think the computer should understand what they mean, not what they say, especially when it's "always been that way before." Like being in the midwest and asking for a coke, and you get a pepsi--because coke means soda. Go out east coast and ask for a coke and they're like... we have pepsi, is that ok? People are like, what? Yes that's what I said, what the hell? Programmers have this happen on computers and don't know why it breaks.
Support my political activism on Patreon.
you now know that we crossed a point where 64bit is more common then you will make your programs take more advantage of the 64bit systems.
What is the practical advantage of 64-bit code for processes whose working set is far smaller than 2 GB? Do the extra architectural registers in x86-64 really make that much difference in practice?
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).
> Do the extra architectural registers in x86-64 really make that much difference in practice?
For tight computations, they do. Most people run memory and i/o bound loads, so the memory overhead (64-bit pointers instead of 32-bit pointers) tend to cancel that out, and you only see modest speed gains.
And the 2GB limit of addressable memory is much more than a working set limit; it's easy to hit a fragmentation limit if you "only" need 1.5GB with some workloads. And the ability to mmap() every file and let the OS handle caching etc for me is also something I miss when I need to do 32 bit work.
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!
Once a processor is in x64 mode, it cannot run real mode/16-bit code at all. Even virtualized. It's just physically incapable of it.
The only way to run 16-bit code is to emulate it because the CPU will only take in 32-bit instructions in 32-bit compatibility mode.
Some virtualization software do have software emulators so they don't have to bother virtualizing 16-bit modes (VirtualBox does - in order to run the loaders of most OSes - the virtualization only takes over once the CPU is switched into 32 bit mode or better).
Windows has an interesting problem - because of the limitation of 64-bit mode, you'd think Microsoft would eliminate all the deprecated API calls for 64-bit Windows (but keep them around in the 32-bit libraries because theres enough legacy software out there that uses them). Calls like OpenFile(). But they didn't - their reasoning is purely developer convenience - you recompile your app for 64-bit windows without having to change many lines of code...
i suspect that quite a few people downloading debian (and linux distros in general) do not realise this. if the architectures were labelled more clearly a lot more people would probably be using the 64 bit version, and enjoying a significant performance increase.
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.
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/
Here's a tip: say what you god damn mean; if you want a long int, declare a long int instead of just an int. If you want a short int, declare a short int instead of just an int. If you declare just an int, declare just an int everywhere where that interface is going to come into play.
No, don't do that. Where it matters (and it usually does not) use stdint.h.
When all you have is a hammer, every problem starts to look like a thumb.
x32 is not IA32. It is actually AMD64 binaries using 32bit pointers. That way you get the small datastructures from 32bit, and the extra registers from x86 64bit mode.
Yeah, and that would be favoring Intel over AMD.
Why? Because Intel's supposed to be the "default" and AMD is only just "compatible" with it?
In fact, AMD's the one who created AMD64, and Intel licensed it from them.
I'm not a lawyer, but I play one on the Internet. Blog