LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-02-2013, 02:23 PM   #16
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 801

Rep: Reputation: 247Reputation: 247Reputation: 247

Quote:
Originally Posted by 273 View Post
I don't mean to be picky but it's not technically 32 bit emulation* as the AMD64 instruction set is a superset of i686 -- meaning when you're running a 32 bit OS you are just making use of some of the processor features and half the registers a bit like locking a 4*4 vehicle in rear wheel drive for want of an analogy.


*OK, before anyone points it out the AMD64 and i686 instructions may well be emulated in microcode on the CPU but that's another story.
I don't consider that being "picky". It is being "accurate". The 32-bit instructions are not all emulated in microcode. There are some instructions in both AMD and Intel CPUs that are implemented in microcode because of the complexity of the instructions. That is not "emulation" because all CPUs implement those instructions using microcode. That applies to both 64-bit and 32-bit operation. The majority of the instructions are implemented in the hardware without using microcode.

AMD and Intel both spend a lot of effort (and hardware real-estate) to optimize the performance of the most frequently used instructions. Intel tends to focus on very specific situations, while AMD tends to focus on overall performance of entire classes of instructions or the whole CPU. Without looking at benchmarks it would be hard to say anything definite about performance differences between 32-bit and 64-bit operation on some particular CPU. I expect that many of the 32-bit instructions use the same hardware implementation as the 64-bit instructions with only slight modifications of how the results are masked and carry is handled.

One way that both AMD and Intel got slightly better performance from 64-bit is by eliminating support for segmentation and task selectors. That avoids some extra address translation steps and some privilege checking. Most operating systems use a "flat" memory model and perform their own task switching rather than using the hardware task selectors. Since all 64-bit operating systems on the X86 are new, it was reasonable to prohibit them from using those legacy features in 64-bit mode.

The differences in the size of instructions between 32-bit and 64-bit are complicated, but in most cases the optimization of instruction fetching and execution makes that unimportant for performance. It is mostly the size (not speed) of the software that is affected by 32-bit versus 64-bit.
 
Old 05-02-2013, 02:25 PM   #17
Martinus2u
Member
 
Registered: Apr 2010
Distribution: Slackware
Posts: 350

Rep: Reputation: 56
Quote:
Originally Posted by narz View Post
I think maybe only the kernel itself addresses 896 MB but I don't even get how that's how relevant to userland operation.
it is relevant in so far as it limits the amount of physical memory the system can use. (note we are not talking about virtual address space here, nor demand paging.)
 
Old 05-02-2013, 02:30 PM   #18
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,508

Rep: Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800
Quote:
Originally Posted by Erik_FL View Post
I don't consider that being "picky". It is being "accurate". The 32-bit instructions are not all emulated in microcode. There are some instructions in both AMD and Intel CPUs that are implemented in microcode because of the complexity of the instructions. That is not "emulation" because all CPUs implement those instructions using microcode. That applies to both 64-bit and 32-bit operation. The majority of the instructions are implemented in the hardware without using microcode.

AMD and Intel both spend a lot of effort (and hardware real-estate) to optimize the performance of the most frequently used instructions. Intel tends to focus on very specific situations, while AMD tends to focus on overall performance of entire classes of instructions or the whole CPU. Without looking at benchmarks it would be hard to say anything definite about performance differences between 32-bit and 64-bit operation on some particular CPU. I expect that many of the 32-bit instructions use the same hardware implementation as the 64-bit instructions with only slight modifications of how the results are masked and carry is handled.

One way that both AMD and Intel got slightly better performance from 64-bit is by eliminating support for segmentation and task selectors. That avoids some extra address translation steps and some privilege checking. Most operating systems use a "flat" memory model and perform their own task switching rather than using the hardware task selectors. Since all 64-bit operating systems on the X86 are new, it was reasonable to prohibit them from using those legacy features in 64-bit mode.

The differences in the size of instructions between 32-bit and 64-bit are complicated, but in most cases the optimization of instruction fetching and execution makes that unimportant for performance. It is mostly the size (not speed) of the software that is affected by 32-bit versus 64-bit.
I suspect the reason some application may be faster when compiled for 64 bit CPUs is because they're able to use instructions not guaranteed to be available in pre-AMD64 CPUs -- SIMD type instructions, perhaps? In other words they may be faster more because they're compiled for more modern CPUs no because they're 64 bit.
 
Old 05-02-2013, 04:50 PM   #19
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 801

