LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 06-22-2008, 10:27 AM   #1
ciden
Member
 
Registered: Dec 2006
Location: New Delhi, India
Distribution: PCLinuxOS 2010
Posts: 246
Blog Entries: 1

Rep: Reputation: 31
64 bit OS advantages.


Are there any advantages in running a 64-bit OS on a machine with lesser than 4 Gigs of RAM?

Or would it actually run slower than the 32-bit version?
 
Old 06-22-2008, 12:05 PM   #2
rjlee
Senior Member
 
Registered: Jul 2004
Distribution: Ubuntu 7.04
Posts: 1,991

Rep: Reputation: 76
There are no inherent advantages to using a 64-bit processor to an equivalent 32-bit processor (with similar function sets), aside from the ability to address more that 4Gb of RAM.

32-bit software will not run any faster than 64-bit. In particular, when AMD first launched their 64-bit Opteron processors, they scored big points at the time against the then-current Intel processors, because the AMD chips could run 32-bit instructions natively at full speed, while the Intel chips had to translate them into 64-bit instructions. So, depending on your hardware, 64-bit software may be faster than the same software compiled for 32-bit.

The main problem with 64-bit processors is software availability. All open-source software is available compiled for 64-bit machines. But it is (as usual) taking commercial software some time to catch up. Last time I checked, Macromedia Flash Player won't work with 64-bit Firefox and 64-bit Java did not include the Java Web Start application.

Having said that, there's no reason you can't install 32-bit Java and Firefox even on a 64-bit operating system (on Linux at least; I think Windows-32 and -64 have some fundamental differences that have nothing to do with the number of bits in the instruction set).

As an aside, Linux has a kernel option to address more than 4Gb of RAM even with 32-bit processors; each process is still limited to 4Gb, and it may slow you down slightly (if you are not using the extra memory). Plus it may require you to recompile the kernel, which is not much fun.

Hope that helps,

—Robert J Lee
 
Old 06-22-2008, 12:36 PM   #3
crashmeister
Senior Member
 
Registered: Feb 2002
Distribution: t2 - trying to anyway
Posts: 2,541

Rep: Reputation: 47
There are some apps (mainly databases) where 64 bit does run faster.

But there is no reason I am aware of (I am not aware of everything) why you shouldn't use a 64 bit system - everything will go 64 bit eventually anyway.

Used to be the way that certain video formats and the mentioned flashplayer were a pain to use but these days almost all distros use workarounds out of the box to make those things work.
 
Old 06-22-2008, 12:41 PM   #4
b0uncer
LQ Guru
 
Registered: Aug 2003
Distribution: CentOS, OS X
Posts: 5,131

Rep: Reputation: Disabled
Quote:
Originally Posted by crashmeister View Post
Used to be the way that certain video formats and the mentioned flashplayer were a pain to use but these days almost all distros use workarounds out of the box to make those things work.
True; for example the Flash player's "32-bitness problem" is circumvented in various ways, one being to use a 32-bit browser version instead of a 64-bit one, and another one to use a special wrapper that enables a 64-bit browser to use a 32-bit plug-in trough the wrapper (the idea is somewhat similar to ndiswrapper which enables using Windows drivers for wireless hardware on Linux).

In programming having a 64-bit processor also makes some differences; for a lot of program code it doesn't mean much or anything, but for some code it does, especially low-level code.
 
Old 06-22-2008, 01:59 PM   #5
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291
I think it should make a difference when using floating point numbers, right ? Because a 'double' is 8 bytes in length or 64 bits and on a 32-bit processor this would use up 2 registers while on a 64-bit processor this would use up only 1 register, theoretically. And I'm guessing the floating point coprocessor still exists and has the same word length as the processor.
 
Old 06-22-2008, 08:33 PM   #6
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191
Quote:
Originally Posted by ciden View Post
Are there any advantages in running a 64-bit OS on a machine with lesser than 4 Gigs of RAM?
Maybe. Depends what programs you run. More likely, you would not notice any difference either way.

Quote:
Or would it actually run slower than the 32-bit version?
Some programs, probably the majority, would run a little slower, but probably not by enough to matter. Other programs would run a little faster. Very few would run a lot faster.

Quote:
Originally Posted by crashmeister View Post
There are some apps (mainly databases) where 64 bit does run faster.
I haven't actually done that comparison, but I would expect 64 bit database applications to run slower than 32 bit on a system with less than 4GB. A database program probably can make more effective use of memory beyond 4GB in a 64 bit system than in a 32 bit, unlike most programs that either need more than 3GB virtual (can't run at all in 32 bit) or don't need more than 3GB virtual and get no benefit from having more available.

But since we're talking about less than 4GB, I can't think of a reason a 64 bit system would make a database faster, and I know several reasons it would be slightly slower.

Program doing some sort of transformation to video or audio data (to a different format, or shifting colors, or any other systematic change) have been reported as running much faster in 64 bit. The likely reason is that the compiler has used SSE for 64 bit, but not for 32 bit. That is the default compiler behavior. I haven't found out whether you have a choice. The hardware allows use of SSE in 32 bit mode and use of non SSE floating point in 64 bit mode. I don't know whether GCC allows it. So use of SSE might be the big advantage of 64 bit mode if you don't or you can't use it in 32 bit mode.

Quote:
Originally Posted by H_TeXMeX_H View Post
I think it should make a difference when using floating point numbers, right ?
Only when using them intensively and systematically enough that the compiler can make good use of SSE and then only if you couldn't have gotten the compiler to use SSE in 32 bit mode.

Quote:
Because a 'double' is 8 bytes in length or 64 bits
True. But ...

