http://www.osnews.com/story/16841/Ubuntu_32-Bit_v_64-Bit_Performance Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Wed, 22 May 2013 07:35:09 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://www.osnews.com/thread?197095 http://www.osnews.com/thread?197095 As the results of this article illustrate, system-level performance actually has little to do with raw CPU cycle speed.

Common bottlenecks such as front-side bus speed, memory access speed and I/O rates are throttling throughput as much as, if not more than, CPU math processing. Once you have to go off-chip, all bets are off. For throughput, I'd trade a honking big L1/L2/Ln cache for wider CPU datapaths.

That being said, the 64-bit model cleverly avoids the 3GB per-process VM limitation of the 32-bit world. Users needed large application spaces would do well to look to 64-bit machines. Fri, 29 Dec 2006 21:37:00 GMT donotreply@osnews.com (megacoder) Comments http://www.osnews.com/thread?197099 http://www.osnews.com/thread?197099 ...on my 64-bit Turion Laptop is that it's a bit of a pain to configure win32 video codecs + Flash to work (since they don't have 64-bit versions). Sure, you can do it by setting up 32-bit chroots (and that in itself shows the power of Linux), but I didn't get enough of a performance boost to justify the hassle, personally. Fri, 29 Dec 2006 21:57:00 GMT donotreply@osnews.com (archiesteel) Comments http://www.osnews.com/thread?197107 http://www.osnews.com/thread?197107 "As the results of this article illustrate, system-level performance actually has little to do with raw CPU cycle speed. "

How did you get that conclusion from the article?? Fri, 29 Dec 2006 22:11:00 GMT donotreply@osnews.com (mtilsted) Comments http://www.osnews.com/thread?197114 http://www.osnews.com/thread?197114 It's interesting to notice how Linux got slower between the 2 releases. Fri, 29 Dec 2006 22:29:00 GMT donotreply@osnews.com (Zenja) Comments http://www.osnews.com/thread?197117 http://www.osnews.com/thread?197117 You mean Ubuntu, not Linux, right?

You should be aware that Feisty Fawn isn't out yet. It's still in pre-beta, which means that there are bound to be some performance issues. Fri, 29 Dec 2006 22:32:00 GMT donotreply@osnews.com (archiesteel) Comments http://www.osnews.com/thread?197134 http://www.osnews.com/thread?197134 this benchmark shows is that running 64bit Linux doesn't matter yet for Joe Sixpack because most user space software doesn't utilise the bigger address space. You can't generally conclude anything about Ubuntu nor Linux itself nor can you claim that speed has nothing todo with raw CPU power. If there would have been included a test for number crunching through some geo data set you would see the difference, though definitely not x2. Fri, 29 Dec 2006 22:55:00 GMT donotreply@osnews.com (retrakker) Comments http://www.osnews.com/thread?197142 http://www.osnews.com/thread?197142 I'm not surprised. Outside of specialist environments the aforementioned memory boundaries and the deeper register size don't play a large role. OTOH, the benefits of more SSE and POH registers also apply to i386 software. Once software starts to utilize the advantages of 64 bit registers in larger numbers we will see AMD64 software outperform i386 software, but this is probably still a few good years down the pipe. Fri, 29 Dec 2006 23:31:00 GMT donotreply@osnews.com (B. Janssen) Comments http://www.osnews.com/thread?197145 http://www.osnews.com/thread?197145 When you move from 32 bit x86 to 64 bit x86, two things important to performance change:

1. Words become twice as large. When you have to swap registers around, you have to move twice as much data. This makes the system slow down.

2. You now have twice as many general purpose registers (16 instead of 8). On a register-starved architecture like x86, this means you have to swap registers around much less often, reducing requirements on the bus and decreasing the number of instructions. This makes the system speed up.

Whether (2) counterbalances (1) enough to make your system actually faster depends a great deal on the program you are running, as these benchmarks show. Fri, 29 Dec 2006 23:35:00 GMT donotreply@osnews.com (nathanw) Comments http://www.osnews.com/thread?197151 http://www.osnews.com/thread?197151 "1. Words become twice as large. When you have to swap registers around, you have to move twice as much data. This makes the system slow down."

The words are twice as wide but so are the data paths.

Net result is no difference. Fri, 29 Dec 2006 23:51:00 GMT donotreply@osnews.com (Tim Locke) Comments http://www.osnews.com/thread?197153 http://www.osnews.com/thread?197153 Indeed. I've got an Athlon64 and I've never used a 64-bit version. I've always gave them a try once Ubuntu releases a new version of it's OS but the problems that the proprietary software brings to the table are just a too much trouble to enjoy such a small return. Fri, 29 Dec 2006 23:53:00 GMT donotreply@osnews.com (GreatBunzinni) Comments http://www.osnews.com/thread?197155 http://www.osnews.com/thread?197155 Well, it does if you have to save them to main memory (context switches, for instance). Inside the CPU, as you say, it makes no difference.

I should also have noted in my original post that 64 bit architectures vastly speed up computational work involving 64-bit integerss or very precise floating point values. This is really noticeable in scientific applications (physics simulations for instance). Fri, 29 Dec 2006 23:57:00 GMT donotreply@osnews.com (nathanw) Comments http://www.osnews.com/thread?197157 http://www.osnews.com/thread?197157 well, i do think he's right. the biggest part of the performance difference is (i think) the kernel - 2.6.19 seems to be slower than 2.6.17. there are other explanations possible, but to me it seems the kernel is to blame. compiling the kernel got >20s slower, and encoding an mp3 took a little longer. of course, the compile could be due to a slower gcc, encoding because lame got a bit slower. and the mem benchmark is faster, as is gzip. so it's not decisive at all... Sat, 30 Dec 2006 00:19:00 GMT donotreply@osnews.com (superstoned) Comments http://www.osnews.com/thread?197159 http://www.osnews.com/thread?197159 Absolutely. Sat, 30 Dec 2006 00:31:00 GMT donotreply@osnews.com (Tim Locke) Comments http://www.osnews.com/thread?197161 http://www.osnews.com/thread?197161 Net result is no difference.

Not quite true. 64-bit programs use more memory than 32-bit ones. As such, less memory is available for the system to use, more bandwidth is used shuttling the program around in memory, and since less memory is available, less things can be cached, etc. Sat, 30 Dec 2006 00:32:00 GMT donotreply@osnews.com (binarycrusader) Comments http://www.osnews.com/thread?197166 http://www.osnews.com/thread?197166 Zenja wrote:
It's interesting to notice how Linux got slower between the 2 releases.

RTFA:

it is also worth noting that at this time there are no real speed increases between Edgy Eft and Feisty Fawn; however, this was only the first Alpha (Herd) release of many to come before the April 2007 release of Ubuntu 7.04.

If you had bothered to look at the performance graphs (those funny looking pictures with bars and numbers) alone you would have seen there was overall virtually no difference in performance. Some tests ran a little faster on Ubuntu 7.04 Feisty Fawn Herd 1 than Ubuntu 6.10 Edgy Eft and some a little slower.

I would appreciate it if you refrained from making ignorant and ill informed comments of limited veracity.Edited 2006-12-30 01:07 Sat, 30 Dec 2006 01:03:00 GMT donotreply@osnews.com (chemical_scum) Comments http://www.osnews.com/thread?197172 http://www.osnews.com/thread?197172 Because everything that Ubuntu has is also available in Debian and SuSE and Fedora. Sat, 30 Dec 2006 01:16:00 GMT donotreply@osnews.com (stephanem) Comments http://www.osnews.com/thread?197179 http://www.osnews.com/thread?197179 It's interesting to notice how Linux got slower between the 2 releases.

