Junior Member
I've been using Linux since 2006 and started with x86_64 Ubuntu before moving to Arch x86_64. I've never used a 32 bit version of Linux. Flash was a bit fiddly early on but not for a long time now and has certainly never made Firefox unstable for me.
I'd consider myself an "average" user and 64 bit was the obvious choice even back in 2006, as things like ripping MP3s is a lot faster. Seems like a no-brainer to me. And I never ran out of memory with 1 GB either (using 8 these days).
Canonical
I've got some data from some 32 bit vs 32 bit pae vs 64 bit:Originally Posted by Wildfire
http://zinc.canonical.com/~cking/pow.../results-1.txt
http://zinc.canonical.com/~cking/pow.../results-2.txt
http://zinc.canonical.com/~cking/pow...-3/results.txt
It really depends on the kind of processor, size of memory and usecase, so you're milage may vary.
Junior Member
I like it. From having been very bleeding-edge and experimental anno ~2007, 64-bit support is shaping up nicely and can only become better as stuff becomes optimized for it. Some of the tasks I use my computer for are *definitely* CPU intensive, including video encoding.
Is there a base difference in wattage between 32-bit and 64-bit? Theoretically the faster a CPU can finish a task the sooner it may enter a lower C-state. I'd love to see these benchmarks redone while also recording power draw.
I don't really have any compelling arguments to not go 64-bit, so whenever possible I do. Few things I need only come in 32-bit flavors, and what does can often be executed anyway.
That said, one exception I've come across was the closed source driver for the Canon P-150 document scanner.
Said token driver only comes in 32-bit builds and is not being maintained. That's just bad and borderline lying, Canon. Looks good on paper, though!Multi-platform compatibility
The P-150 offers compatibility on Mac systems with an included Mac TWAIN driver and CaptureOnTouch software for Mac. Also a SANE compliant Linux driver is available for organisations preferring to develop with open architecture. This driver can be downloaded from Canon’s software support site.
It turns out 64-bit sane-utils doesn't have the backwards compatibility needed to speak with 32-bit drivers -- but I extracted the 32-bit deb and used the scanimage binary therein instead. Granted, the workaround fails the ordinary-Joe test, but the blame is solely on Canon.
(If you work for them, please send a harsh mail to the driver department; the rest of us just get stuck in "customer support", where we're kindly told you never explicitly said you supported 64-bit linux. It's like claiming your hotel has a shower in every bathroom, when in reality it's just a tap on the wall at breast height. Cold water tap. Also it hasn't been cleaned since being built in 2010. But you could totally "shower" there!)
Junior Member
If you manage without it, then cheers; all the better. I don't like the idea of Flash but I can't do without it yet.
As my own anecdote I haven't had to kill a soaring 100% CPU Flash process for months now, literally. Flash crashing is even rarer.
That's with Chromium though; separately killing plugins is easy via its task manager, and a crashing plugin just shows me a sad face where the plugin was. Browser crashes happen but I can usually blame that on me running a development build (from the chromium-daily ppa).
Phoronix Member
I can agree with that, but I think personal preferences are beside the point here. The original question was whether 64 bit has any advantages for the average user (something the benchmark doesn't cover). So far 64 bit had disadvantages(*), which is probably why Canonical didn't recommend it. Now that 64 bit works reasonably well for anyone they're making it the default. But does it actually bring some benefits for non cpu intensive tasks? Being able to use more memory is definitely a plus, but in the case of Firefox throwing more RAM at it sounds more like a cure to the problem than the actual cause.
*) I would count no access to Flash as a disadvantage, because in this case you don't have a choice about using it or not. Now that it's available you can configure it whichever way you want. You don't use it, it's a possible security issue, but the average user won't care and will complain if it's missing.
I guess it depends on whether you're cpu constrained or memory constrained. If you're memory constrained switching to 64 bit might actually make things worse, because programms will typically use more memory (so you'll run out of memory sooner). If you're cpu bound 64 bit might be beneficial (as the benchmark shows).
Last edited by Wildfire; 02-28-2012 at 05:58 AM.
Senior Member
Well, 64-bit applications will use more ram due to address references being 64-bit as opposed to 32-bit but it should hardly amount to 'twice as much' unless the code in question is nothing but address references (which of course it's not). I've seen some statement that 64-bit code is typically ~15-20% larger than the equivalent 32-bit code which seems to ring true with the numbers on my systems.
Senior Member
IMO, if your PC supports 64 bit at all, you should be using 64 bit. It is way faster in just about every multimedia application, Flash issues are absolute history (you could have just ran the 32 bit edition when they didn't have 64 bit flash,) better disk performance, for the most part drivers are a non-issue, etc. We should have moved over to 64 bit as the default with 64 bit PCs back in '06. When people say you should only use 64 bit when you have 4 gigs or more of RAM, they really don't know WTF they are talking about. Also mind you, on Linux in general, 99% of packages are compiled for 64 bit so many more packages get a speed up unlike 64 bit Windows which for the most part runs 32 bit applications.
Senior Member
There are real gains for everyday use as well. For instance, file decompression is a task that you have to do often, and IIRC there are sizeable gains there as well.
Yes, 64-bit applications do use more memory; however, that usually isn't much of an issue. The issue is only if you have a slow disk - it will take longer to load the application. Otherwise, RAM is fast enough for the size increase not to be an issue at all. And don't forget that free RAM is wasted RAM - you need to have it filled up as much as possible anyway (same with disk space - copy-on-write file systems show that very clearly). You can precache a few less apps in RAM when using 64-bit, but that won't be much of an issue, either, since with current amounts of RAM most of it is going to waste anyway.
Oh, and another reason to stick with 64-bit is that there already are 64-bit-only apps (in fact, Creative X-Fi beta drivers come to mind), not to mention that since most people code on 64-bit machines to save time needed for compilation, they also test their programs on 64-bit machines as well, so it's a better supported platform right now.
Last edited by GreatEmerald; 02-28-2012 at 11:42 AM.
Senior Member
i'm surprised how many people here are not very supportive of 64 bit when linux is pretty much the absolute best x86-64 compatible OS.
64 bit is more memory consuming, but not nearly as much as people are acting like it does. Note that in Windows, 64 bit is VERY memory consuming because windows basically runs 2 of everything - a 32 bit compatibility layer and then the normal 64 bit processes. since 64 bit addresses twice as much memory per instruction, all 32 bit programs end up taking up twice as much memory, whereas 64 bit programs often don't take up any extra at all. in linux, you don't need to worry about that because pretty much everything is compiled for 64 bit.
64 bit linux is pretty much just as compatible as 32 bit, assuming you have at least 1gb, the memory differences are insignificant, and you get noticeably more performance.
Junior Member
64 bit kernel, 32 bit userspace
I'd be curious to see benchmarks of a 64 bit kernel with a 32 bit userspace. I've been doing this quite a while on a few boxes with smaller amounts of RAM. And it seems to go fine.
Posting Permissions
Reply With Quote