Weekly Edition
Return to the Press pageSponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
(Log in to post comments)
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 12, 2006 22:42 UTC (Tue) by xorbe (guest, #3165) [Link]
Why does the link go to another summary site which links to the real article at Linux.com?
Direct link:
http://www.linux.com/article.pl?sid=06/09/07/1632253
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 1:59 UTC (Wed) by richo123 (guest, #24309) [Link]
Hmmm I have read now in several places (including this) that you will notice little difference in desktop application speed with 64 bit versions of Linux distros.
I beg to differ. I have a dual em64t intel rig and I compared directly a 686 32 bit Ubuntu install with a amd64-xeon 64bit install. The difference was VERY MUCH noticeable to the extent that I am prepared to bear the disadvantage of codecs and flash. Actually there is a 32 bit version of firefox from the Ubuntu forum which even allows this without too much trouble. The difference in responsiveness of the gnome desktop is remarkable and I am at a bit of a loss to understand these recycled comments on how there is little difference in speed.
I use this machine as my main desktop and have noticed very few irritations....
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 3:06 UTC (Wed) by k8to (subscriber, #15413) [Link]
I was under the impression that typical demanding apps would see around20% advantage when built for amd64.
This should venture into user-noticable territory, if not obvious in some
cases.
well it's half-baked 64-bit system ;-P
Posted Sep 13, 2006 5:43 UTC (Wed) by gvy (guest, #11981) [Link]
> The difference in responsiveness of the gnome desktop is remarkableIt's just plain horrible, considering the bogomips. Well, even if xeons suck on context switches, the more so as the clock gets higher since something was real time-based there... (intel em64t chipsets suck too, try getting proper i/o with e.g. 3ware 9xxx and 4+Gb RAM, you'll get (sw)iotlb surprize -- which can result in filesystem corruption; this is done in hardware in AMD64 CPUs and seemingly isn't done yet in intel *server* chipsets)
well it's half-baked 64-bit system ;-P
Posted Sep 13, 2006 12:45 UTC (Wed) by richo123 (guest, #24309) [Link]
The bogomips between an intel x86 3.4Ghz regular processor and the x86_64 xeon em64t processors (cache sizes the same) are actually identical (6800). The difference in responsiveness of gnome between the two is stark. Published benchmarks (Tom's Hardware) show the em64t and amd64 to have advantages in different areas.
Why 64 bit?
Posted Sep 13, 2006 4:34 UTC (Wed) by TwoTimeGrime (guest, #11688) [Link]
What practical advantage does 64 bit have over regular computers other than the ability to address more RAM?
Why 64 bit?
Posted Sep 13, 2006 4:45 UTC (Wed) by shemminger (subscriber, #5739) [Link]
x86-64 code has more registers available so it is faster.
64 bit allows addressing >4 gigabyte of memory without doing the PAE hack.
Why 64 bit?
Posted Sep 13, 2006 15:02 UTC (Wed) by chill633 (guest, #16013) [Link]
64-bit is faster just because it has more registers? Not quite.
My one serious test w/64-bit involved benchmarking Slackware 10.2 w/2.6 kernel against Slamd64 w/2.6 kernel. The one thing I was interested in was converting DVDs to Xvid (MPEG-4) using vobcopy and transcode.
The 32-bit Slackware version was 40-50% faster than the identical Slamd64 setup. By "identical" I mean the same computer (dual-boot), same DVD, same software installed (well, 32-bit in one case, 64-bit in the other).
I never could figure it out. Vobcopy was identical in speed, down to the second. Transcode, however, was a dog using the Slamd64 version.
My next test is going to be Gentoo, when I have some time.
Charles
Why 64 bit?
Posted Sep 13, 2006 15:29 UTC (Wed) by ewan (subscriber, #5533) [Link]
I believe that transcode has some handwritten assembler for some of itsheavy numerical loops that's only used on supported x86-32 processors;
everything else, including both non x86 and x86-64 uses the equivalent
portable versions written in C.
Why 64 bit?
Posted Sep 13, 2006 15:33 UTC (Wed) by khim (subscriber, #9252) [Link]
Gosh. You've compared hand-optimized 32bit assembler code and generic 64bit code without SIMD commands. You found VERY surprising that optimized code which uses SIMD commands are faster then non-optimized code. Why ? Have you EVER seen situation where generic code is faster then hand-optimized code with SIMD instructions ?
Hint: if you are comparing DIFFERENT programs (and make no mistake: 32bit transcode and 64bit transoce are totally different beasts) all bets are off. Gentoo will not help there...
P.S. AFAIK 64bit SIMD implementation is in the works and there are something in CVS but it's not enabled in any builds right now...
Why 64 bit?
Posted Sep 13, 2006 4:54 UTC (Wed) by bryanr (guest, #25324) [Link]
- AMD64 has more registers than IA32 -- resulting in fewer spills to memory (load/store ops)
- The wider registers mean fewer cycles are used during memcpy and
related operations (the CPU can load/store 64 bits of data per ins
instead of 32)
- Modern CPU instructions are always enabled on AMD64. Many "i686"
distros have gcc schedule code for an i686 pipeline, yet only emit
instructions present since i486 (penalizing new hardware to ensure
compatability with old)
Why 64 bit?
Posted Sep 13, 2006 17:53 UTC (Wed) by raven667 (subscriber, #5198) [Link]
> Modern CPU instructions are always enabled on AMD64. Many "i686"> distros have gcc schedule code for an i686 pipeline, yet only emit
> instructions present since i486 (penalizing new hardware to ensure
> compatability with old)
I don't believe that to be accurate. I'm pretty sure that the the acutal object code does runtime cpu
detection and has seperate optimized code paths for i386/486/586/686/etc. so there should be no
difference when using -march=i386 and -mcpu=i686.
Why 64 bit?
Posted Sep 13, 2006 20:41 UTC (Wed) by nix (subscriber, #2304) [Link]
Doesn't that depend on the software?
(Some builds of speed-critical stuff like OpenSSL use the CPU hwcaps and
the per-hwcap library feature of glibc to produce builds optimized for
appropriate processors: look for e.g. /usr/lib/i686 or /usr/lib/v9...)
Why 64 bit?
Posted Sep 14, 2006 2:42 UTC (Thu) by raven667 (subscriber, #5198) [Link]
> Doesn't that depend on the software?
I don't believe so, what I understand is that if you use both -march and -mcpu gcc will put in
optimized code paths seperate for each. There will be a fallback for i386 but optimized code for
i686. The binary will obviously be larger as it may contain multiple implementations of the same
code.
At least that's how I understand how it works, but I can't find a find a reference quickly. Maybe
someone more knowledgable than I can comment?
Why 64 bit?
Posted Sep 14, 2006 6:47 UTC (Thu) by khim (subscriber, #9252) [Link]
When everything else fails, RTFM.
And here we go:
-mtune=cpu-type: Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions.
-march=cpu-type: Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type.
-mcpu=cpu-type: A deprecated synonym for -mtune.
Nothing like "separate code path", "fallback for i386" and other such nonsense. If you are specifying "-mcpu=i386 -mtune=i686" it just means: "try to optimize for i686, but don't use anything except i386 instructions". Quite sad, really: C++ code expirience can slowdown up to 30-40% with such options but usually just 5-10%.
Autoselection can be done (kernel does it in some configuration, OpenSSL does it, GLibC does it, some other programs are doing it - but that's up to application developer, compiler will not help you there... Where have you got ridiculous idea that it's task for the compiler - I do not know...
Why 64 bit?
Posted Sep 14, 2006 18:57 UTC (Thu) by nix (subscriber, #2304) [Link]
OpenSSL doesn't do it, as far as I know (it can't; many critical-paththings are macro-expanded). Instead, distributors use glibc's hwcap
mechanism to select appropriately-compiled OpenSSL libraries for the
hardware at dynamic link time. (This is especially useful on e.g. SPARC,
because of SPARCv7's lack of integer multiply instructions.)
Why 64 bit?
Posted Sep 13, 2006 21:16 UTC (Wed) by dberkholz (subscriber, #23346) [Link]
Only in code specifically written to do so, e.g. Mesa.
Why 64 bit?
Posted Sep 13, 2006 9:03 UTC (Wed) by jfj (guest, #37917) [Link]
Unless you are using "long long" operations or more than 4GB of memory per process, none. Oh, I forgot, it eats your cache memory so you are using 1/2 of it compared to 32 bits.
Why 64 bit?
Posted Sep 13, 2006 9:11 UTC (Wed) by nix (subscriber, #2304) [Link]
Congratulations on being the only commenter not to assume that '64-bit' means 'x86-64' :)
Why 64 bit?
Posted Sep 13, 2006 15:36 UTC (Wed) by khim (subscriber, #9252) [Link]
Ummm... What OTHER 64-bit architecture is available for "brand-new AMD64 workstation" ?
Why 64 bit?
Posted Sep 13, 2006 20:42 UTC (Wed) by nix (subscriber, #2304) [Link]
Er. Um. True. I forgot the actual *content* of the article.
I'll go away now.
Why 64 bit?
Posted Sep 13, 2006 15:34 UTC (Wed) by charris (subscriber, #13263) [Link]
I haven't noticed much difference on the desktop, but for certain numerical things there can be significant differences. For instance, the random number generator MWC8222 relies on multiplying two 32 bit integers with a 64 bit result and runs about twice as fast on amd64. Oddly enough, that advantage disappeared on the emt64 xeon machine I tried it on, so go figure.
By and large I am favoring 32 bits for the short term just because of the codecs and such. When those things eventually mature, and with MS in the 64 bit desktop market they will, I will switch over for good.
Chuck
Why 64 bit?
Posted Sep 13, 2006 17:29 UTC (Wed) by zlynx (subscriber, #2285) [Link]
Now, this may not be factual, but I have read that Intel cheated a bit with EMT-64 instructions.
What they apparently do is run 64-bit operations through their existing 32-bit ALU, and because their P4 architecture has a double-clocked ALU, this isn't so bad. What it does mean though, is that you've just exchanged the instructions a 32-bit compiler generates for 64-bit ops with CPU microcode doing the same thing.
Why 64 bit?
Posted Sep 14, 2006 6:57 UTC (Thu) by khim (subscriber, #9252) [Link]
It's not the same thing. 64-bit instructions were discowered in the photo of Prescott CPU two years before Intel said that he'll support EM64T! How ? On the photo you can find TWO 32bit ALUs! One is used for 32bit, another one - for high half of the 64bit (it's smaller, it's registers don't have tags so can not be used separately, etc). It means that while it's slower then AMD64 it's still faster then what the compiler does - because the compiler can only use first ALU!
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 5:14 UTC (Wed) by zooko (subscriber, #2589) [Link]
Using the 64 bit architecture came in handy when doing some scientific programming for my wife. We needed to deal with information which was somewhere around 48 bits per item. The 64-bit compile (port) of Judy Tree would handily store those items for us. To use the 32-bit version of Judy Tree we would have to store them elsewhere and put pointers to them into the Judy Tree.
Unfortunately, my wife valued portability so much that we did the latter. :-)
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 9:12 UTC (Wed) by nix (subscriber, #2304) [Link]
I'm more impressed that you could remember what those awfully-named accessor macros did for long enough to use them. (Or did you do as I did and rename them to something better?)
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 9:25 UTC (Wed) by zooko (subscriber, #2589) [Link]
I just kept the man page in another window nearby.
Renaming them might have been worth it, though.
I was really happy with judy's performance. I look forward to using it again. Somebody should write a Python wrapper...
--Z
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 11:11 UTC (Wed) by amk (subscriber, #19) [Link]
Andrew Dalke has written PyJudy.
Py* Dalke?
Posted Sep 13, 2006 12:02 UTC (Wed) by gvy (guest, #11981) [Link]
Hm, the same Dalke who wrapped daylight.com API?
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 14:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Oh yes, from functionality, performance, and documentation POVs Judy is amazing. :)
just use double?
Posted Sep 14, 2006 1:39 UTC (Thu) by stevenj (subscriber, #421) [Link]
Um, for 48 bits per item you could just use 64-bit double precision, which is portable (now that everyone uses IEEE 754) and has 52 bits in its significand (i.e it can represent 52-bit integers exactly).
just use double?
Posted Sep 21, 2006 11:44 UTC (Thu) by renox (guest, #23785) [Link]
Integer<->float convertion can be quite expensive, so I'm not sure using double is that interesting.
Gone back to 32-bit
Posted Sep 13, 2006 8:55 UTC (Wed) by alspnost (subscriber, #2763) [Link]
I ran an AMD64 system for a year or so, and very nice it was. But it *was* indeed more hassle as well, and I've now gone back to 32-bit again. Well, I had to as my new machine is a laptop with a Core Duo chip, so no 64-bit support!Overall, during the benchmarks I ran with the 64-bit machine, I honestly found almost zero discernable difference betwee 64/32-bit. There were some exceptions - for a good example, try the OpenSSL crypto benchmarks, which speed up by 3x in 64-bit mode - but nothing that really made a real-life difference. It kind of felt "cool" to be running 64-bit though.
But I've not found any disadvantages in going back to 32-bit. What makes a hell of a difference is dual core - now *that* is seriously worth having, and makes me enjoy my dual 32-bit system much more than my single 64-bit one. Two 32s really do equal more than 64 after all :-)
Gone back to 32-bit
Posted Sep 13, 2006 9:15 UTC (Wed) by nix (subscriber, #2304) [Link]
Emacs and XEmacs have visible improvements in 64-bit mode: larger buffers and the ability to deal with integers above 2^28 (or 2^30 in XEmacs).
Long-term security
Posted Sep 13, 2006 11:59 UTC (Wed) by dark (subscriber, #8483) [Link]
64-bit systems will continue to work in 2038. It's best to be prepared.
Long-term security
Posted Sep 13, 2006 12:29 UTC (Wed) by clugstj (subscriber, #4020) [Link]
Well, so will 32-bit systems. We just have to "typedef long long time_t" and recompile. And of course, fix all the bugs this exposes. But, this is less work than has been and is being done to fix all the bugs in porting all applications to 64-bit.
Long-term security
Posted Sep 13, 2006 12:57 UTC (Wed) by rvfh (subscriber, #31018) [Link]
Just use an unsigned int and you'll get 68 years extra. How could time possibly be negative?
Long-term security
Posted Sep 13, 2006 13:22 UTC (Wed) by pbardet (subscriber, #22762) [Link]
To store dates before 1970 on very old apps ?
Time representation
Posted Sep 13, 2006 13:33 UTC (Wed) by rvfh (subscriber, #31018) [Link]
That particular counter is operating system time. Applications can do what they see fit, but the system time is meant to be UTC. So negative time only helps for people who use time machines ;-)
Time representation
Posted Sep 13, 2006 13:42 UTC (Wed) by HenrikH (guest, #31152) [Link]
Exactly what has UTC with this issue? Negative values for time_t is perfectly legal and is meant to reference dates and times before 1970
Time representation
Posted Sep 13, 2006 14:10 UTC (Wed) by rvfh (subscriber, #31018) [Link]
The original post about 2038 is about OS time, the epoch counter in UNIX operating systems. This time is meant to represent the time now for OS use (file modified time and so on).
Applications might need to deal with 6000 B.C., but they do not need to set the OS time to that date, so it's their problem to handle the time as they see fit, and use a 1024-bit counter for that.
I hope I am not misunderstanding your point, otherwise feel free to correct me!
Time representation
Posted Sep 13, 2006 15:56 UTC (Wed) by HenrikH (guest, #31152) [Link]
Both yes and no, the original post talks about time_t beeing 32-bits since it is defined as an int. time_t is used both by the kernel to track the current time and by libc to represent time for userspace applications. There is no separation between the two. time_t is used extensibly by userspace programs to store dates and times which of course can be hsitorical times aswell, and the time and date functions in libc uses time_t for this purposes aswell.
Time representation
Posted Sep 13, 2006 16:08 UTC (Wed) by rvfh (subscriber, #31018) [Link]
In this case one can only code dates which are 68-odd years either side of 1 January 1970, i.e. 1902 to 2038. This does not even cover birth dates for many countries' population!
No, really, applications need a lot more possibilities than the operating system does, so back to square one: the OS could have an unsigned number for its current epoch.
Quoting David Schwartz
on the same kind of discussion:
Application programmers can allocate space or not, that's their
decision. Well-written application code either uses its own date classes
or uses date classes that are known to be safe for the range of dates the
application is intended to handle. If we're talking about fixing
application code, why are we doing it on the linux-kernel list?
Why is time_t not unsigned
Posted Sep 13, 2006 16:29 UTC (Wed) by rvfh (subscriber, #31018) [Link]
I found an answer to my own question, in case anybody is interested...
If you start a system with time = 0 and local time is GMT-something (any place west of Greenwich: Brasilia (GMT-3), New York (Eastern time), ...), then you get time before 1 January 1970. Well, you don't if time_t is unsigned! You get time in 2107 instead :-(
Time representation
Posted Sep 13, 2006 19:35 UTC (Wed) by HenrikH (guest, #31152) [Link]
Who ever said that it was wise by the applications to use time_t ;-)
Anyways one reason that it is used is that time_t has excellent support in libc with conversion functions between localtime and UTC for current and historical dates. So one does not have to find another date library. Also since you get a time_t from the gettimeofday() systemcall one tend to use the very same variable in the application, it is not the the kernel is completely isolated into its own world.
Time representation
Posted Sep 13, 2006 20:39 UTC (Wed) by dark (subscriber, #8483) [Link]
the OS could have an unsigned number for its current epoch.Not anymore, it can't :) Too many applications rely on it being signed. (And if you don't mind breaking those, then why not move to 64 bits instead?)
One reason they rely on it is that in addition to using time_t to represent dates, they subtract time_t values from each other to represent intervals.
For example:
while (deadline - time() > 15) { ... do something that might take 15 seconds ... }
If time_t is unsigned, this condition will be true if time() is already past the deadline, thus causing an infinite loop. Well, not really infinite... just 68 years :)
Long-term security
Posted Sep 13, 2006 13:58 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link]
Well, it was my first DB app, and I didn't bother sorting the timestamps.Q: No one would override the warnings and violate the start/stop sequence of the data entries, would they?
A: Just the first user.
Long-term security
Posted Sep 13, 2006 14:19 UTC (Wed) by nix (subscriber, #2304) [Link]
They'll only continue to work if we've fixed all the places where 32-bit time_t is wired into data on disk, filesystems layouts, and so on. (Mind you those'll have to be fixed sooner or later anyway).
servers - no brainer
Posted Sep 13, 2006 19:41 UTC (Wed) by ccyoung (subscriber, #16340) [Link]
been running servers 64 bit Ubuntu for over a year. somewhat faster, not a problem. just put up a couple of new Dapper Drake, err, LTS 6.0.x, on web and mail servers - very sweet.
am I missing something?
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 20:19 UTC (Wed) by Nelson (subscriber, #21712) [Link]
I was using Mandriva with Opteron for a while and it lagged. They've had some issues within their org and I assume they're getting them fixed but for a while they had forgot about x86_64, literally, the build machine that does the automatic builds was broken and nobody knew or did anything about it. Other than that, Fedora Core has a decent 64bit distribution. It includes all the 32bit stuff so that you can run off the shelf apps. If you for some reason need it to be "pure 64bit" across the board, you might be out of luck but if you don't mind running a 32bit openoffice or some other apps then you'll be fine. I've really not noticed any difference in support, I can run everything I need to and since I use it day in and day out at the job I tend to run a lot of stuff.
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 13, 2006 23:44 UTC (Wed) by proski (subscriber, #104) [Link]
Actually, the 64-bit OpenOffice.org is available in the Fedora Core 5 updates, and it works much faster. So it is possible to go pure 64-bit without sacrificing any supported free software.
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 19, 2006 18:08 UTC (Tue) by xorbe (guest, #3165) [Link]
iirc, some dude did know about it, but he delayed the repair in protest of something... I forget what the fuss was all about.
Their x86_64 seem to be updated and working these days. Things were really sad for a while.
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 14, 2006 7:42 UTC (Thu) by pcampe (subscriber, #28223) [Link]
The original article looks like a bit outdated, if I compare it with myown experience.
I switched to a 64bit Fedora more than one year ago, because I think makes
sense for a sys admin to explore strange, new worlds and (fore)see the
potential problems in a production environment.
I didn't do real benchmark, but at the switching time I had the
distinctive feeling that Gnome was faster, and in a noticeable way.
First time were a bit difficult, as there is not working and free
virtualization technique available for 64bit system, being VmWare not free
and qemu and Wine unworking.
Things have been changed, and now my current configuration includes a
Fedora 5/x86_64 (which supports wine, I didn't test it at all but I do not
understand why the original writer defines it "problematic", I assume that
if it has been packetized for Fedora it's because it reasonably works),
and (that's the key point) a Vmware which runs a Windows XP/Fedora 32
bit/whatever when I need to do some tests or, more practically, see a
Flash-enabled site (like youtube). Also Vmware was capable of supporting
some hardware Linux does not (webcam and cellphone).
The release of free (as beer) Vmware for Linux was a big helps, it
alleviates the need of a 64bit Flash player, altough other options are
viable (I read on Lwn about a 64bit->32bit wrapper for Firefox), but the
whole point is that, if you start to think to your desktop system as a
collection of operating systems (enabled via some kind of virtualization
technology) you eventually have no shortcomings at all, so there is no
need to switch back to a 32bit Linux, you can keep the (little or more)
extra power for free.
What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
Posted Sep 17, 2006 17:35 UTC (Sun) by zooko (subscriber, #2589) [Link]
I have run the (commercial, proprietary) vmware workstation on my 64-bit Ubuntu for a year or so now. It works fine. The only problem was that it didn't set the title bar on the window, so when switching between windows I had to remember that the unnamed one was the vmware window. In the latest release of vmware workstation that too is fixed.
(Warning: you might have to install some 32-bit libs to run vmware. Not sure if this is still true with the latest version.)
(Hint: apply Petr's latest vmware-any-any patch.)
How about core 2 duo and 64 bit?
Posted Sep 14, 2006 11:37 UTC (Thu) by lamikr (guest, #2289) [Link]
I am little confused with this core 2 duo.If I have understood correctly, that chip has also 64 bit instructions.
Are those 64 bit instructions compatible with AMD 64, I mean can I install some of the 64 bit Linux distributions currently targeted for the AMD64 for the core duo 2 or would I need to have another 64 bit Linux distro to get advantage from those 64 bit instructions?
How about core 2 duo and 64 bit?
Posted Sep 14, 2006 16:17 UTC (Thu) by Lockjaw (subscriber, #4611) [Link]
This is being posted from a Core 2 Duo machine running Debian Etch AMD64, so it's definitely possible. AMD calls their 64 bit extensions AMD64 (originally they called them x86-64), and Intel calls theirs EM64T, but they're the same as far as an end user is concerned.
ps - It's a nice machine so far - very fast. I'm still waiting for the Intel graphics drivers to make it from experimental into testing, but in the meantime the Vesa driver is limping along (I'm no gamer). Also, my wireless card no longer works (Ralink - the driver is under pretty heavy development); that's probably been the most annoying aspect of the switch.
Some rough benchmarks
Posted Sep 18, 2006 8:51 UTC (Mon) by fred87 (guest, #31349) [Link]
I made these around a year ago, on the same machine, comparing Slamd64,Slackware, and 32-bit binaries on top of a 64-bit kernel:
http://slamd64.com/benchmarks.htm
Disclaimer: You may consider me biased, as I maintain a 64-bit distro.