Good thing Windows Vista performs just as well as Windows XP does on the same hardware . Sat, 30 Dec 2006 01:49:00 GMT donotreply@osnews.com (Jimbo) Comments http://www.osnews.com/thread?197181 http://www.osnews.com/thread?197181 Who cares. Sat, 30 Dec 2006 01:57:00 GMT donotreply@osnews.com (Bringbackanonposting) Comments http://www.osnews.com/thread?197186 http://www.osnews.com/thread?197186 Then Jimbo woke up.

Nice try though. Sat, 30 Dec 2006 02:24:00 GMT donotreply@osnews.com (blitze) Comments http://www.osnews.com/thread?197215 http://www.osnews.com/thread?197215 this doesn't really apply to most ubuntu users but if you do a lot of compiling, it is beneficial to go with 64. I know from personal experience that in some cases i experience up to 30% faster compile times with 64 bit over the same installation in 32 bit on the same athlon64 box. Sat, 30 Dec 2006 04:37:00 GMT donotreply@osnews.com (re_re) Comments http://www.osnews.com/thread?197225 http://www.osnews.com/thread?197225 "Good thing Windows Vista performs just as well as Windows XP does on the same hardware ."

Actually you're mixing things here.

First of all they're comparing the same application on different systems, what you're comparing is completely different systems (which have different applications). Yet again it depends.

For example graphics performance of Vista is better than XP on the same machine if you have a mid to high end card.

The desktop GUI, at least feels faster than XP counterpart, even when transparency is enabled.

Also games give higher FPS because of the optimizations done on DirectX core. (The new version uses better data paths that result in less data moved around).

But if you're talking about general application performance you may see an obvious decrease. This is because Vista uses more RAM in idle configuration. (Yet it will probably run faster than XP if you happen to have > 1GB of RAM).

While you're at it, try to look at: http://en.wikipedia.org/wiki/Features_new_to_Windows_Vista#System_p...

Oops, sorry... I shouldn't have fed the troll... Edited 2006-12-30 05:31 Sat, 30 Dec 2006 05:23:00 GMT donotreply@osnews.com (sukru) Comments http://www.osnews.com/thread?197232 http://www.osnews.com/thread?197232 So basically, the findings of the tests reveal no performance boost going from 32 to 64bit OS. I would have liked to have seen Windows XP-Pro and Pro-64bit thrown in there for coloring. Still, the frame rates for Unreal were terrible on all versions. I'd attribute that to the low end video card they used.

My Core2 is running 32bit simply because I'm fearful of the 64bit drivers that I've heard had problems. I just like the fact that the 64bit architecture allows for hardware DEP, or whatever the actual non-Microsoft term is, for it. Sat, 30 Dec 2006 05:59:00 GMT donotreply@osnews.com (Phloptical) Comments http://www.osnews.com/thread?197238 http://www.osnews.com/thread?197238 I think Jimbo was being sarcastic....benefit of the doubt??? Sat, 30 Dec 2006 06:34:00 GMT donotreply@osnews.com (suryad) Comments http://www.osnews.com/thread?197241 http://www.osnews.com/thread?197241 Interesting... Seems like defending Windows on a Linux article gets you modded down. I shall be more careful then.

(I know, this one will probably become -1 too) Sat, 30 Dec 2006 06:44:00 GMT donotreply@osnews.com (sukru) Comments http://www.osnews.com/thread?197242 http://www.osnews.com/thread?197242 That 64bit can be faster, it's been proven when properly written for. Testing games that have not been written to support x86_64 is useless, Far Cry has a AMD64 patch that adds more content without no frame rate loss.

Soon as people start writing apps/games to take advantage of 64bit then we will see the difference. Sat, 30 Dec 2006 06:50:00 GMT donotreply@osnews.com (SlackerJack) Comments http://www.osnews.com/thread?197247 http://www.osnews.com/thread?197247 Theory is nice, but in reality most of the 32 bit vs 64 bit desktop benchmarks I have seen show 32 bit equal or slightly better than 64 bit, with occasional areas like game performance where 32 bit is much faster because the 64 bit drivers are not mature yet.

Additionally, native 64 bit versions tend to use more RAM to store the same data