Quote:
and on a 32-bit processor this would use up 2 registers while on a 64-bit processor this would use up only 1 register
False. It uses special floating point registers that are the same size in 64 bit mode that they were in 32 bit mode.

Quote:
And I'm guessing the floating point coprocessor still exists and has the same word length as the processor.
The coprocessor, as such, hasn't existed in a long time and it never had the same word length as the processor.

An emulation of the coprocessor still exists (in both 32 bit mode and 64 bit mode) and its support of 32 bit, 64 bit and 80 bit floating point is exactly the same between the two modes (32 or 64) of the rest of the CPU. The size of floating point data never was connected to the size of integer data and addresses.

The CPU (again in both modes) also has a second way to do floating point, using SSE. SSE is generally easier for a compiler to generate code (vs. the coprocessor emulation) and for certain very regular patterns of floating point use, SSE can also be much faster to execute.

Another advantage of 64 bit mode is that it has twice as many general registers (for integers and addresses) as well as twice as many SSE registers. The GCC compiler was never very good at dealing with the shortage of registers in X86, so having twice as many makes GCC generate better code. It's hard to predict what sort of application will gain enough benefit from that to overbalance the performance costs of 64 bit. Typically the performance costs of 64 bit are low and the benefits of twice as many registers is low and the net performance impact is very small in one direction or the other.
 
Old 06-23-2008, 09:13 AM   #7
ciden
Member
 
Registered: Dec 2006
Location: New Delhi, India
Distribution: PCLinuxOS 2010
Posts: 246

Original Poster
Blog Entries: 1

Rep: Reputation: 31
Are the core 2 duo processors of intel able to run 32-bit OS as fast as equivalent AMD X2 dual core processors?
 
Old 06-23-2008, 09:24 AM   #8
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191
Quote:
Originally Posted by ciden View Post
Are the core 2 duo processors of intel able to run 32-bit OS as fast as equivalent AMD X2 dual core processors?
Depends what "equivalent" means.

Maybe you are confused by old information about IA64. That was a 64 bit design with some legacy support for 32 bit, but not good enough to make 32 bit actually practical.

The EM64T design is very close to the AMD64 design. If some EM64T chip is performance equivalent to an AMD64 chip in a 64 bit OS, I would expect them to also be performance equivalent in a 32 bit OS.

But the memory access design is very different between Intel and AMD. An Intel chip probably has a larger L2 cache than an "equivalent" performance AMD chip. So it may perform much better in applications where a larger L2 cache matters a lot and may perform significantly worse in applications with so much locality that only the inner CPU speed matters or in applications where there is so little locality that only the memory bus matters.

So "equivalent" would never mean "same". At best it means average together some programs that run faster with some that run slower.

Last edited by johnsfine; 06-23-2008 at 09:31 AM.
 
Old 06-23-2008, 02:18 PM   #9
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291
Thanks for the clarification johnsfine.

Then I guess there really is not much difference. I'll still try setting up a 64-bit system on my new box. Maybe I'll do a double install 32-bit and 64-bit and make some benchmarks, eh ? Let's see, I'll probably use Slackware 12.0 and Slamd64 12.0 (or 12.1 of each if they come out with it).
 
Old 06-23-2008, 02:50 PM   #10
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191Reputation: 1191
Quote:
Originally Posted by H_TeXMeX_H View Post
Maybe I'll do a double install 32-bit and 64-bit and make some benchmarks
What would you use for benchmarks? I don't think I could come up with a good answer for that.

The choice of benchmark may determine the results (whether 64bit is better or worse).

If you have tasks YOU use a lot that seem to depend on CPU speed, then those should be the basis for YOUR benchmarks.

I've done a lot less so far with my home Linux computer than I had intended and nothing CPU intensive. Hopefully I'll find time to fix that.

At work, I spend a LOT of time waiting for a large project to recompile, running four compilers in parallel on a quad core Intel Windows XP64 system. Compared to the XP32 system I used previously, I see a much bigger difference now for first compile after a reboot or significant other work vs. recompile after the usual debug and make a small change.

IIUC, XP64 can keep all the source files used in a build in its file cache at once. But XP32 can't fit that many files in file cache even though they are small enough to all fit in ram. I'm less clear on why comparisons show such a high CPU time cost and low disk I/O cost to a miss in the file cache.

I think (far from sure) both XP32 and 32 bit Linux, when they have enough physical ram (but not enough kernel virtual memory) for file caching, may drop files from the cache, but leave their pages in ram and somehow find them again when next accessed. If that explains the results I see, then the CPU cost for XP32 to find those files is so large, it's barely better than redoing the disk I/O. XP64 simply allows file caching to use far more kernel virtual memory and has instant access to any files whose caching fits in physical ram.

I expect some similar difference between 32 bit and 64 bit Linux. Assume an activity (similar to recompiling a really BIG project) that uses files whose total count and size is small enough to cache in physical ram, but too big to cache in a 32 bit kernel's virtual address space. There should be a big performance boost to using a 64 bit kernel.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
64 bit cpu-64 bit Ubuntu-are there 32 bit app issues? sofasurfer Ubuntu 7 04-09-2014 03:02 PM
Triple Boot Suse 10.3 32 bit, suse alpha 11.0 64 bit and Windows XP (32 Bit) 1kyle SUSE / openSUSE 1 02-28-2008 11:25 AM
Advantages? phantom_cyph Solaris / OpenSolaris 19 02-10-2008 03:31 PM
32 bit or 64 bit install - is 32 bit easier for a newbie? dms05 Linux - Newbie 3 05-19-2006 04:05 PM
Advantages zekko Slackware 2 09-03-2003 03:58 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 09:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration