Slackware 64 or 32 bits on AMD Turion 64 X 2 ?
 

hello
I've been working in the IT since 20 years and I have always use unix, first at the university and then at work. I am a basic user, I know the commands, how to write shells, etc, but I never had to install, configure etc. Since a few weeks I've decided to put Linux on my home computer and get rid of windows and I am now dealing with all the installations and configurating issues. In french we say "petit à petit l'oiseau fait son nid" which means literally "little by little, the bird makes its nest", that what's what it is happening to me right now.

Let's get to the point : a friend of mine suggested I should install Slackware 14.0 32 bits. he told me since I have only 1 Gb RAM I shouldn't put a 64 bits OS.

But still, since the sticker on my labtop says : "AMD Turion 64 X 2" which means I guess that I have a double core 64bits processor, I am really wondering :

should I install the 64 bits OS ?

First observation: it is main memory plus swap space you need to consider, as the 64 bit question is about the virtual process address space more than the physical memory. However, if you use large amounts of swap you won't be happy with the machine, I promise.

Second observation: a 32 bit kernel can address around 896 MB physical RAM unless large memory support is enabled (which would be the case in the Slackware stock kernel)

Third observation: 64 bit applications can use more and longer registers, but pointer variables are longer. Still, most applications perform a little bit better in 64 bit.

So maybe the best advice is: if you can upgrade the memory, do it, and go 64 bit. Otherwise stay with 32 bit.

Which windows version were you running and how did it perform with 1GB of RAM?

I've had both versions of Slackware 14 on my low-end machine (Sempron 140 + 3GB RAM) and to be honest I haven't really noticed much of a difference between the two. If I were to reinstall today I'd just stick with the 32-bit version and that way I wouldn't have to deal with the whole multilib business. Yeah, I know I'm lazy. :)

I run both Slackware 32bit and Slackware 64bit on a machine with 1GB RAM. I think the 64bit version boots a bit faster (but have never actually measured it). In general operation, there is no noticeable difference. The only issue I have had with running 64bit is with my printer; the driver is 32 bit only, so I need to add the glibc-solibs-2.17_multilib-x86_64-2alien.txz and cups-compat32-1.5.4-x86_64-2compat32.txz packages from http://taper.alienbase.nl/mirrors/pe...lien/multilib/ to use the printer in Slackware 64bit.
It really comes down to the software that you want to run. There are some programs, e.g. Skype, that are only available in 32bit versions. I also use one program that is only available in a 64bit version. Some calculation intensive programs seem to run a bit faster in 64bit.

Are you sure? I was under the impression it was about 3.8GB?

Member Response
 

Hi,

Welcome to LQ!

Personally I use both x86_32 & x86_64 on similar hardware. I do not use multilib on older 64 machines. You could do a install for 32 & 64 on the machine or use 64 with multilib. I keep my installs vanilla except when I need a special bench setup.

Look at Slackware Doc Project & for Configure your new Slackware System to aid you.

Hope this helps!

If it was me... I'd install Slackware64 simply because it's a 64-bit capable machine. The machine I typing on right now is an "Intel Centrino Dual Core" with Slackware64-current. I do have a bit more memory that 1GB though, 3GB. That said, I'd still install Slackware64, even with only 1GB.

I think you can safely install slackware64, and if you need 32-bit software, just use multilib. It's true that installing slackware32 will probably be less of a hassle. It's your choice. Overall I think there will be a performance benefit if you use 64-bit.

I think maybe only the kernel itself addresses 896 MB but I don't even get how that's how relevant to userland operation.

Having this exact same processor myself (in my el-cheapo Wal-Mart post-Christmas Acer laptop special from 4 years ago or so), I think I can add a bit here: being AMD, it is 64 bit native with 32 bit emulation (in microcode?) so for basic tasks you won't see much of a difference. You WILL see a small, but noticable difference in high end tasks like games, booting up, and so on: I personally notice the biggest difference with my NVIDIA IGP, which definitely seems to prefer being fed natively 64 bit (bigger registers?).

Also remember that with Slackware, you can go multi-library with Eric's (Alien Bob) multi-lib packages; I leave it to you to determine if it's worth the effort.

The catch with going 64 bit is some native 32 bit apps (especially Wine) and code that is physically larger, thus needing more memory and possibly resulting in more cache misses (AMD desktop/mobile procs have tiny caches). My machine came with 2GB of RAM and I have never needed to expand it (only the GIMP has ever maxxed it out). In use it usually hangs out around 500-600 MB, but then again I'm running Xfce, not KDE. YMMV.

My advice: if you've been using it and not maxxing out your RAM, then why invest another penny? If you are hitting it, you need to decide if upgrading the RAM is more worthwhile than buying a new machine. Remember that the Turion X2 is around 5 years old now, and while ok for office stuff and light graphics, is not sufficient for major gaming (although this is more determined by your GPU, which is probably an IGP if you have this processor); it's also not terribly power efficient.

One last thing if you are thinking about new hardware: work is ongoing to get Armed Slack aka Slackware-ARM to work on the ARM Chromebook--for non-gaming stuff this could be huge with amazing battery life that can't be had on the PC (WIntel) architecture. See here:http://alien.slackbook.org/blog/armport

Hope this helps, Mike

It won't make a lot of difference in performance whether you use a 32-bit kernel or a 64-bit kernel. The 64-bit software may be slightly faster because the 64-bit execution has probably been optimized in the CPU. The 64-bit software will also be slightly larger, though it isn't twice as big. There are only a few situations where addresses and data with small values absolutely have to be stored as 64 bits.

With 1GB of physical RAM I recommend using a 32-bit kernel. The programs will be slightly smaller, and you won't have two copies of libraries loaded when running a 32-bit program (and a 64-bit program). KDE uses a lot of RAM. The 64-bit version of KDE will use a little bit more than the 32-bit version.

With a 32-bit kernel, a single process (task) can directly access up to 3GB of memory. Very few programs need to directly access more than 3GB of RAM. A process uses the other 1GB to access software and data in the kernel. A process can also re-map the 3GB of addressing to access more than 3GB of physical RAM.

The 32-bit Linux kernel can support up to 64GB of physical RAM with PAE (Physical Address Extension). The 64GB is shared between all the processes and the kernel. So, it is not necessary to use a 64-bit kernel to access all the RAM even with more than 4GB. This is different than Windows. Windows 32-bit versions are limited to 4GB of physical RAM because Microsoft never fully implemented support for PAE. Windows only supports the "no execute" bit for PAE, and not the extra four address bits.

You are going to hear a lot of misinformation about 64-bit. Most of the benefit from 64-bit is because of the newer hardware designs and not because of running 64-bit software. Running 64-bit software provides only a slight benefit for most things. Some really well written and optimized 64-bit software may be a lot faster, but that is usually the exception to the rule.

There are a few drivers and programs that still do not support 64-bit Linux. Those are usually older software. So 32-bit has slightly better compatibility with software.

You might want to use a 64-bit kernel because that will eventually be the standard. If your computer is new, you will want to find out about any 64-bit problems now, rather than later. If performance is your main goal, then definitely use 64-bit. Anything that moves large amounts of data around, such as large file copying and graphics will be slightly faster.

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 am. Reason being that linux implements the unix principle of the monolithic block, meaning the kernel address space is part of the address space of every running process (even though the access is protected by the MMU). Without high mem support the kernel maps the entire physical memory into the kernel address space. Oh, and the standard split of the 4GB process address space is 3 GB user, 1 GB kernel.

Your statement about 3.8GB or thereabouts (depending on the hardware) is correct once you enable high mem support (without PAE which enables up to 64 GB).

Ah, yes, I forgot about the 1:3 split.

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.

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.)

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.

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.

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.

Yes it does unless you compile in high memory support.

It does what you say only if you compile in high memory support.

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.

So you say. A lot of people disagree.

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 !

thank you very much for all your replies

as far as I understand there is no hurry switching to a 64bits kernel

I agree with Martinus2u.

As for performance benefits, there are some benchmarks:
http://www.phoronix.com/scan.php?pag...204_3264&num=1

64bit mode should be faster; if for no other reason than the doubling of gp registers to 16.

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.

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.

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.