Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: Linux
What you should (and shouldn't) expect from 64-bit Linux
By Nathan Willis
on
September 12, 2006 (8:00:00 AM)
Share
Print
Comments
So you just bought and assembled a brand-new AMD64 workstation. The only decision that remains is whether to install a 64-bit Linux distribution, or stick with comfortable, tried-and-true IA-32. If you are seeking an easy answer to that question, I can't help you. Running 64-bit Linux has its pros and cons. Unfortunately, a lot of the cons are out of your hands -- but they're not really Linux's fault, either.
For starters, you should know that there are essentially no proprietary applications for a 64-bit Linux desktop. Google, Adobe, iD, Skype, and the rest of the independent software vendors (ISV) who release Linux binaries of their apps by and large do so solely for 32-bit Intel architecture only.
Free software is a little trickier on a 64-bit Linux box, too. Now, I'm not talking about faulty distribution-supplied packages; the vendors that supply 64-bit versions of their distro generally live up to the words supported platform (although cutting-edge stuff like Compiz comes to i386 first).
But no one survives on distro-supplied packages alone. All of us download and install third-party applications. One of the things I enjoy most about the free software world is that every day I discover some new and interesting project.
Take a step back and consider your own system: how many locally-installed packages do you acquire over the course of one distro release cycle? For most of us, it is quite a few. If you run a 64-bit Linux system, this is going to demand additional overhead time on your part -- either maintaining a 32-bit compatibility environment, or compiling everything from source.
Whichever route you prefer, expect to run across more bugs and hang-ups than you would in a purely 32-bit environment. You are likely on a different platform than the developer, and no matter how good free software is, there is still the occasional lapse in judgment (assuming pointer sizes, for instance) that you will be the first to catch.
All the 64-bit distros have their own AMD64 forums to deal with problems unique to the platform. The second-string status of 64-bit is a big enough issue that Ubuntu even has a dedicated forum thread just for listing what applications don't work. Again, no big deal for some users, but worth a warning to others.
64 != 2*32
Limiting our discussion to distro-provided software, there are still a few myths about 64-bit computing to dispel. No, 64-bit application binaries are not twice as large as 32-bit binaries. You do not need to purchase a larger hard drive. Running processes may occupy a little more RAM due to larger pointer sizes, but far from double.
Conversely, 64-bit binaries are not twice as fast, either. You are unlikely to notice any discernible speed difference, particularly with desktop apps. Of course, one of the primary advantages of 64-bit Linux is the ability to load your system up with north of four gigabytes of RAM -- and if you do that, things will run pretty smoothly.
But the fact remains that the real performance benefits of 64-bit computing are not found in day-to-day applications. Addressing enormous chunks of memory, working with gargantuan databases -- these tasks are still primarily in the domain of servers.
For the rest of us, running a 64-bit Linux distribution is a matter of choice. We want to see what breaks, we want to try what's new, we want to work (just slightly) outside of the box. And if you are willing to live with the shortcomings described above, more power to you.
... on the other hand ...
That said, it really irritates me when I hear someone criticize "Linux" for those shortcomings. Yes, there is no Flash plugin for 64-bit Linux, and yes, Wine is a nightmare. But don't fall into the trap of blaming this misfortune on Linux. It is the individual fault of the various ISVs, not the not of the kernel developers and not of the distros.
And there is essentially nothing you can do to change this. Even the free-software-friendliest ISV is unlikely to adopt additional processor architectures to convenience a fringe constituency. Certainly being treated as a second-class citizen in this way makes 64-bit Linux less useful, but the decision behind it is not the kind that can be swayed by lobbying.
To boil it down even further: Linux runs great on 64-bit processors. The deficiency lies in the apps. Tell their developers how inconvenient it is.
Comments
on What you should (and shouldn't) expect from 64-bit LinuxNote: Comments are owned by the poster. We are not responsible for their content.
That was the conclusion I came to when I tried to install 64-bit linux on my shiny AMD-64 (with SATA) around 18 months ago. I tried numerous 64-bit distributions that had so many problems, but Gentoo worked great (aside from the expected issues such as Flash). I assume this was partially because of the source compilation that is part of normal Gentoo use. IIRC, Slackware had a 64-bit version that worked well sooner than most others, too.
They have a ton of linux applications available that just work. It is easy to add things into your environment that are "testing" as well.
Granted it compiles everything from Source, but there is something to be said about that when dealing with 64 bit.
One area that is VERY DIFFERENT in the 64 bit world is transcoding movies. It is definitely faster. I transcode mpg recordings from my Hauppage card to AVI, and get around 110 Frames Per Second.
Granted it compiles everything from Source, but there is something to be said about that when dealing with 64 bit.
One area that is VERY DIFFERENT in the 64 bit world is transcoding movies. It is definitely faster. I transcode mpg recordings from my Hauppage card to AVI, and get around 110 Frames Per Second.
One advantage the AMD64 architecture has over other 64-bit processors (say SPARC) is the ability to run 32-bit programs (without resorting to emulation). That is to say that as long as you enable the correct option in the kernel, you can run 32-bit programs written and compiled on any x86.
Now for this, you need a separate userspace, with some essentials (libc, and other things), in which to put 32-bit programs. A chrooted 32-bit userspace (with intelligent symlinks to connect with all the rest of your programs) is pretty easy to do with Gentoo (probably easy with other amd64 distros), and provides a sort of fallback for those few times when you need that proprietary, 32-bit app.
Now for this, you need a separate userspace, with some essentials (libc, and other things), in which to put 32-bit programs. A chrooted 32-bit userspace (with intelligent symlinks to connect with all the rest of your programs) is pretty easy to do with Gentoo (probably easy with other amd64 distros), and provides a sort of fallback for those few times when you need that proprietary, 32-bit app.
SuSE 10.1 has given me no grief with 64-bit. SuSE 10.1 is a mixed system 32bit, and lib64 for 64bit. It's nice having most application I use in 64bit. The only things on my system that are 32bit are Firefox, Java, Wine, and my games. Running 32bit apps in 64bit SuSE Linux is no big deal either. Most of the time I don't need to run "linux32 " only when using Loki installers for games becuase they're picky about the CPU id. What's awesome is how flawlessly 32bit, and 64bit work together, and 64bit is a real option in Linux. What are you going to do with 64bit Windows, except crash alot more. We have a real reason to buy a 64bit systems, I can't see any reason for a Windows user.
Don't be a Windows hater.
I run a Athlon 3800X2 system on Windows x64, and it is great. It runs my games and other software just fine, and it is *more* stable than 32-bit Windows XP. And until x64 popularity rises too far, I am safer from Windows OS-level root-kits as well.
There are 64-bit versions of Half-Life 2 and Far Cry. Probably others.
I don't run Win x64 because I need it. I just run it because I can.
I run a Athlon 3800X2 system on Windows x64, and it is great. It runs my games and other software just fine, and it is *more* stable than 32-bit Windows XP. And until x64 popularity rises too far, I am safer from Windows OS-level root-kits as well.
There are 64-bit versions of Half-Life 2 and Far Cry. Probably others.
I don't run Win x64 because I need it. I just run it because I can.
> One advantage the AMD64 architecture has over other 64-bit processors (say SPARC) is the ability to run 32-bit programs (without resorting to emulation).
This is incorrect. SPARC has the ability to do this just fine. In fact, I'm posting this from a mixed SPARC64/SPARC32 box. My kernel is 64-bit, and I have both 32-bit and 64-bit userlands installed. The primary userland is 32-bit, but I do have a compiler for SPARC64 along with glibc and the C++ libraries in case I ever want to compile programs heavy on double-precision floating point arithmetic.
As a matter of fact, SPARC got this ability before AMD64 was even developed. The reason mixing 32-bit and 64-bit apps works as well as it does for AMD64 is because SPARC motivated the kernel to develop support for this kind of an environment.
This is incorrect. SPARC has the ability to do this just fine. In fact, I'm posting this from a mixed SPARC64/SPARC32 box. My kernel is 64-bit, and I have both 32-bit and 64-bit userlands installed. The primary userland is 32-bit, but I do have a compiler for SPARC64 along with glibc and the C++ libraries in case I ever want to compile programs heavy on double-precision floating point arithmetic.
As a matter of fact, SPARC got this ability before AMD64 was even developed. The reason mixing 32-bit and 64-bit apps works as well as it does for AMD64 is because SPARC motivated the kernel to develop support for this kind of an environment.
The primary userland is 32-bit, but I do have a compiler for SPARC64 along with glibc and the C++ libraries in case I ever want to compile programs heavy on double-precision floating point arithmetic.
FWIW, DP FP works just fine in a 32-bit environment.
Yep, I was just about to point that out about SPARC too. The same's true on PowerPC; in fact one of the earliest inputs into the design of PPC by Apple-IBM-Motorola was that the chip be scalable to 64-bit from the off.
Very few people have more than 4 gigabyte of RAM today anyways.
And I don't care about ISV, I can run my system on free software only. I got the source, I got the power.
And I don't care about ISV, I can run my system on free software only. I got the source, I got the power.
Re:32-bits ought to be enough for anybody.
Posted by: Anonymous Coward on September 13, 2006 07:02 AM
That's true. I generally see only higher-end servers or specialized workstations with > 4GB DRAM. However, since AMD, for example, is making only AMD64 parts these days, there's nothing necessarily bad about running a 64-bit kernel, if it's easily available; I do this on my Opteron server (8GB DRAM) running RHEL.
However, the situation changes when you start talking about deploying a thin-client system like LTSP. At that point, if you can use a 64-bit kernel, then you should, so you can stuff as much DRAM in the box as you can afford. Yes, it's a server-centric architecture, but it's one that's providing 40 or more user desktops per LTSP server...at a significant cost savings, BTW.
As for the Free Software only situation, unfortunately, there are some folks at places of work who are required to run certain proprietary applications to keep their jobs and keep roofs over their heads. I am, sadly, one of these many people; in my case, it's MS Internet Exploder to access our so-called "Web-based" trouble-ticket system called Remedy Magic. No, Firefox, Opera, Konqueror, or any other browser other than IE will work; they use too much VBScript all over the place. Therefore, I need something like WINE or CrossOver Office. I do this on Kubuntu, but I still don't like my employer's eagerness toward IE dependency.
Now, at home, I don't have that restriction. Like you, I got the source, I got the power. The proprietary ISV's can therefore go kiss where the sun don't shine.
However, the situation changes when you start talking about deploying a thin-client system like LTSP. At that point, if you can use a 64-bit kernel, then you should, so you can stuff as much DRAM in the box as you can afford. Yes, it's a server-centric architecture, but it's one that's providing 40 or more user desktops per LTSP server...at a significant cost savings, BTW.
As for the Free Software only situation, unfortunately, there are some folks at places of work who are required to run certain proprietary applications to keep their jobs and keep roofs over their heads. I am, sadly, one of these many people; in my case, it's MS Internet Exploder to access our so-called "Web-based" trouble-ticket system called Remedy Magic. No, Firefox, Opera, Konqueror, or any other browser other than IE will work; they use too much VBScript all over the place. Therefore, I need something like WINE or CrossOver Office. I do this on Kubuntu, but I still don't like my employer's eagerness toward IE dependency.
Now, at home, I don't have that restriction. Like you, I got the source, I got the power. The proprietary ISV's can therefore go kiss where the sun don't shine.
Re:32-bits ought to be enough for anybody.
Posted by: Anonymous Coward on September 13, 2006 07:08 AM
Word size and address bus has little to to do with it. If you want the fastest performance from these CPUs, you need to use all of their registers. The new 64bit CPUs from AMD and Intel only access the new set of additional registers when things are compiled for 64 bit.
And 64K of RAM should be enough for everyone, right?
Actually I well remember a certain head engineer saying that 16K was enough memory for anything anyone would ever need.
Of course, that was a LONG time ago now and he has been dead for some years now.
But the principle is still the same.
Those who cannot see a reason for using new tech ALWAYS say things like this. The best response is that of Ben Franklin who, when asked of what use electricity could ever be, replied: "Madam, of what use is a new born child?"
Cheers,
Frank
Of course, that was a LONG time ago now and he has been dead for some years now.
But the principle is still the same.
Those who cannot see a reason for using new tech ALWAYS say things like this. The best response is that of Ben Franklin who, when asked of what use electricity could ever be, replied: "Madam, of what use is a new born child?"
Cheers,
Frank
Actually, the quote is "640K ought to be enough for anybody." It's OK, you're only off by a factor of 10.<nobr> <wbr></nobr>:-)
When I bought my amd64 1year and a half ago, I wondered as well if I should install a 32bit or 64bit distro. I decided to install 64bit distro for only one reason: exotism (fun gdb asm output etc.., and 64bits did sound nice back then to play with). I chose gentoo because of the wide package list, and sometimes I need to tweak some source code in some packages. I stumbled upon many problems during my journey simply because nothing is perfect. As a matter of fact, I often cursed myself for installing a 64b distro. However, I can say that after learning the answers to my problems, it's pretty similar to a 32bit system. Mainly everything can be solved by using Gentoo 32bit emulation libraries..
Oh wait, I installed a 64b system to use 32b emul in the end? Now it's starting to sound stupid, right?<nobr> <wbr></nobr>:) I'd say that having problems to overcome can be sometimes entertaining and sometimes plainly boring and frustrating, the point being to learn the arcanes of a distro.
I use extensively the "ACCEPT_KEYWORDS=~amd64 emerge" to install whatever packages I need. Some break sometimes but it's quite rare nowadays.
the 64bit nvidia drivers and glx works just fine under xorg (nvidia-kernel media-video/nvidia-glx media-video/nvidia-settings). I play enemy territory without problem (games-fps/enemy-territory).
I had some issues with wine indeed, but I tried once cedega and had battlefield working but it was a bit clumsy so i gave up on that one.
for mplayer, I use most of the time the 64 bits version (media-video/mplayer), and for proprietary codecs like quicktime etc, I just use the 32bits mplayer-bin package with win32codecs (media-video/mplayer-bin, media-libs/win32codecs,media-plugins/realvideo-co<nobr>d<wbr></nobr> ecs ).
Having no flash player for bestofgooglevideo.com or youtube is indeed a pain. I always use a 64bit compiled version of firefox (www-client/mozilla-firefox) for my everyday browsing. For flash, I simply use the 32bit emul bin package of firefox provided by www-client/mozilla-firefox-bin (/opt/firefox/firefox) coupled with the net-www/netscape-flash package. That works just fine.
Now, why do I use a 64bit and a 32bit version of firefox instead of only using the 32bit version? Because I am sure that non-exec protection (NX bit) is actually enforced for heap/stack and it's using a 64bit address space as well. It's good enough for me to avoid any firefox public exploit out there.. NX bit is more than enough anyway.
As for the 32bits emulation which I'm really satisfied with under gentoo, I installed all the
app-emulation/emul-linux-* packages (see<nobr> <wbr></nobr>/usr/portage/app-emulation/emul-linux-*). 32bit emul USE flags that I set in<nobr> <wbr></nobr>/etc/make.conf are emul-linux and emul-linux-x86.
skype (net-im/skype) works just fine using these one.
I'm using as well vmware (app-emulation/vmware-modules, app-emulation/vmware-workstation) to run windows XP, netbsd, solaris 10 operating systems.. I'm happy with it so far, never seen vmware under 32bit emul breaking whatsoever.
as for the speed, I really doubt running 64bit hardly make a noticeable experience for a desktop usage. However, some applications using 64bit optimized/asm code like john-the-ripper do gain in terms of speed. My guess is that video/audio encoding/ripping like ffmpeg/xvid/lame are also significantly faster but I never verified this using fullproof benchmarks.
The main problem with 64bit is that some applications were not portable from 32 to 64 due to bad code habit but it's getting fixed over time as package maintainer get notified of breakage.
If I need to compile a 32bit version of an external program which is not in the gentoo package list, I simple add the "-m32" flag to the CFLAGS in the Makefile. However, each libraries linked to this binary will have to be 32bits as well (emul libs).
I have no experience with ubuntu64 or any other distrib supporting 64bit but I would say that it's pretty much fairly mature under gentoo as of now. That was maybe not the case when I firstly installed it. You basically gain nothing using a 64bit system instead of a 32bit system except for the 'exotism' part of using it, and enjoying (now i'm being ironic) the ride when problems occur. Anyway everyone will eventually move to 64bits..
Hope it helps
Oh wait, I installed a 64b system to use 32b emul in the end? Now it's starting to sound stupid, right?<nobr> <wbr></nobr>:) I'd say that having problems to overcome can be sometimes entertaining and sometimes plainly boring and frustrating, the point being to learn the arcanes of a distro.
I use extensively the "ACCEPT_KEYWORDS=~amd64 emerge" to install whatever packages I need. Some break sometimes but it's quite rare nowadays.
the 64bit nvidia drivers and glx works just fine under xorg (nvidia-kernel media-video/nvidia-glx media-video/nvidia-settings). I play enemy territory without problem (games-fps/enemy-territory).
I had some issues with wine indeed, but I tried once cedega and had battlefield working but it was a bit clumsy so i gave up on that one.
for mplayer, I use most of the time the 64 bits version (media-video/mplayer), and for proprietary codecs like quicktime etc, I just use the 32bits mplayer-bin package with win32codecs (media-video/mplayer-bin, media-libs/win32codecs,media-plugins/realvideo-co<nobr>d<wbr></nobr> ecs ).
Having no flash player for bestofgooglevideo.com or youtube is indeed a pain. I always use a 64bit compiled version of firefox (www-client/mozilla-firefox) for my everyday browsing. For flash, I simply use the 32bit emul bin package of firefox provided by www-client/mozilla-firefox-bin (/opt/firefox/firefox) coupled with the net-www/netscape-flash package. That works just fine.
Now, why do I use a 64bit and a 32bit version of firefox instead of only using the 32bit version? Because I am sure that non-exec protection (NX bit) is actually enforced for heap/stack and it's using a 64bit address space as well. It's good enough for me to avoid any firefox public exploit out there.. NX bit is more than enough anyway.
As for the 32bits emulation which I'm really satisfied with under gentoo, I installed all the
app-emulation/emul-linux-* packages (see<nobr> <wbr></nobr>/usr/portage/app-emulation/emul-linux-*). 32bit emul USE flags that I set in<nobr> <wbr></nobr>/etc/make.conf are emul-linux and emul-linux-x86.
skype (net-im/skype) works just fine using these one.
I'm using as well vmware (app-emulation/vmware-modules, app-emulation/vmware-workstation) to run windows XP, netbsd, solaris 10 operating systems.. I'm happy with it so far, never seen vmware under 32bit emul breaking whatsoever.
as for the speed, I really doubt running 64bit hardly make a noticeable experience for a desktop usage. However, some applications using 64bit optimized/asm code like john-the-ripper do gain in terms of speed. My guess is that video/audio encoding/ripping like ffmpeg/xvid/lame are also significantly faster but I never verified this using fullproof benchmarks.
The main problem with 64bit is that some applications were not portable from 32 to 64 due to bad code habit but it's getting fixed over time as package maintainer get notified of breakage.
If I need to compile a 32bit version of an external program which is not in the gentoo package list, I simple add the "-m32" flag to the CFLAGS in the Makefile. However, each libraries linked to this binary will have to be 32bits as well (emul libs).
I have no experience with ubuntu64 or any other distrib supporting 64bit but I would say that it's pretty much fairly mature under gentoo as of now. That was maybe not the case when I firstly installed it. You basically gain nothing using a 64bit system instead of a 32bit system except for the 'exotism' part of using it, and enjoying (now i'm being ironic) the ride when problems occur. Anyway everyone will eventually move to 64bits..
Hope it helps
a nice paper on 32bit to 64bit application porting,
<a href="http://www-128.ibm.com/developerworks/linux/library/l-port64.html?ca=dgr-lnxwPort64" title="ibm.com">http://www-128.ibm.com/developerworks/linux/libra<nobr>r<wbr></nobr> y/l-port64.html?ca=dgr-lnxwPort64</a ibm.com>
<a href="http://www-128.ibm.com/developerworks/linux/library/l-port64.html?ca=dgr-lnxwPort64" title="ibm.com">http://www-128.ibm.com/developerworks/linux/libra<nobr>r<wbr></nobr> y/l-port64.html?ca=dgr-lnxwPort64</a ibm.com>
There is no reason why you would not want to run VMware on your system esp since it can support 64-bit host OSes. This gives you the ability to have a guest OS that runs at 32-bit and is fully sandboxed. I know this crosses over into running a server in your home, which is still new to most users who don't realize that all home computing is based around running specialized or lite-weight servers. Once you start to use VMware or other virtualization for segmenting your application usage, you will never go back. It's free and makes life much easier, esp if you ever need to "restore" your guest. Run daily backups of the files and store to CD. If your guest goes bad, pop-in the CD and you are up in running in minutes. It also allows for your machine to be very portable if you need it to be.
I have merged www-client/mozilla-firefox-bin and net-www/netscape-flash how should couple them?
if you want to use flash(32bit plugins) on 64 bit browser, use nspluginwrapper
Having no flash player for bestofgooglevideo.com or youtube is indeed a pain. I always use a 64bit compiled version of firefox (www-client/mozilla-firefox) for my everyday browsing. For flash, I simply use the 32bit emul bin package of firefox provided by www-client/mozilla-firefox-bin (/opt/firefox/firefox) coupled with the net-www/netscape-flash package. That works just fine.
LOL. I dunno peepz maybe I'm a linuX GOD but since ubuntu I can watch all movie and flash crap under linux and I didn't do a thing hahaha
GL to the compileing
BTW I've a du@l @thlon machnie and that's better than 1 proc 64bit so this whole "64 bit" thing is a fcking joke until developers are prick
LOL. I dunno peepz maybe I'm a linuX GOD but since ubuntu I can watch all movie and flash crap under linux and I didn't do a thing hahaha
GL to the compileing
BTW I've a du@l @thlon machnie and that's better than 1 proc 64bit so this whole "64 bit" thing is a fcking joke until developers are prick
Only a problem on debian (and derivatives)
Posted by: Anonymous Coward on September 13, 2006 02:09 PM
Other distributions (such as suse) you can just install all the 32bit versions of the apps you mention right on the 64bit distribution. 32bit Flashplayer works in 64bit konqueror. 32bit firefox is installed by default so works with the 32bit flash plugin. On debian based systems there is no multilib so it's another story with chroots and other such fun.
Re:Only a problem on debian (and derivatives)
Posted by: Anonymous Coward on September 13, 2006 04:45 PM
the problem with flash slowly goes away - gnash is getting improved quickly, and the flash9 is getting closer.
also the matter of binary codecs - the reason that we need 32bit mplayer in 64bit linux is also slowly going away - ffmpeg developers recently added support to decoding windows media video files which is a major step forward. the other ones are simply a matter of time.
unfortunately some proprietary software still sticks to 32bit. (opera,skype,adobe reader). maybe that's because the platform is relatively new to the developers. or they make bad code, that won't build on 64bit easily<nobr> <wbr></nobr>:]
we still need 32bit libraries for this software. but these apps are slowly decreasing in number.
the problem could be wine. i never looked how did it build under 64bit environment - as a 32bit app or 64bit? i'll probably prevent us from having pure 64bit environment, since we will be running a lot of 32bit windows apps with it.
also the matter of binary codecs - the reason that we need 32bit mplayer in 64bit linux is also slowly going away - ffmpeg developers recently added support to decoding windows media video files which is a major step forward. the other ones are simply a matter of time.
unfortunately some proprietary software still sticks to 32bit. (opera,skype,adobe reader). maybe that's because the platform is relatively new to the developers. or they make bad code, that won't build on 64bit easily<nobr> <wbr></nobr>:]
we still need 32bit libraries for this software. but these apps are slowly decreasing in number.
the problem could be wine. i never looked how did it build under 64bit environment - as a 32bit app or 64bit? i'll probably prevent us from having pure 64bit environment, since we will be running a lot of 32bit windows apps with it.
Re:Only a problem on debian (and derivatives)
Posted by: Anonymous Coward on September 15, 2006 11:52 AM
Fortunately, I don't need Opera, Skype, or Adobe Reader. Instead, we have the following:
Opera --> Firefox or Konqueror
Skype --> Any multitude of Free Software SIP clients
Adobe Reader --> XPDF, KPDF, GPDF, and several others
Since we have the source, we can compile them in 64-bit mode.
Opera --> Firefox or Konqueror
Skype --> Any multitude of Free Software SIP clients
Adobe Reader --> XPDF, KPDF, GPDF, and several others
Since we have the source, we can compile them in 64-bit mode.
On debian based systems there is no multilib so it's another story with chroots and other such fun.
Oh, right. So the ia32-libs package is just another useless Debian package... You shouldn't bash a group of distro's unless you know what you are talking about.
Oh, right. So the ia32-libs package is just another useless Debian package... You shouldn't bash a group of distro's unless you know what you are talking about.
In different scientific apps i found an increase in number crunching performance with 80% more.I would expect from all data mangling apps (multimedia) an increase in efficiency (better performance or lower cpu used)
Okay - so Linux (64bit) may have shortcomings, but is using 64bit Windows really any better yet?
Actually, yes, it is. This assumes you don't view lack of drivers as a problem, but you're running Linux so I guess you came to terms with this a while ago.
expect to run across more bugs and hang-ups
Posted by: Anonymous Coward on September 14, 2006 03:04 AM
"expect to run across more bugs and hang-ups"
This is stupid. There's no other word that'd better fit.
You want to use 64bit Linux ? Don't get me wrong for this line, but: just do it ! And I mean it. I've been using 64bit ~amd64 Gentoo for 8 months now, no hangups, definitely not more bugs than in 32bit (so few I'd really have to think hard to recall some), and it's really nothing you can't do.
And no, do not expect more bugs and hangups. Expect to do your part (educate yourself and do know what you're doing) and get a good system in the end.
This is stupid. There's no other word that'd better fit.
You want to use 64bit Linux ? Don't get me wrong for this line, but: just do it ! And I mean it. I've been using 64bit ~amd64 Gentoo for 8 months now, no hangups, definitely not more bugs than in 32bit (so few I'd really have to think hard to recall some), and it's really nothing you can't do.
And no, do not expect more bugs and hangups. Expect to do your part (educate yourself and do know what you're doing) and get a good system in the end.
Running amd64 gentoo for over 2 years here. Two thumbs up - Wayyy up. And to the posters who say "not much difference", y'all are uhm, well NUTS. 64bit is WAY faster, across the board; screw conditional benchmarks, how does it FEEL? Feels fast as hell. Just do it and quit the whining. Ya think 64 is faster? Maybe? Hmmmmmm...GUH!!
Another silly article on the web! Who knew?
Another silly article on the web! Who knew?
"But no one survives on distro-supplied packages alone. All of us download and install third-party applications. [...] how many locally-installed packages do you acquire over the course of one distro release cycle?"
Hmmmm....I've done pretty well with Debian for the last 3 years. I don't think I've needed to go outside the main repository more than a couple of times, and every time I have done so, I've pretty much had to build from source anyway. So, no change there then.
"no matter how good free software is, there is still the occasional lapse in judgment (assuming pointer sizes, for instance) that you will be the first to catch."
OK, that is somewhat valid. But I've found that that sort of thing is generally only from immature software that has other bugs in it anyway. *shrug*
"Of course, one of the primary advantages of 64-bit Linux is the ability to load your system up with north of four gigabytes of RAM"
Ummm...you can do that with x86-32 - that's what PAE[0] is for. Yes, individual apps can only access 4GB each (and only 3GB userspace), but you can fit more than one of them, fully loaded, in physical memory at once on such a system.
"That said, it really irritates me when I hear someone criticize "Linux" for those shortcomings. Yes, there is no Flash plugin for 64-bit Linux, and yes, Wine is a nightmare. But don't fall into the trap of blaming this misfortune on Linux. It is the individual fault of the various ISVs, not the not of the kernel developers and not of the distros."
Tell it brother! I think that people should be barred from saying they "support Linux" when they mean Linux/x86-32. Linux is well-supported on at least 11 architectures[1], and runs on a hell of a lot more than that. IMO, if your software does not run on at least half of the well-supported arches, it does not count as "supporting Linux". If you support "Linux/x86-32" - fine. But *say so*.
[0] <a href="http://en.wikipedia.org/wiki/Physical_Address_Extension" title="wikipedia.org">http://en.wikipedia.org/wiki/Physical_Address_Ext<nobr>e<wbr></nobr> nsion</a wikipedia.org>
[1] <a href="http://www.debian.org/releases/sarge/" title="debian.org">http://www.debian.org/releases/sarge/</a debian.org>
Hmmmm....I've done pretty well with Debian for the last 3 years. I don't think I've needed to go outside the main repository more than a couple of times, and every time I have done so, I've pretty much had to build from source anyway. So, no change there then.
"no matter how good free software is, there is still the occasional lapse in judgment (assuming pointer sizes, for instance) that you will be the first to catch."
OK, that is somewhat valid. But I've found that that sort of thing is generally only from immature software that has other bugs in it anyway. *shrug*
"Of course, one of the primary advantages of 64-bit Linux is the ability to load your system up with north of four gigabytes of RAM"
Ummm...you can do that with x86-32 - that's what PAE[0] is for. Yes, individual apps can only access 4GB each (and only 3GB userspace), but you can fit more than one of them, fully loaded, in physical memory at once on such a system.
"That said, it really irritates me when I hear someone criticize "Linux" for those shortcomings. Yes, there is no Flash plugin for 64-bit Linux, and yes, Wine is a nightmare. But don't fall into the trap of blaming this misfortune on Linux. It is the individual fault of the various ISVs, not the not of the kernel developers and not of the distros."
Tell it brother! I think that people should be barred from saying they "support Linux" when they mean Linux/x86-32. Linux is well-supported on at least 11 architectures[1], and runs on a hell of a lot more than that. IMO, if your software does not run on at least half of the well-supported arches, it does not count as "supporting Linux". If you support "Linux/x86-32" - fine. But *say so*.
[0] <a href="http://en.wikipedia.org/wiki/Physical_Address_Extension" title="wikipedia.org">http://en.wikipedia.org/wiki/Physical_Address_Ext<nobr>e<wbr></nobr> nsion</a wikipedia.org>
[1] <a href="http://www.debian.org/releases/sarge/" title="debian.org">http://www.debian.org/releases/sarge/</a debian.org>
Running on 64 bits HAS a definite advantage: getting rid of IA32's Achille's heel: lack of registers who in addition to its direct effect also makes life difficult for compilers (several optimizatiopn algorithms don't work that well on register starved machines like IA32).
On a XEON running RHEL 4 I got 50% improvement on a pure CPU benchmark when I reinstalled with the 64 bit version. Caveats: That was really pure CPU, the entire benchmark fitted in cache. In real world applications who do I/O and who access memory the improvements would have been lesser. Also FP intensive get some improvement (from janitorial operations like saving pointers on the stack) but far less than 50%
However with Gcc progressikng and thus becoming more accurate for the quirks of Xeons/Athlons in 64 bit mode I expect the gap increases.
On a XEON running RHEL 4 I got 50% improvement on a pure CPU benchmark when I reinstalled with the 64 bit version. Caveats: That was really pure CPU, the entire benchmark fitted in cache. In real world applications who do I/O and who access memory the improvements would have been lesser. Also FP intensive get some improvement (from janitorial operations like saving pointers on the stack) but far less than 50%
However with Gcc progressikng and thus becoming more accurate for the quirks of Xeons/Athlons in 64 bit mode I expect the gap increases.
"...and yes, Wine is a nightmare."
I'm not sure where this comes from since throughout most of the last year, I ran Cedega on Gentoo without issue. That said, in May my subscription ran out. After running 32-bit Ubuntu for about a month before switching back to 64-bit Gentoo.
Anyway, the last 3 releases of Wine have compiled and run fine on 64-bit Gentoo. I have already logged many hours of StarCraft and Diablo 2. As a bonus, all my apps from <a href="http://portableapps.com/" title="portableapps.com">http://portableapps.com/</a portableapps.com> run nearly perfect!
Also, try copying 20GB of data betweeen drives on an amd64 using a 32-bit OS, and a 64-bit OS. In my experience the 64-bit OS blows away the 32-bit OS in situations like these.
I'm not sure where this comes from since throughout most of the last year, I ran Cedega on Gentoo without issue. That said, in May my subscription ran out. After running 32-bit Ubuntu for about a month before switching back to 64-bit Gentoo.
Anyway, the last 3 releases of Wine have compiled and run fine on 64-bit Gentoo. I have already logged many hours of StarCraft and Diablo 2. As a bonus, all my apps from <a href="http://portableapps.com/" title="portableapps.com">http://portableapps.com/</a portableapps.com> run nearly perfect!
Also, try copying 20GB of data betweeen drives on an amd64 using a 32-bit OS, and a 64-bit OS. In my experience the 64-bit OS blows away the 32-bit OS in situations like these.
I've installed the 64-bit version of Fedora Core ever since it supported the platform and it does quite a clever job of automatically installing 32-bit libraries (in<nobr> <wbr></nobr>/lib) in addition to 64-bit ones (/lib64). It can then install mostly 64-bit apps, but switch to 32-bit apps if there is no 64-bit version yet (e.g. OpenOffice.org).
The "yum" updater also knows about the two architectures, though I find it confusing when you do "rpm -qa | grep lib | sort" and end up with two copies (32-bit and 64-bit) of a lot of libraries and no indication of the bitness of the libraries!
One sticking point is actually Firefox because if you want to use a third-party 32-bit plug-in (64-bit plug-ins from third parties are virtually non-existent<nobr> <wbr></nobr>:-( ) such as Flash, you actually have to hunt around for 32-bit Firefox because Fedora installs the 64-bit one by default.
The "yum" updater also knows about the two architectures, though I find it confusing when you do "rpm -qa | grep lib | sort" and end up with two copies (32-bit and 64-bit) of a lot of libraries and no indication of the bitness of the libraries!
One sticking point is actually Firefox because if you want to use a third-party 32-bit plug-in (64-bit plug-ins from third parties are virtually non-existent<nobr> <wbr></nobr>:-( ) such as Flash, you actually have to hunt around for 32-bit Firefox because Fedora installs the 64-bit one by default.
Well, don't use Flash then. I don't, and I don't miss it a bit. Same for Adobe Acrobat Reader; XPDF is, I have found, a _mighty fine_ PDF reader and works very well from within Web browsers.
Remember, folks, that nobody *needs*<nobr> <wbr></nobr>.WMV's,<nobr> <wbr></nobr>.SWF's,<nobr> <wbr></nobr>.MOV's, and so on. You don't *need* these things. On the other hand, encourage your ISV's to start supporting Ogg Theora/Vorbis and non-proprietary formats that we Free Software users can legally and easily use. The only reason that I tolerate<nobr> <wbr></nobr>.DOC's at home is because Free Software, namely OpenOffice.org, can handle them well, otherwise I wouldn't tolerate them. The workplace is, of course, a different story; they mandate the use of MS Windows/Office at my workplace. But that's work. What we do at home, on our own PCs, is up to us.
Remember, folks, that nobody *needs*<nobr> <wbr></nobr>.WMV's,<nobr> <wbr></nobr>.SWF's,<nobr> <wbr></nobr>.MOV's, and so on. You don't *need* these things. On the other hand, encourage your ISV's to start supporting Ogg Theora/Vorbis and non-proprietary formats that we Free Software users can legally and easily use. The only reason that I tolerate<nobr> <wbr></nobr>.DOC's at home is because Free Software, namely OpenOffice.org, can handle them well, otherwise I wouldn't tolerate them. The workplace is, of course, a different story; they mandate the use of MS Windows/Office at my workplace. But that's work. What we do at home, on our own PCs, is up to us.
gentoo linux works perfect on an amd64 machine. a big thanx to gentoo team. distro really makes a difference. Shame on macromedia developers.. perhaps they should get some courses on programming..<nobr> <wbr></nobr>;)
4GB per process has been available for a while.
Posted by: Anonymous Coward on October 19, 2006 08:12 AM
The RHEL kernels (hugemem and the like) have been able to address 4GB per process for some time, thanks to using PAE on Pentium 4 systems and the 4G/4G split.
Perhaps you mean larger "total" memory per system.
I had a larger discussion here, but it would fall on deaf ears.
Perhaps you mean larger "total" memory per system.
I had a larger discussion here, but it would fall on deaf ears.
What you should (and shouldn't) expect from 64-bit Linux
Posted by: Anonymous [ip: 125.60.240.200] on October 27, 2007 09:26 AM
The new ubuntu 7.10 64 bit can be installed with wine and flashplayer without sweat... but the wine can only process the version of windows2000 not the windows xp.In my opinion, ubuntu is one of the best linux as of now... im new to linux, and but im not an IT.
Comment
Posted by: Anonymous Coward on September 13, 2006 01:32 AM#