There are many reasons to hold off on 64 bit for the desktop currently, and the only major reasons I can think of to make the jump to a 64 bit system is if you need more than 4 gig of RAM on your desktop or need to develop 64 bit apps.

Most people are better off using a 32 bit system for the next couple years. Sat, 30 Dec 2006 07:51:00 GMT donotreply@osnews.com (Priest) Comments http://www.osnews.com/thread?197250 http://www.osnews.com/thread?197250 Ah the sad nature of closed source applications, and people wonder why I only use free software. Sat, 30 Dec 2006 08:38:00 GMT donotreply@osnews.com (jessta) Comments http://www.osnews.com/thread?197254 http://www.osnews.com/thread?197254 I wonder whether the author realises that compiling the same vanilla kernel tarball on i386 and x86_64 produces completely different results because a lot of kernel features are specific to the arch it's being compiled on. Any attempt at comparing compilation times is moot. Just run a "make allyesconfig" command on both archs for the same kernel version and compare the resulting .config files to get an idea.

In other words, the 32-bit version will always take longer to compile. You could make a better comparison by cross-compiling instead. Sat, 30 Dec 2006 08:55:00 GMT donotreply@osnews.com (joy division) Comments http://www.osnews.com/thread?197264 http://www.osnews.com/thread?197264 I had some serious problems getting the recent 64 bit (k)ubuntu versions to install at all, something is broken in the diskpartioner on 64 bit..
32 bit versions works, still have to replace ati with radeon in the /etc/X11/xorg.conf file. Sat, 30 Dec 2006 09:51:00 GMT donotreply@osnews.com (gfx1) Comments http://www.osnews.com/thread?197268 http://www.osnews.com/thread?197268 The Unreal Tournament 2004 is 32bit, why compared it with 64bit? Crazy people.. :-) Sat, 30 Dec 2006 10:33:00 GMT donotreply@osnews.com (gothic) Comments http://www.osnews.com/thread?197273 http://www.osnews.com/thread?197273 Just for the fun to know:

For personal use it seems to be a possible solution to run 64 bits variants. For specific (!) tasks, a 64 bit version at companies also has it's use, but up till now, we install the 32 bits versions all the times, irrelevant of the hardware platform, unless seriously asked by our customers to do different.

For now it is almost of no use in our work. Sat, 30 Dec 2006 12:31:00 GMT donotreply@osnews.com (linux-it) Comments http://www.osnews.com/thread?197277 http://www.osnews.com/thread?197277 I recently switched from 32 bit to 64 bit Debian, and haven't had many problems this time. At first, I missed Flash for Youtube, then I discovered http://gwenole.beauchesne.info/en/projects/nspluginwrapper which lets you use 32 bit plugins in 64 bit Firefox. It's a bit of a hassle to get it to work, but it does work. Quake 3 32 bit works as it is. What more do you need?

Most videos play fine without the win32 codec pack. Sat, 30 Dec 2006 13:01:00 GMT donotreply@osnews.com (No it isnt) Comments http://www.osnews.com/thread?197280 http://www.osnews.com/thread?197280 Run Videos fine under VLC.
Audio, can use it fine.
OpenGL and WINE, check, all good.
Quake 4 No Problem haven't bothered with UT2004.
DVDRip, works fine.

Open Office, check.
JACK and Ardour, working but I need to learn more about them.

Deluge, (torrent client) running fine as well.

Only thing I miss is Opera with mouse guestures but I can run the static 32bit version but I hate the font rendering doing that.

More success with 64 Linux than 64 Windows which I've only tried under Vista and drivers are very spartan for that. I can't get audio as well but that what you get with relying on hardware companies to produce the goods. That being said, Nvidia's 64bit Linux driver is very good, just need to look into a little vertical tearing on fullscreen TV out with fast paced low light scenes. Sat, 30 Dec 2006 13:19:00 GMT donotreply@osnews.com (blitze) Comments http://www.osnews.com/thread?197299 http://www.osnews.com/thread?197299 What I would like to see is these same tests performed on a recent Intel CPU. Right now, I'm not sure how Intel's x86-64 implementation stacks against its own IA32 implementation. Sat, 30 Dec 2006 16:07:00 GMT donotreply@osnews.com (CrLf) Comments http://www.osnews.com/thread?197306 http://www.osnews.com/thread?197306 If you look at Unixs that have been 64bit for last 10years or more you will notice that they tend to have a mix of 32bit/64bit software. Kernel would be 64bit but you have all the basic tools (shell commands etc.) running as 32bit after all what difference does a 64bit version of "cp" make?

On Irix for example there are 3 runtime abi's n64 n32 and o32. n64 been 64bit using latest and greateast of underlying CPU architecture (MIPS III or MIPS IV). n32 is basically just the 32bit version of n64 so you get the improvements in underlying CPU arch but it's 32bit binaries produced. o32 is for old binaries that were compiled on MIPS I system.

Now if IRIX and OS that hasn't seen a major new release in over 8years can do this, how come Linux systems tend to get it arse ways.

Do i really need a 64bit version of firefox after all? and don't be complaining that ye have to install a 32bit version of glibc etc with disc space been so cheap it's hardly a valid argument anymore. Sat, 30 Dec 2006 16:58:00 GMT donotreply@osnews.com (Dubhthach) Comments http://www.osnews.com/thread?197307 http://www.osnews.com/thread?197307 The main reason to switch from 32-bit to 64-bit is NOT performance. 64-bit is the future, let's move on. Sat, 30 Dec 2006 16:58:00 GMT donotreply@osnews.com (MrGAM) Comments http://www.osnews.com/thread?197334 http://www.osnews.com/thread?197334 It's too early to tell how effective 64-bit is. Yes, Ubuntu has a 64-Bit distro, but how many applications are actually rewritten to take advantage of the 64-bit processor? I think the test is premature, and too early to tell.

Why are the memory tests done with integers? The differences will be greater than you moving around double precision floating point numbers, not so much integers. This was a poor test: lets test the 32-bit processor, against the 64-bit processor in a 16-bit test as not to show any of its weaknesses.

In Unreal Tournament, did anyone really think that using the 64-bit processor register would make as much difference as buying a video card?

The Lame compilation was also a poor test. What kinds of floating point math is used in compiling a program?

If you want to test the 64-bit extensions, I want to see 2D and 3D CAD tests, I want to see large spreadsheet number crunching, I want to see science programs tested such as astronomy charting software, Fast fourier transformations, computational flow dynamics, and fractal generators--all rewritten for 64-bit. It's not enough to recompile 32-Bit code for 64-Bit.

We are still living in this world where we may not care what 4195835/3145727 is, but as time goes one, we will.

If you have called in the jury on 64-bit processors, you haven't heard all the evidence. Sat, 30 Dec 2006 17:36:00 GMT donotreply@osnews.com (BrendaEM) Comments http://www.osnews.com/thread?197385 http://www.osnews.com/thread?197385 There should be no impact on floating point operations, since the x86 FPU registers are 80 bits wide and is capable of handling the common 64 bit double precision floating point with ease (with the additional 16 bits for overflow). This is why you rarely see any improvement in FP heavy code when moving from x86 - x86-64.

The move from 32 bit to 64 bit doesn't affect floating point. Sat, 30 Dec 2006 18:30:00 GMT donotreply@osnews.com (evangs) Comments http://www.osnews.com/thread?197488 http://www.osnews.com/thread?197488 Yeah...there's always an absolute guarantee that there would be a 64bit version if it was open sourced. Sat, 30 Dec 2006 21:42:00 GMT donotreply@osnews.com (jelway) Comments http://www.osnews.com/thread?197521 http://www.osnews.com/thread?197521 It's like waving a red flag to a bull

FTFA we get the following benchmarks (Edgy vs Feisty):
Unreal Tournament is slower: 24.46/24.30
GZIP is slower: 69.19/68.13
RAMSpeed is slower: 2840/2834 and 2818/2792