Rep: Reputation: 247Reputation: 247Reputation: 247
Quote:
Originally Posted by Martinus2u View Post
it is relevant in so far as it limits the amount of physical memory the system can use. (note we are not talking about virtual address space here, nor demand paging.)
Actually the 800MB (approx.) is the limit on kernel virtual memory space. The limit is the 1GB of process virtual space reserved for the kernel minus the space required to map PCI bus addresses. It does not limit the amount of physical RAM that the kernel or applications can use. The 800MB limits how much physical RAM the kernel can leave permanently mapped for access by the kernel. The kernel doesn't permanently map all of physical RAM. Instead the kernel temporarily maps individual pages or small ranges of pages when it needs to access the physical RAM. The limited kernel virtual space may affect performance but it doesn't limit the amount of physical RAM.

The actual physical RAM limit for a 32-bit kernel is 64GB. That is large enough that very few systems would ever encounter the limit. Note that this is not true of Windows, where Microsoft purposely limited non-server 32-bit versions of Windows to 4GB of RAM (by leaving out PAE support).

In fact the physical RAM on most systems is limited by the chip-set rather than 32-bit software. Intel made a marketing decision to limit their non-server chip-sets to 4GB until recently. Intel, like Microsoft wanted to charge a premium for its "server" chip-sets that supported over 4GB of RAM.

In some respects Intel and Microsoft were both dragged "kicking and screaming" into 64-bit by AMD. AMD used 64-bit as a marketing tool to regain the lead in CPU architecture (though it was temporary). Intel and Microsoft had no choice but to support 64-bit lest they be viewed as lagging behind technology.

There was very little real need for 64-bit CPU architecture, and there still isn't. Most programs do not need over 3GB of permanently mapped memory. Programs can re-map portions of their 3GB to access any amount of physical RAM. Very few calculations require 64 bits, and 32-bit CPUs can perform 64-bit calculations using multiple instructions. Even in 32-bit mode the MMX and SIMD instructions support 128-bit calculations (256-bit recently). Instruction optimization on 32-bit CPUs makes 64-bit calculations happen about as fast as they do on 64-bit CPUs.

So, pretty much any actual limitations of 32-bit software are artificial and apply to Windows rather than Linux. Some limitations of 32-bit hardware and software have occurred because 64-bit exists. They probably would not be limitations if 32-bit hardware continued to be developed. For example, there is no reason why PAE could not be expanded to allow more than 64GB of physical memory on a 32-bit CPU. If Microsoft had not produced 64-bit versions of Windows, they might have added full PAE support to 32-bit versions of Windows.
 
Old 05-02-2013, 04:52 PM   #20
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,619
Blog Entries: 2

Rep: Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076
Quote:
Originally Posted by 273 View Post
I suspect the reason some application may be faster when compiled for 64 bit CPUs is because they're able to use instructions not guaranteed to be available in pre-AMD64 CPUs -- SIMD type instructions, perhaps? In other words they may be faster more because they're compiled for more modern CPUs no because they're 64 bit.
Usually AMD64-capable CPUs don't use the older x87 FPU for floating point math anymore, but SSE2 instead. So any distro compiled for AMD64 will make use of those SIMD instruction set.
 
Old 05-02-2013, 05:00 PM   #21
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,508

Rep: Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800
Quote:
Originally Posted by TobiSGD View Post
Usually AMD64-capable CPUs don't use the older x87 FPU for floating point math anymore, but SSE2 instead. So any distro compiled for AMD64 will make use of those SIMD instruction set.
That would make sense. A friend recently switched to 64 bit for music recording and 64 bit seems to handle it much better -- I wondered whether it was due to the SIMD instructions having fewer denormals and dealing with them better.
 
Old 05-03-2013, 02:47 PM   #22
Martinus2u
Member
 
Registered: Apr 2010
Distribution: Slackware
Posts: 350

Rep: Reputation: 56
Quote:
Originally Posted by Erik_FL View Post
Actually the 800MB (approx.) is the limit on kernel virtual memory space. The limit is the 1GB of process virtual space reserved for the kernel minus the space required to map PCI bus addresses. It does not limit the amount of physical RAM that the kernel or applications can use. The 800MB limits how much physical RAM the kernel can leave permanently mapped for access by the kernel. The kernel doesn't permanently map all of physical RAM.
Yes it does unless you compile in high memory support.

Quote:
Instead the kernel temporarily maps individual pages or small ranges of pages when it needs to access the physical RAM. The limited kernel virtual space may affect performance but it doesn't limit the amount of physical RAM.
It does what you say only if you compile in high memory support.

