Recently there hasn’t been much talk about 64-bit Linux on the desktop. Most technical articles have been dated sporadically since the release of the Athlon64/Opteron CPUs in 2003. And while Linux was one of the first operating systems to take full advantage of the AMD64 and later EM64T extensions to the x86 architecture, no one has really truly adopted them for standard use because of some technology still being 32-bit only.
According to Smolt, the online hardware and configuration database used by Fedora’s distribution, approximately 20 percent of installations are 64-bit. Doing some math with Debian’s popularity-contest site, 64-bit seems to be around 15% of the total. While this is nowhere near any kind of major market share, especially within the Linux world who’s total market share for all operating systems is still less than one percent, it does mean that some people are willing to begin using it for everyday computing.
So what does 64-bit really mean? Well, firstly, and the most well-known attribute for 64-bit, is the ability of the CPU to access more RAM than its 32-bit counterpart. This is the most talked about attribute since personal computers are reaching over 4.0GB of installed RAM. Its well documented that 32-bit Windows machines can only access 3.2GB of RAM on any machine with more than that installed. By moving to 64-bit memory addressing this issue is resolved.
But, there are other benefits to 64-bit architecture that some people don’t think about. Among these is the availability of twice as many CPU registers as 32-bit hardware. This allows twice as much data to be processed without having to hit the caches or RAM. If the OS and applications know about these additional registers when compiled, the machine code will be able to take advantage of those registers. Both 64-bit general purpose and 128-bit SEE register counts were doubled.
Another big advantage of x86-64 is the inclusion of SSE and SSE2 into the core instruction set. This means that every 64-bit capable x86 processor will feature SSE and SSE2, and that compilers can make use of those extensions. Software that can take advantage of these instructions can get a large performance benefit if these instructions are used. However, the compiler needs more optimization for 64-bit software. GCC has had over a decade to optimize 32-bit compilations, its time to switch the work to optimizing 64-bit. Another solution to some software packages is coding explicitly for some of the newer instructions. Most code is written for both 32-bit and 64-bit and its up to the compiler to make the necessary optimizations. However, rewriting some of the code and splitting up function declarations for both architectures isn’t the heart of this article.
On the Linux platform, there are still some issues with software that haven’t been compiled for 64-bit. However, they are closed source applications so getting them to work for 64-bit is up to the software company. Adobe has not yet released a 64-bit version of their venerable Flash plugin, however its been said on one of Adobe’s blogs that Flash 10 may be released 64-bit. Another package is a 64-bit version of Sun’s Java interpreter. 64-bit Java is available for Windows and (surprise) Solaris, but not for Linux. It’s unsure if Sun is not offering 64-bit Linux binaries because of its Solaris operating system.
Hopefully the points discussed here will start to take shape in the Linux world. Distributions should start marketing 64-bit. Programmers should start adjusting their code for 64-bit, while not taking away from 32-bit. Software companies should provide 64-bit binaries when the source packages aren’t available.
Please Digg if you find this post interesting or informative.
EDIT: I should clarify that at least under Ubuntu Hardy Heron 64-bit, that there is no Sun Java browser plugin, even though the Sun JDK is available for 64-bit. Thank you commenters for pointing this out to me.
You state that there is no 64-bit Java for Linux, but that isn’t true. There have been 64-bit version of Java from Sun, IBM and BEA (Now Oracle) for quite some time. The only thing that is missing is none of them provide a 64-bit browser plugin.
Well, that’s where Red Hat’s Iced Tea, OpenJDK based version of Java steps in. In Fedora 9 is 64-bit Iced Tea, and it also includes a 64-bit browser plugin. Iced Tea is being adopted by other distributions as well, so you should start seeing this everywhere in the not too distant future.
Please go here:
http://java.sun.com/javase/downloads/ea/6u10/6u10rcDownload.jsp#6u10JDKs
This page has the 64 bit JDK for X86-64 platforms for Linux. See the entry entitled, “x64 RPM in self-extracting JDK file.”
I was aware of IcedTea/OpenJDK. I was not aware of a 64-bit version of Java from Sun. With that said, with no Sun Java browser plugin some websites “break” since it looks for Sun’s version signature instead of OpenJDK. I’m sure if the websites in question (I don’t have a list readily available) were to change their Java applets to be more tolerant of other versions of Java there would be less of a problem.
well i went 64bit on my AMD64 hardware a year or so ago now and have not looked back. true the flash plugin crashes every now and then (reload firefox; ugh). shame they can’t open it. PDF is open now, no? at least i think it is. it will give adobe the chance to be sure they proliferate beyond the reach of silverlight’s encroachment. and in such a scenario that would be a goodness. though who knows, something else might happen to come along. interesting things are out there: http://www.advogato.org/article/981.html
but anyway it seems that so far i have been successful lately getting the 32bit stuff to run in my amd64 install, though native x86_64 would be real nice now.
now if i had say a ppc based embedded system or workstation, or ARM, or what have you, i would be suffering a little harder as the proprietary shoppes just snub their nose at many alternate architectures. viva la open source libre!
NO!
An OS that run in 32 bits, can access memory above 4GB, with PAE extension (since P-II)
SSE already in P-III
SSE2 alredy in P-IV
Using 64 bit mode is irrelevant for this.
The most important advantage of 64 bits (from my point of view) is that a one process can use more than 4G virtual address space.
This not posible with PAE since in 32 bits, exists the 3G/1G memory split.
But 64 bit mode in x86 have a problem with PCI. PCI is a 32 bits, and access to it, need a space in memory to transfer data to it, in AMD64 can be performed with an integrated IOMMU (in really is a GART) in chip, but with intel there is no IOMMU, and fallback with a bounce buffers.
If this space is small and transfers are big and fast, this space is overflowed and data corruption is inevitable.
Hello gera,
Yes, SSE is in the P3, and SSE2 is in the P4. However, compiling for “i386″ sets you specifically to what was available on the 386 chip. With that said, SSE and SSE2 are available by default on any x86-64 CPU, so compiling for “x86-64″ or “amd64″ automatically includes SSE and SSE2.
Besides Flash and the official Java plugin from Sun, we need a 64 bit Skype and a 64 bit Google Earth too
. For pdf, I’m fine with xpdf, much faster than adobe acrobat reader.
Another thing worth noting is that ndiswrapper only works with 32bit that’s what kept me from going 64 for a while till the new b43 driver came out.
The whole debate about Java is over anyway, as there will be a GPL’d Java Runtime in the next version of your favorate Linux distribution. Evince and xpdf and k-something-or-other handle pdf’s just fine. And if you want flash just for watching video’s on Youtube, libswfdec and gnash do that already just fine.
Firefox website does not provide their 64bit version of the browser either. in Linux those are maintained by the distros your use. So lets say if I am using Slamd64 (64bit version of Slackware) and it comes with 64bit version of Firefox 2.0.14 and I want to upgrade to 3.0.1 I cannot do it unless the distro provides it for me through their download site. If Firefox provided the 64bit version directly on their site when it became available I would be able to make the switch more easily and more promptly.
One reason for the slow changeover to 64-bit might be that porting C++ code from 32-bits to 64-bits can take a bit of work.
It seems like it would be easy, but all kinds of sloppiness that worked in 32-bits (like treating ints and pointers as interchangeable) breaks when you go to 64-bit compilation.
I even spent two days tracking down a function-pointer casting problem that only occurred when we compiled the code as 64-bit, but the bug had no clear connection to 32-bit vs. 64-bit issues. (The real surprise was that the bug didn’t cause crashes in 32-bit code, not that it did crash 64-bit code.)
Any, the main point is that maybe some people are finding that porting to 64-bit compilation is just more work than they want to deal with right now.
I think you missed the Number 1 reason to switch to 64-bit computing and 64-bit Linux in particular:
http://en.wikipedia.org/wiki/Y2K38
As long as we use 32-bit machines, year 2038 will be interesting!
Artaxerxes
Linux’s 64 bit time has been since AMD Opteron came on the scene, making 64 bit releativly mainstream.
DEC Alpha 64 bit appeared 1992.
AMD64 has been around a while now & it saddens me that even Windows Vista didn’t get released 64 bit only (and reduce their software maintenance, as well as driver writers).
The AMD64 security bit function to stop execution in rogue memory areas is a great feature.
As regards i386, it’s about time i686 was the deafult, if not AMD64.
64-bit is basically still a waste of time, unless you’re going for mega-RAM, ie 4GB as the article states. I’m running 64-bit Ubuntu Hardy now, and whilst the core system is fine, there are niggles that don’t exist in the 32-bit version. Who knows if it’s faster – both versions feel the same. Of course, both versions still take *longer* to boot on my Core2 E6500 that Win3.1 used to take on my 40 MHz 386 in 1992, but that’s another story
It sure is.
I’m on Ubuntu 64bit. It handles 32bit applications and things like Flash quite seamlessly.
64 bit ndiswrapper in openSUSE 11.0 works just fine for my bcm4310 usb, using XP 64-bit driver. The b43 driver does not yet support this broadcom chip.
In the sparc64 architecture, 64bit userland is slower than 32bit userland.
Now, supposedly, x86-64 architecture fix those problems but that is not the case, in the benchmarks (phoronix.com) 32bit is faster that 64bit.
I have 64bit kernel and 32bit userland in my Q6600 rig (as Debian’s sparc64) and that is the best combination right now, well that’s only possible if you don’t need 64bit propietary kernel drivers, even that is solvable but not for the faint of heart.
Weird, I could have sworn I’ve been using a ‘64 bit linux’ – as a ‘desktop’ for about 5 years or so.
The advantage of open source is, that there is really no issue here. Software support is there. Fully.
I’m running a 64-bit Ubuntu Linux. There were absolutely no 32-bit related software problems yet.
Wine is working like a charm. Java and Flash work in Firefox and Opera (closed source, but 64 bit as well). And even the win32codecs in all media players or VirtualBox / QEMU don’t seem to mind. Every other open source package could be compiled with ease.
Ooops. Wait. I had a single issue with a small game (“Monsterz”) and a bug in the Python interpreter. But documentation was online, and the glitch easily fixed.
What I would beleive most when speaking about the 64-bit adoption is the ratio between 32 – multilib – 64 Gentoo installations. It is the only choice that is not influenced by anything other than pure user preference.
Unfortunately, I do not know how to get that number, but maybe article writers can get it through personal contacts.
Why are we stopping at Intel architectures?
128 bit architectures should be the next step, with 32 bit and 64 bit instructions, and support for standard memories beginning at 4 gigs (to 128 gigs to start).
The 128 bit architectures could have new long byte (interruptable) move instructions, so that large efficiencies can be obtained. Long byte moves that are interruptable means no cpu lockout during the move operation, and the move instruction is restartable from where it left off.
With 128bit, virtual memory management, fast address translations, string operations, and evenn much faster I/O operations could prevail.
AMD and INTEL CPUs are designed to be backwards compatible. 64bit memory for Intel and AMD was an inefficient shoe-horn in to what is essentially a 32bit architecture.
Dâniel Fraga – Just wanted to let you know that the Google Earth installer works and installs great on x64. I have been using it since Kubuntu Hardy released. Woohoo.
Why is it that so many people seem to think that it is not possible to implement 64 bit time on a 32 bit CPU or OS? Unixoid OSs running on 16 bit hardware never had any trouble dealing with 32 bit time. Nor did i ever have any problem manipulating 16 bit integers and 40 bit floats on 8 bit computers.
Denso!