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."
Not surprising... (Score:4, Insightful)
considering lots of people use older machines to install Linux on to breathe life into them, to act as servers, etc.
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:Not surprising... (Score:4, Insightful)
I actually choose Debian for servers, the biggest and fastest servers I can get my hand on. Debian isn't a desktop distribution, you got Ubuntu for that. But for a server you want a small and fast OS, You don't care much about X the server should be able to run by itself for weeks at a time and casual maintenance.
Re: (Score:2)
Debian isn't a desktop distribution, you got Ubuntu for that.
In a professional context Debian is a perfectly fine workstation desktop distribution. With the longer cycles and better linux support of professional hardware I've never seen big issues, except maybe using a newer kernel for a brand new model. Which is no big deal to handle in a professional context. I've seen Debian deployed on hundreds of workstations with no problem.
Even for home use I stick to Debian. Yes, the out of the box support is not as good as a recent Ubuntu. But the stock stable is usually
Re: (Score:3)
Seconded. I have been using Debian for a long time, mostly because its installation is a lot more modular than other distros and because you can find .debs pretty much anywhere. Though I have been thinking of moving to Mint on my next PC (probably Debian Edition, though). Debian stable is also great for installing on the machines of senior family members. Other than the outdated version of Firefox, they're fine. So I just install a recent version Opera or Chrome and they're good to go for a year or so (gett
Re: (Score:2)
Re: (Score:2)
You are thinking of Windows. With Linux you can expect years not weeks.
Re: (Score:2)
I still favor Debian over Ubuntu on the server. I had sOme odd problems with Apache on Ubuntu a few years ago that clearly camfrom some of the install options. Moving to Debian seemed to sort it out.
Re:Not surprising... (Score:5, Informative)
And Debian, no less. You don't pick Debian for 'new hotness'.
Ubuntu has less amd64 installs than i386: http://popcon.ubuntu.com/ [ubuntu.com]
sudo dpkg-reconfigure popularity-contest and "Yes" to join the contest (mine was disabled for some reason).
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: (Score:2)
Many distributions recommend ix86 for whatever reason.
Can someone who is experienced with binary distributions tell me whatever the binaries are still compiled to take advantage of newer processors (like more registers) and just using a least common instruction set or whatever they won't use whatever they could had used on newer processors except doing 64 bit instructions?
A lot of the "whatever reason" has been Java and Flash. Loathe them or despise them, it's hard to travel the Internet without them.
Re: (Score:3)
Stable, sure. But with testing or unstable you get a fantastic OS that does have a lot of the new hotness. I've been running testing as my business desktop in a large corporate for some years now.
Re: (Score:2)
The only Atom CPUs, intended for netbook or desktop usage, that are not 64-bit enabled are the two "original" netbook Atoms, being the N270 and N280. Ever since the Atom 230 and the Atom 330 (the only two without a letter designating their usage), all Atoms are 64-bit provided they are for netbook or desktop usage, which means their model number is prefixed with N or D.
It is true that the Atoms with model numbers prefixed with E or Z are 32-bit, but those are for embedded application (E) or "mobile interne
You should pick Debian for 'new hotness' (Score:3)
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/ [raphaelhertzog.com]
Re: (Score:2)
You don't pick Debian for 'new hotness'.
I beg to differ. Sid is very current, and unlike Ubuntu (which is forked from Sid) it is continously updated.
Disclaimer: mostly running preinstalled Ubuntu these days. Server runs Debian Testing, gradually migrating laptops and workstations from Ubuntu to Debian.
Re: (Score:2)
Also considering putting Linux on a newer system is often hit or miss in terms of compatibility.
But 64bit CPU's like the Intel Core 2 have been out past the 5 year mark. So when they re-purpose their old systems they are now 64 bit, and for those people who use Linux on new gear are getting new PC's and almost all of them are now 64bit.
I do find it funny how Windows and Linux, were not as graceful from the 32bit conversion to 64bit like Apple and Sun Microsystems. Both Apple and Sun released 64 bit and 32
Re: (Score:3)
I do find it funny how Windows and Linux, were not as graceful from the 32bit conversion to 64bit like Apple and Sun Microsystems.
I think you might not know about the alpha linux port in the mid 90s. 64 bit native kernel is not much of an issue. How the distros handle multi-arch, now that has been recently exciting.
Re: (Score:2)
I was a heavy user of linux/alpha, even still have several boxes here...
Alpha never had a multi-arch problem, it was pure 64bit from the start and not extended to 64bit later. I was also a fairly heavy Sparc user, and the state of 64bit linux/sparc support was quite poor... We had a 64bit kernel, but the userland was all 32bit and you needed a separate sparc64 compiler to build the kernel.
Re: (Score:2)
Both Apple and Sun released 64 bit and 32 bit OS's and got very little of this you cant run this 32bit app in your 64bit OS.
Um, neither did Windows. I don't think I've seen a 32-bit app that won't run on 64 bit Windows.
(Drivers are another matter...)
Re: (Score:3)
"I don't think I've seen a 32-bit app that won't run on 64 bit Windows."
I have plenty here. Old apps for programming older integration software, Car ECM programming, etc.... All fail under Windows X86. I have a old laptop with windows 2000 installed on it for using these programs.
Re: (Score:2)
Probably something to do with file permissions, lazy programmers writing files where they shouldn't. Have you tried running them in compatibility mode?
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
I haven't seen 64-bit versions of Windows (Vista and 7) having any problem running 32-bit applications. What I have noticed is that a number of older applications utilize 16-bit installers which 64-bit versions of Windows won't run, but many times those will lay down 32-bit executables and libraries that the OS handles fine.
As an aside, I run the 64-bit version of Debian at home and I haven't had any issue running 32-bit applicaitons, assuming ia32-libs is installed (Wouldn't be a bad idea to inst
Re: (Score:2)
I have a couple of installs that are 32 bit, one that has been upgraded from a 333 MHz Mobile Pentium II (Thinkpad) to a Core 2 E7400, upgraded from Potato through squeeze. Only using 3GB of RAM so I haven't gone through the motions to move it to 64 bit yet.
Re: (Score:3)
Windows has no problem running 32bit apps on 64bit hosts, although 64bit windows came years later than 64bit linux...
Drivers ofcourse are a problem on windows, a lot of older hardware has no 64bit drivers and likely never will because the manufacturers have long since abandoned the hardware.
64bit linux has no problems running 32bit binaries either, however since most applications can easily be recompiled as 64bit native, the necessary libraries required for compatibility with 32bit applications are often no
Re: (Score:2)
I built some custo routers based on Via's Cyrix CPUs (Pentium 4 equivalents) earlier this year and greatly appreciated x86 Debian. There are still a lot of 32 bit processors out there, even in newer equipment.
Re: (Score:2)
Thing is, the last x86 worth a crap was the Pentium III, and that's a bit long in the tooth these days. The power consumption was great for its day (especially the mobile edition) but today it's a voracious consumer of watts compared to any of these tiny ARM-based machines. Pentium IV machines just aren't even worth running any more. Almost everything newer is 64 bit, except Atoms. But most netbooks don't have a lot of I/O, and no PC card or ExpressCard slot, so no way to get any. Most mobile P3 laptops hav
Talking about Debian and AMD64 (Score:3)
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?
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: (Score:2)
Are you kidding? It's worked for me for ages, running Wine for several releases (just recently started getting 64 bit wine, which is annoying). Yes you get duplicates of major libraries, because the processor won't run in protected/long mode both, won't switch between them without magic, and you need application-level translation to use a 32-bit library from a 64-bit code base and vice versa.
You need application-level translation that's fully aware of the implications between 32 and 64 bit, which means
Re: (Score:2)
Yellow Dog Linux for PPC. Some of the binaries are 64 bit, some are 32. Using rpmbuild to build your own rpm's makes a ppc64 one by default, but tarball source compiles are 32-bit by default.
m68k support? (Score:2)
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...
Re: (Score:2)
m68k linux requires a PMMU so even many of the descendants of the 68000 won't run Linux, including some macs with 68040 processors because they used the 68040LC.
Re: (Score:2)
I played with m68k linux on an amiga fairly recently, and there does seem to be some active development going on...
Maybe now Canonical will finally recommend 64-bit (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Easier to tell CD-R than x86-64 from outside (Score:2)
Canonical should recommend by default that you buy CD's from them
They provide that as an option [canonical.com] on the Ubuntu Desktop landing page [ubuntu.com].
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 [ubuntu.com], thou
Re: (Score:2)
By Default?
Again, By Default?
The same way games require a DirectX 9 compatible sound card. The same way that the gas station makes sure you put the right type of fuel in their car. By requiring the user to take some responsibility for their own stuff.
The whole point of this is what Canonical offers as a default setting. If most use
Re: (Score:2)
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
Not a huge surprise. (Score:3)
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.
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.
Re: (Score:2)
Even if you are running a 32-bit OS on a machine with 4GB of RAM, you'll need to use a PAE kernel to take advantage of all the RAM. Some of the 4GB address space (usually around 400-500MB) will be reserved for things like PCI-Express so, 10% or more of your RAM is likely to be unaddressable for applications by a non-PAE kernel. This isn't an issue when you get down to 3GB or less though.
Re: (Score:2)
Estimates for performance improvements just from not having to deal with x86 range from 5 to 15%, so if you have any CPU-bound tasks you may well notice a significant difference. As well, data-shoveling tasks benefit from the increased word size.
I wonder... (Score:2)
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
Stock Price (Score:2)
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.
Not AMD specific (Score:2)
Re: (Score:3)
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.
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.
Still running 32-bit (Score:2)
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!
wintel architecture so funny (Score:2)
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....
Large File Spport (Score:2)
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.
Yeah, about that. (Score:2)
Stealing share from ARM? (Score:2)
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 d
Re:Wow! (Score:5, Informative)
Re: (Score:2)
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.
Re:Wow! (Score:5, Informative)
You should check up on PAE kernels [wikimedia.org].
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.
PAE has worked fine on Windows Server (Score:5, Informative)
Microsoft's flawed implementation (or lack of implementation) of PAE modes
PAE has worked fine on Windows Server [microsoft.com]. 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.
Re: (Score:3, Insightful)
Yeah
This is actually an example of Linus being right to push for drivers to be source code which lives in his kernel repository, not binaries you get on a CD with the product.
When Linux went 64-bit, Linux developers went through the drivers and replaced stuff that said "Yeah, I can just use any hardware address, I have 32-bit DMA" with code saying "Is this address suitable for 32-bit DMA? If not, I will use a bounce buffer like shitty ISA drivers used to". They ripped out any code that crammed hardware addr
Re: (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. R
Re: (Score:2)
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 e
Re: (Score:2)
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...
Re: (Score:2)
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.
Re:Wow! (Score:5, Informative)
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).
Re: (Score:3)
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.
Re:Wow! (Score:5, Informative)
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. [wikipedia.org])
Similar sentiment btw was shared by Linux kernel folks, but they decided (== Linus decided) in the end to use vendor-neutral 'x86-64' moniker.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
Er, generically for soda, that is. Not generically for Pepsi.
Re: (Score:2)
The midwest is generally pop. It's the south where they use coke for any soft drink
Re: (Score:2)
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 [popvssoda.com]
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
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?
Re: (Score:3)
> 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
Re: (Score:2)
It means that I can keep 32 more bit flags in a register.
Re: (Score:2)
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
Re: (Score:2)
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!
Re: (Score:2)
I still own systems that can't run 16 bit software.
Re:About time. (Score:5, Insightful)
"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.
Re: (Score:2)
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.)
Re: (Score:2)
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
Run the 16-bit applications in a real emulator (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
...run the 16-bit applications in Windows 3.1 in a real emulator such as DOSBox.
This works really well, actually. DOSBox is good enough that it seems more stable than any 486 hardware ever was. It runs my old DOS/Windows apps handily, runs on any recent Windows/Linux/OSX OS with no drama, and the source is readily available in case I ever run into something that needs some tweaking to get running. Not that I've needed to do that much; I think I made a small hack to 0.72 to get it to run something, which ended up working in 0.73 and 0.74 without modification.
Re:About time. (Score:5, Insightful)
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.
Re:first! (Score:4, Funny)
Oh dear, you must've been posting from a 32 bit Debian install.
Re: (Score:2)
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.
Re:size lies (Score:5, Informative)
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!
Re: (Score:2)
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!
Re: (Score:2)
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 sugge
Re: (Score:2)
What you really want is X32:
http://en.wikipedia.org/wiki/X32_ABI [wikipedia.org]
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.
Re: (Score:2)
Show me the numbers!
Re: (Score:2)
you may someday hit the big issue with PAE, 2G per process limit
or not.....