Quote:
The actual physical RAM limit for a 32-bit kernel is 64GB.
Only if you compile in PAE support on top of high memory support. PAE is a kludge. You're better off using 64 bit mode if the hardware allows it.

Quote:
There was very little real need for 64-bit CPU architecture, and there still isn't.
So you say. A lot of people disagree.
 
1 members found this post helpful.
Old 05-03-2013, 05:54 PM   #23
fredak
Member
 
Registered: Apr 2013
Location: Montgeron near Paris
Distribution: Slackware
Posts: 32

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by digger95 View Post
Which windows version were you running and how did it perform with 1GB of RAM?
actually the labtop is about 6 or 7 years old and it had Windows XP on it. It was my wife's. She got sick of its slowliness and bought a new computer. As far as I remember it was slow. I'd say it is now 4 four times faster with linux !
 
Old 05-03-2013, 06:09 PM   #24
fredak
Member
 
Registered: Apr 2013
Location: Montgeron near Paris
Distribution: Slackware
Posts: 32

Original Poster
Rep: Reputation: Disabled
thank you very much for all your replies

as far as I understand there is no hurry switching to a 64bits kernel
 
Old 05-04-2013, 04:37 AM   #25
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
I agree with Martinus2u.

As for performance benefits, there are some benchmarks:
http://www.phoronix.com/scan.php?pag...204_3264&num=1
 
1 members found this post helpful.
Old 05-05-2013, 08:52 AM   #26
chemfire
Member
 
Registered: Sep 2012
Posts: 81

Rep: Reputation: Disabled
64bit mode should be faster; if for no other reason than the doubling of gp registers to 16.
 
Old 05-05-2013, 05:15 PM   #27
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 801

Rep: Reputation: 247Reputation: 247Reputation: 247
Quote:
Originally Posted by H_TeXMeX_H View Post
I agree with Martinus2u.

As for performance benefits, there are some benchmarks:
http://www.phoronix.com/scan.php?pag...204_3264&num=1
After taking a look at the benchmarks, I was puzzled by the huge difference in disk performance between 32-bit and 64-bit. After a little investigation I found that the 64-bit C library memory copying functions have been optimized to use some of the newer instructions. Although those instructions are available to 32-bit CPUs they are not used in 32-bit versions of the C library.

From a performance standpoint that makes 64-bit Linux a much better choice on any CPU that supports it. It looks like more effort is being invested in optimizing 64-bit versions of the C compiler and libraries than 32-bit versions. As time goes on 64-bit software will continue to be developed and 32-bit software will receive less and less attention. That's a practical aspect of 64-bit versus 32-bit that I hadn't considered. It means that 32-bit software will probably never use all of the hardware capabilities of modern CPUs even if it could theoretically come close to 64-bit software performance.
 
2 members found this post helpful.
Old 05-05-2013, 05:29 PM   #28
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,508

Rep: Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800Reputation: 800
As I mentioned I think it's a CPU generational thing -- an AMD64 bit CPU can be guaranteed to have certain features that only "may be" or "ought to be" in x86 CPUs. So, rather than compiling a few different x86 or even i686 versions they code to an average.
 
Old 05-05-2013, 05:36 PM   #29
digger95
Member
 
Registered: Oct 2007
Location: Indiana, PA
Distribution: Slackware 14
Posts: 330

Rep: Reputation: 45
This has been an informative thread and as a result I've decided to stick with Slackware64. Since my machine only has 3GB RAM I assumed that it wouldn't make much difference (and also I'm a little resistant to change) but the bottom line seems to be that if your hardware supports it you should go with 64-bit.

* I will say that flash player seems to perform better in 64-bit but that might just be in my head.
 
  


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 Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
64 bits or 32 bits on AMD athlon x2 ram 4gb? albertoburgos Linux - Newbie 13 08-15-2011 04:37 PM
installing 32 bits distro on turion x2 fujitsu laptop amilo pa 3553 AvalonVrouwe Linux - Newbie 5 10-25-2009 07:55 PM
AMD Turion 64 laptop rntr Linux - Laptop and Netbook 5 08-06-2007 04:54 PM
LXer: AMD Turion 64 X2 LXer Syndicated Linux News 0 07-13-2006 12:54 AM
Best Distro for AMD Turion 64 danishmr Linux - Distributions 1 01-20-2006 09:22 PM


All times are GMT -5. The time now is 06:26 AM.

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration