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?
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.
Why? If you are writing software, 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.
Most people design software for last generations systems, because that is where we will have most people using it. Knowing that 64bit is becoming the majority that means we can take more advantage of the new system.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
5yr old laptop with a turion processor? sure it might be 64bit capable but with less then 1GB of memory, is it even possible to run a 64bit OS on it? How bout a 700MHz Celeron (P3 era) that still runs WinMe? Hell the unit is still capable of everything asked of it today, which is office tasks - Word Processing, Email and Power Point. It's even used for some game play (games that don't install or run on Win7).
I Find it funny that people demand the latest greatest hardware when something like this old system still works and the really nice thing is, it uses a meager 60 watts of power. In fact, we're considering repurposing the thing to replace the home router due to the better memory (512M) and faster CPU compared to many of the routers you get today. Hell based on the specs, it's as good as a $2k Cisco unit though w/o the Cisco label or OS on it. Can I Sell it for that if repurposed as a proper router?
Mod me up/Mod me down: I wont frown as I've no crown
The most common wallpaper image on Debian desktops is of a green field. The most popular flavor of ice cream is vanilla. Thank you.
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
i386 and AMD64 are architecture not the manufacturer.
Intel Architecture won the i386 so AMD back in the days kept compatibility for that design.
AMD Architecture win the AMD64 (for 64bit vs the Intel Itainium) so future versions of Intel chips were compatible with the AMD64 architecture.
Last Year 10 year old computers were 32bit CPUs this years 10 year old computers are now 64bit.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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?
In my head I ran various scenarios in which a fresh 32-bit OS would be needed (older hardware, 16-bit apps, 32-bit drivers)...but in all those special cases you could just run Windows 7. I just can't see why they are putting resources to maintain a niche 32-bit flavor of Windows 8!
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?
I still own systems that can't run 16 bit software.
Give me Classic Slashdot or give me death!
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.
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.
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).
Was some AMD fanboy trying to make a point ...
Plausible. I know I was a bit disgusted in recent days when some $SHITHEAD was lambasting Linux users for not supporting AMD when the latter went out of their way to accommodate us. I haven't bought an Intel CPU since Randall Schwartz was railroaded by Intel's stupidity. I only go AMD and ATI, and that's been the case for more than a decade.
"Tongue tied and twisted, just an Earth bound misfit
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.
My webserver runs on a 32-bit machine. I can't remember how old it is -- probably about 10 years (the processor is an AMD Athlon 1.4GHz).
It runs my website fine, and the website for a community group, and hold all my photos, and my parent's photos, and a backup of my desktop PC -- hosting for 70GB of photos wouldn't be cheap.
(My offline backup PC boots up once a month to back up the webserver. That also has Debian, and is even older -- an 800MHz CPU, I think.)
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.
> Who owns a system that still cannot run 64bit software?
I've got one that I use regularly, but I'm really only using it as a router, so I'm not sure that counts.
If you count systems that I don't turn on on a regular basis but which are still in working order if I should happen to want them for any reason, then I've got several, including a MicroVax 3100-40 and an old ITT XTRA (though, the hard drive in that one died years ago, so to use it I'd have to find a bootable 360K floppy that's still readable).
Cut that out, or I will ship you to Norilsk in a box.
> 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.
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.
On the Windows side I think it'll be Real Soon Now that AAA games start shipping with 64-bit executables so they can use all that RAM, especially when XP stops being supported.
Hail Eris, full of mischief...
E pluribus sanguinem
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.
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!
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.
Bullshit. Benchmark CPU-intensive code compiled for 32bit and 64bit and you'll see the 64bit version is, on average, much, much faster. There's absolutely no reason to refuse to use some features of your CPU.
I do... I have a laptop which I got from a friend of my sister. It had a cracked screen, I replaced it. The CPU is a Core Duo... Not 64-bit. From online reviews, I date it around mid 2007. (Fujitsu-Siemens Lifebook S7110, yes there are Core 2 Duo models, but mine isn't) It supports up to 4GB RAM (never tried, I only had 2x1GB modules lying around, which I used to upgrade from the 2x512MB modules) and runs both Windows XP Pro (license sticker included) and Ubuntu 12.04 LTS i686 just fine.
Now, granted, another of my laptops, also a Fujitsu-Siemens (Amilo Pa1510) is AMD Turion based and can run 64-bit. Alas, that one doesn't run Ubuntu 12.04 LTS fine, because the graphic chipset (ATI X1100) isn't supported well in the open source drivers and ATI dropped support from the proprietary ones :-(. So, on the road, I take the S7110....
That said, from approximately mid-2008, I expect everything to be 64-bit. However, 5-year old gear can be perfectly usable.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
In my experience with Java apps, you don't need a large app to take a few GB of RAM. Small ones most defintely can! I was using a Java-powered DLNA server and was surprised to see it try to use over 2 GB of RAM!
It means that I can keep 32 more bit flags in a register.
Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
Yes, absolutely... Works perfectly fine. Now, you might argue it doesn't make much sense as you only have 1GB RAM to address, but it will work. I have a Fujitsu Siemens Amilo Pa1510 that originally came with 1GB RAM and it does run a 64-bit OS just fine. [*] It support 2GB RAM (which I have installed), but not more. It seems to be a BIOS issue. Dropping in 2x2GB ram resultsin 2.4GB memory addressable. Weird stuff.
[*] That's not 100% true, because the graphic chipset has no more support in proprietary drivers and as such a modern GUI is basically unusable, but that's hardly the CPU's fault.
For the record, the P-III machine won't be 64-bit. How old are those again? From wikipedia, the last released P-IIIs were in 2002. That's pretty much a decade. In the dumpsters around where I live, you can find socket 754 and socket 939 AMD64 machines, and I've seen the first few 775 socket machines showing up.
Now, the most popular 32-bit machine in recent times, I can think of is the original Asus EEE 701. Celeron CPU at 900MHz, released mid 2007.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Why were you modded up?
Your entire post is either trollish or flamebait.
You are terribly misinformed about how PAE works on Windows or Linux.
On any non-PAE enabled 32bit OS the limit is 4GB.
Furthermore, you require PAE-capable hardware.
Also, PAE is a terrible, performance-degrading hack.
Where in the Midwest is Coke used generically for Pepsi? I've never heard it in Michigan, nor in any other Midwest State in which I've spent any time.
Most benchmarks i have seen have much better speed up than 4%. eg http://www.scribd.com/doc/363677/Benchmarks-AMD64-in-32bit-mode-vs-64bit-mode-Ubuntu
Those LFS benchmarks are comparing build times. ie building a 64bit exectuable on a 64bit system is 4% faster than building a 32bit executable on a 32bit system. by that logic you should compile everything with -O0 or -O1 because thats much quicker to build.
The plausible explanation that i have heard for the big speed up is that for x86_64 you can assume that the CPU has things like SSE2, where as if you build i386 packages you might want to support older chips pentium 2 or 3, or chips like the via that lack some newer instructions. if you build everything with -march=native then you can enable the extended instruction sets on 32bit, but given the context of the discusion debian can't enable SSE2 on their i386 packages.
Er, generically for soda, that is. Not generically for Pepsi.
Depends on the code. One thing you left out is long mode gives you access to more registers. That can give you an incredible speed boost with the right compiler and work load combination.
Its also true that memory, primary and secondary has fallen in price dramatically. So needed 9% more of it for typical loads is, not a relevant performance metric for most desktop / workstation deployments and even many types of servers.
Finally PAE can be a significant performance hit. So I don't think its fare to suggest that you need a single thread using an image larger than 4GB before you see gains in that sense either.
I would say if you have a clear reason not do so fine; but otherwise if in doubt put the 64-bit version of your platform on your AMD64 machine. That is were you going see the best performance for the widest variety of use cases.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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....
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?
You mean the south/southeast? It's pop or soda in the midwest.
http://www.popvssoda.com/countystats/total-county.html
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.
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.
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.
There is a really excellent reason to migrate. The reason is the extra registers you get with the 64-bit instruction set cause a lot of programs to become significantly more efficient. Like 10-30% faster. But otherwise, you are completely correct.
And, of course, there's the mitigating effect that pointers are all twice as big and so they take more memory, more cache space, reduce locality of reference and so on. From what I've seen, the positive effect of the extra registers usually outweighs the negative effect of the pointers being larger.
Need a Python, C++, Unix, Linux develop
You realize, of course, that the first people to come out with 64-bit processors that were fully backward compatible with the 32-bit x86 instruction set were AMD. When Intel finally came out with their own a year or so later, they quietly made them completely instruction-set compatible with AMD's 64-bit offering. But their manual offered no hint that this was the case. You had to go through the entire instruction set and compare and see that all the same instructions existed with all the same numeric values. They wouldn't even tell people who asked in any direct sort of way.
For this reason, Linus was very peeved at Intel. And because Intel was being such a jerk about it all, he threatened to call the new platform 'AMD64' instead of 'x86_64'. And a few people agreed with him. The legacy of that debacle is lying around in a few places, and apparently one of them is Debian's platform naming convention.
Need a Python, C++, Unix, Linux develop
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/
The midwest is generally pop. It's the south where they use coke for any soft drink
Here, here. Intel is evil, even more evil than Microsoft. They have done just much harm to computing and as Microsoft and Apple. They are anti competition, anti consumer, and pro DRM, and they hate 3rd world children(see OLPC). Fuck them, Intel are dirty scumbags.
---- GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
Two of my most heavily used servers at home can't run 64-bit software. They have dual Xeon 2.8s, 8GB RAM, and run the latest CentOS just fine. They were previously running vmware esx fine. My personal workstation at home is a Dell Precision 650 (and can't run 64-bit software) with dual Xeon 2.8s, 4GB RAM, a nice Quadro FX graphics card, and runs Fedora 14 and Windows XP in vmware quite happily.
These machines work perfectly and perform very well for what I need. What does it matter that they can't run 64-bit software? If I want to run 64-bit software, that's what my SGI Challenge XL running in the garage is for.
Windows implemented PAE, and it even worked properly... They intentionally disabled support for >4GB on lower end versions of windows, the code actually checks wether you have a license for using more ram. I believe someone documented this this a while ago and made a blog post about it...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Try the East Coast, it's terrible. Ridiculously high stress compared to the midwest--high population density, mcdonalds like every other corner (there's a map), and the East Coast is ridiculously politicized. Politics IS religion on the East Coast, people walk around all day talking about the evil otherparty. Midwest who cares? Are my crops going to fail?
Support my political activism on Patreon.
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.
Show me the numbers!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
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
What you really want is X32:
http://en.wikipedia.org/wiki/X32_ABI
So you can make use of the extra registers available in 64bit mode, but only use 32bit pointers so as to save memory.
Most commercial unixes such as Solaris and IRIX had a 64bit kernel with 32bit userland apps for much the same reason.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Yes, do that. Where it doesn't matter, if you go willy-nilly saying "long" or "int" what you get is 32-bit "int" and 64-bit "long" that "shouldn't matter" and then very strange shit happens. Where it matters precisely how big it is, you use uint32_t or int64_t or whatever. If it doesn't matter precisely, either say 'long' or say 'int' for shit that's going to be carrying these values--parameters to functions, local variables, variables in structs, whatever. Don't go scattering 'long' and 'int' as interchangeable or shit will break.
Support my political activism on Patreon.
If I may, because I worked for Intel at the time...allow me to shed a small bit of light on this.
Intel had a prepared 64 bit product...and no, it wasn't itanium. Different architecture for a different part of the building than the desktop. Problem with the 64 bit product was lack of operating system and driver support, meaning the only value it'd bring was >4GB addressing, at a time when 2GB of ram was considered absurdly large.
People want to slap AMD on the back for what they did, but what happened was a half assed 64 bit implementation with limited kernel support, very little in the way of stable drivers, and no applications to speak of.
Competition may be great in some regards, but if it makes you fire off three shots before aiming, its not really a measured success if you happen to accidentally hit something. Most of the people who bought 64 bit cpu's back in the day had no use for the capability whatsoever, and didn't have much benefit until years later.
Years ago Intel built silicon in partnership with the operating system vendors and app suppliers, and when the products were released there was actual code you could run on them and gain benefit from the purchase.
The only reason AMD tossed it out was because most computer buyers have no idea what they're buying, and 64 is more than 32, and AMD was getting hit in the face with the Core architecture, and realized they were 5 years away from starting to compete with that.
wasn't PAE a feature introduced on the Pentium Pro? so most 32bits processors should support it. (of course there could be old VIA CPUs or something, or artificial disabling on some Intel models, or what have you). not that 32bit systems with over 4GB memory would be exactly common (you might need a pentium 4 variant with artificially disabled 64bit support and a ddr2 motherboard, or max out some rare high end x86 server from before the transition.)
your grandmother's celeron running windows 98 is PAE-capable hardware.
...because Intel was being such a jerk about it all, he threatened to call the new platform 'AMD64' instead of 'x86_64'. And a few people agreed with him. The legacy of that debacle is lying around in a few places, and apparently one of them is Debian's platform naming convention.
Debian project always tries to do the right thing which is why I love them. On top of shipping arguably the best distro.
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.
char is -128..127 or 0..255. If it matters use signed char or unsigned char.
Never use short int. (If you want 16bits use "int16" or "uint16" (correct spelling left as an exercise for the student)).
Use int for "normal" ints.
use long int if you want an int the same size as a pointer.
If you want 64 bits use "int64" or "uint64" (see 16 bits re spelling).
Watch this Heartland Institute video
You are insane.
Watch this Heartland Institute video
That may be one usage, probably even the proper one, but I have seen "x32" used for what was clearly plain x86-32.
Sorry, but this is just blatant Intel fanboism. And B.S.
People want to slap AMD on the back for what they did, but what happened was a half assed 64 bit implementation with limited kernel support, very little in the way of stable drivers, and no applications to speak of.
GCC and Linux had support for AMD64 *before* the CPUs were even officially released. And they were initially targeted and sold for Linux clusters (iow to people with money and experience in system building).
Competition may be great in some regards, but if it makes you fire off three shots before aiming, its not really a measured success if you happen to accidentally hit something.
But AMD actually hasn't just randomly tried to hit something. It wasn't a shot in the dark. They went straight to customers and system developers and plainly asked what they wish in a new 64-bit architecture (cheap + b/c with i386 were obviously the top two things). (Unlike Intel who basically tried to force everyone to love the much delayed and overly expensive and underperforming Itanic.)
AMD64 or x86-64 or x64 became success not because it was a lucky shot - but because it was based on a vast pool of feedback from people who actually needed an affordable 64-bit CPUs. The high-end servers and clusters have carried the AMD64 into main stream market. Desktop/etc were not the focus in the beginning, but caught up only later when the prices have fallen down.
Most of the people who bought 64 bit cpu's back in the day had no use for the capability whatsoever, and didn't have much benefit until years later.
I had bought IIRC 2nd gen 64-bit dual core CPU from AMD back then for the simple reason that it was only marginally more expensive than comparable 32-bit CPU. It ran 64-bit Linux pretty well - because AMD64 wasn't the first 64-bit architecture Linux ran natively on. It was perfect for the development purposes (as I mainly develop software for 64-bit *NIX systems anyway (including Itanic btw)). So it has paid off for me.
Otherwise, what benefit one could expect from a 64-bit CPUs Very very few desktop applications require more than 4GB of RAM. But then again, 64-bit CPUs for PCs pretty quickly fallen down in price (thanks to Intel's Core series) so there was very little difference even back then. And if there is little difference, why not take 64-bit one?
All hope abandon ye who enter here.
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.
"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."
The PAE kernel limiting Firefox to 4GB left me 4GB to work with on my Thinkpad when FF "went apeshit" now and then.
It can be a useful "restraint".
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
Use int for "normal" ints.
Be aware that if you are porting to more obscure platforms that int may only be 16 bit.
ideally you should use intfast16_t or intfast32_t instead but most people probablly can't be bothered with that.
use long int if you want an int the same size as a pointer.
That will produce code that works on most platforms but that will break horriblly on win64. C makes no gaurantees on the relationship between long and pointer. The type you are looking for is intptr_t.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Your entire post is either trollish or flamebait.
You are terribly misinformed about how PAE works on Windows or Linux.
He made a technical error, windows supports PAE but the vast majority of windows installs out there have cripped PAE support and MS makes you pay through the nose to raise the limits (you have to buy server enterprise or above). Yeah you can hack the kernel to bypass the restrictions but I wouldn't call that a supported configuration.
So for most desktop windows users the only practical way to get support for more memory is to run a 64-bit version.
On any non-PAE enabled 32bit OS the limit is 4GB.
True but only really a problem for windows since linux comes with uncrippled PAE support for free.
Furthermore, you require PAE-capable hardware.
True but afaict all cpus/chipsets that support 64-bit modes also support PAE in 32-bit modes.
Also, PAE is a terrible, performance-degrading hack.
Please provide a reputable source for this claim. The benchmarks I can find seem to show the performance impact as being negligable compared to a plain 32-bit kernel (though interestingly in some tests the 64-bit kernel was far better than either the regular 32-bit kernel or the 64-bit one).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
> Who owns a system that still cannot run 64bit software?
Me. Me. Me. I made the mistake of buying an early netbook with a Z520 dual core Atom cpu. The Poulsbo GPU didn't help either... bleagh. For a couple of years, it was almost a doorstop under linux, running painfully slow VESA 1024x768. Earlier this year, an open-source Poulsbo driver for linux was reverse-engineered. See http://blog.bodhizazen.net/linux/linux-gma500-poulsbo-driver-moved-out-of-staging In addition to the kernel setting, I had to install xf86-video-fbdev as the X11 video driver.
1) It woiks!!! The netbook is now displaying 1366x768.
2) No xorg.conf required. And udev is not sniffing anything out, because the machine is running on mdev.
3) Performance is decent for an early Atom. I used Youtube for quick-n-dirty torture testing...
- 480p Youtube videos are OK, even at fullscreen
- 720p Youtube videos are OK on the standard player and large player,
but stutter slightly at fullscreen
- 1080p - fuggedaboutit
4) Getting brightness control, etc, to work is still hit-and-miss.
5) Hibernate (suspend-to-disk) does not work. Reading comments at the blog, that appears to be a known problem with the GPU and the kernel driver.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
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."
But then, if your hardware supports it, there's not a good reason not to, either. Unless you're one of the rare few that happen to need a particular version of Flash or Java, there's no advantage (and a slight performance penalty) to sticking with a 32-bit Linux distribution.
Also, it may be rare now to have a process that takes up more than 4GB of address space, but you'll be surprised how quickly that will cease to be true. The instance of Firefox that I'm using to write this is taking up 308MB of memory and that's only with a few tabs open. I imagine heavy users bump up against 1GB routinely.
I can't find the source at the moment, but there was a discussion on LKML where a few of the kernel developers were threatening to write a patch which refused to let a PAE kernel boot on AMD64 hardware.
I think you have those quite reversed...
When the first AMD64 processors were released, Linux was the only mainstream OS that could take full advantage of the hardware on day one because AMD actively worked with the open source community to get support for their chips in software like the kernel and gcc before launch. In truth, it wasn't that hard because Linux already had mature 64-bit support on other platforms (sparc, mips64) for years.
And for years, Linux was still the only mainstream OS that had good 64-bit support. The only thing holding users back were a couple of proprietary desktop applications that are now finally becoming fully obsolete. System administrators have been able to run full 64-bit Linux on their servers for what, 8 years or so.
But on Windows, everyone had to wait for software and hardware vendors to get their crap together in order to run anything decent. And I know a number of businesses who cannot and will not swtich over to 64-bit Windows any time soon due to legacy hardware and/or software requirements.
That will produce code that works on most platforms but that will break horriblly on win64. C makes no gaurantees on the relationship between long and pointer. The type you are looking for is intptr_t.
Oh, they even managed to fuck that up!
What is sizeof(long)? 4? 16?
Watch this Heartland Institute video
What's a int64_t and how does it differ from a long? Or is it something from the latest, new-fangled C standards?
Reminds of of Microsoft's wide int definition types from their Windows programming header files.
I'm not a lawyer, but I play one on the Internet. Blog
And for years, Linux was still the only mainstream OS that had good 64-bit support. The only thing holding users back were a couple of proprietary desktop applications that are now finally becoming fully obsolete. System administrators have been able to run full 64-bit Linux on their servers for what, 8 years or so.
Back in year 1999 (yup, that's full 13 years ago) I was using my desktop Linux (Red Hat Linux 5.1) on DEC alpha, which was fully 64-bit kernel and user space. We've been running Linux on some seroius DEC alpha machines instead of running DEC's own UNIX implementation (OSF/1) because it actually behaved better.
After I changed my employer in 2002, I had to downgrade to i386 version (being much more stable than amd64 at the time).
The problem is people use 'int' and 'long' interchangeable because on x86 sizeof(int) = sizeof(long). On x86_64, sizeof(long) > sizeof(int). So they have int foo getting passed along to int func1(long foo) and set by long func1(int foo) etc. Then, strange things happen when they compile to 64 bit.
It doesn't matter what you use for what, but you must be consistent. If it's consistent, it works. If you use all int storage for a particular variable as it gets assigned to other variables, structure elements, and passed to functions, then your program is type safe and you know what you're doing. If you willy-nilly pass an int as a long or vice versa, shit breaks. If you store a pointer in an int that's even worse.
Support my political activism on Patreon.
long is 32 bits on i386 and 64 bits on x86-64. Except maybe on Windows 64 where long might be something different, as long as it's at least as big as int. The new C99 standard defines [u]int[$sz]_t for [unsigned] integer of $sz bits.
Support my political activism on Patreon.
OS X had an emulation mode that allowed both PowerPC and AMD64 programs to run.
It would seem to me that the Mighty Microsoft could had made a 16 bit emulation mode. I mean you just click on the program the OS already gives you an error. Just swap to a 16bit emulation mode. Yes easier said then done but not impossible.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Oh, they even managed to fuck that up!
They made a choice that was within the C standards, it just happened to be a different one from unix like platforms.
When some programmers are assuming long is the same size as pointer and some are assuming that long is exactly 32-bit then the platform vendor is going to have to break some code in the move to 64-bit. The only question is which code.
I also expect that there is a lot more code using long for 32-bit in the windows world than in the unix-like world because 16-bit systems went away much earlier over there.
What is sizeof(long)? 4? 16?
4
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
..of what utility is this? Who is running 16-bit programs? Windows 3.1 was 1992
OS X had (dropped in 2011) an emulation mode for an architecture that was sold, marketed, and targeted up into 2006. Thats 5 years of support.
WIN16 was outdated starting in 1995, was supported up until 2006. Thats 11 years of support.
Now what exactly where you trying to day?
"His name was James Damore."