But hey, its more fun to insult original poster than actually looking at the coloured graphs you're referring to. Sun, 31 Dec 2006 00:43:00 GMT donotreply@osnews.com (Zenja) Comments http://www.osnews.com/thread?197548 http://www.osnews.com/thread?197548 Actually x86 chips have used larger datapaths under the hood for years. They will write/read combine multiple 32bit accesses together into larger chunks (e.g. 64bit) - so it's moot. The first post is right - on one hand you get more registers, on the other you need to throw more memory around if it contains pointers of any sort. Sun, 31 Dec 2006 02:45:00 GMT donotreply@osnews.com (raster) Comments http://www.osnews.com/thread?197560 http://www.osnews.com/thread?197560 which desktop apps will benefit most from 64 bit? games and video. unfortunately, those aren't strong points for linux yet Sun, 31 Dec 2006 03:44:00 GMT donotreply@osnews.com (arielb) Comments http://www.osnews.com/thread?197580 http://www.osnews.com/thread?197580 If a program is open source and there is a demand for a 64bit version then it is likely that there will be a 64bit port created. Sun, 31 Dec 2006 07:20:00 GMT donotreply@osnews.com (jessta) Comments http://www.osnews.com/thread?197610 http://www.osnews.com/thread?197610 Unlike Debian based distros, not all Linux distros have a problem. For example, Fedora and Red Hat do multilib junk just fine. Sun, 31 Dec 2006 13:17:00 GMT donotreply@osnews.com (Mathman) Comments http://www.osnews.com/thread?197628 http://www.osnews.com/thread?197628 The tested programs were 32 bits programs compiled in 64 bits... this does not change in any way the actual programming.

If you have a 8 bit algorithm, try building it up in 32 or 64 bits... it is still a 8 bit limited program with an 8 bit algorithm.

However, some applications can use and afford 64 bit programming... then you will find the performance more than doubled... (in the parts of the program that use that code). So we get a mix... that will be near the double or less...

Ity all depends of the data you process and the algorithm. Period.

Expecting magic is plain nonsense.
You get what you tested. If you do not do what you are doing or how things work... You get "amazing" results that only reveal your ignorance.

Sorry to be rude but "Articles" made of vapor deserve to be denounced as a bad service to all and the spread of trash. It dis-informs people. No-good... You'll agree. Sun, 31 Dec 2006 15:02:00 GMT donotreply@osnews.com (dulac) Comments http://www.osnews.com/thread?197682 http://www.osnews.com/thread?197682 "Interesting... Seems like defending Windows on a Linux article gets you modded down. I shall be more careful then.

(I know, this one will probably become -1 too) "

Although some people don't like pro-Windows posts, they don't mind people complaining about their moderating iron (penguin) hand. Same on Slashdot. Sun, 31 Dec 2006 20:38:00 GMT donotreply@osnews.com (r3m0t) Comments http://www.osnews.com/thread?197751 http://www.osnews.com/thread?197751 Yeah, there is a definite, although tiny performance regression. Upvoting people who are wrong and downvoting people who are correct won't change that

However, Feisty isn't released yet. Mon, 01 Jan 2007 09:29:00 GMT donotreply@osnews.com (vegai) Comments http://www.osnews.com/thread?198223 http://www.osnews.com/thread?198223 FTFA we get the following benchmarks (Edgy vs Feisty):
Unreal Tournament is slower: 24.46/24.30
That's a 0.65% difference. I would define it "noise". Do you agree?

GZIP is slower: 69.19/68.13
That's a 1.5% difference. Again, I would define it "noise"

RAMSpeed is slower: 2840/2834 and 2818/2792
0.77% and 1.4%.

So, it's hard for me to say whether this is just noise or the end results of using a beta version or the release that is getting 0.X% slower. Wed, 03 Jan 2007 13:45:00 GMT donotreply@osnews.com (PaoloC) Comments