Should I install a 32 bit or 64 bit system?

I have an older Netbook, a Gateway LT2022U Netbook, which includes an AMD Atholon chip capable of 64bit, but the system is maxed out with 2 GB of RAM.

I am looking at refreshing it, and possibly making it dual-boot with Windows 7 (it originally came with Windows Vista Basic ). Currently it has a 64-bit version of Linux. Looking at the system requirements for Windows I noticed 32bit requires 1 GB of RAM while 64bit requires 2! This got me thinking

  • On a low-powered system like this, would there be any benefit to going 32bit instead of 64bit Linux?
  • Should I look at using a 32bit version of Linux even though the chip can take 64bit?
  • Is there a benefit to installing the 64bit version of Linux?

Performance with the 64 bit and Xfce is adequate at this point. I would love to run Gnome shell on it but the system generally doesn’t handle Gnome well (with a Live USB)

Not all that much difference. What you will want probably is a light weight desktop rather then Gnome or KDE. But not knowing the exact processor it is hard to tell. If me I’d install 64 bit if the processor will handle it.

On 2014-10-08, dragonbite <dragonbite@no-mx.forums.opensuse.org> wrote:
> - On a low-powered system like this, would there be any benefit to
> going 32bit instead of 64bit Linux?

No. If your chipset supports it, use 64-bit. You won’t see any performance improvement if you resort to 32-bit.

> - Should I look at using a 32bit version of Linux even though the chip
> can take 64bit?

No. A situation where it’s worth considering installing a 32-bit version of Linux is within a VM, but I’m guessing your
chip doesn’t support virtualisation.

> - Is there a benefit to installing the 64bit version of Linux?

Yes. Lots. It’s not just memory addressing that distinguishes the architecture. The repertoire of machine instructions
for 64-bit architectures is more extensive than that of 32-bit archectures, and 32-compiles won’t take advantage of the
extra CPU registers available on 64-bit architectures.

> Performance with the 64 bit and Xfce is adequate at this point. I would
> love to run Gnome shell on it but the system generally doesn’t handle
> Gnome well (with a Live USB)

I have a 7-year old 32-bit laptop running openSUSE_13.1_ix86_KDE completely smoothly so your newer 64 bit laptop will be
fine. I’d ditch your Windows Vista. A Windows 7 purchase for this machine would probably not be a good investment
(although arguably the cheaper Windows 8 may have a stronger case). The real question is what do you want to use the
laptop for? If only for casual things like emails/internet/documents/media playback, I’d probably just stick openSUSE
13.1 KDE 64 bit on it. If you’re worried about DE performance, you might want to consider Linux Mint 17 MATE. If in
addition however, you need MS Office or Direct3D games, then you might want to consider dual-booting it with Windows 8.

On 2014-10-08 15:36, dragonbite wrote:

> - On a low-powered system like this, would there be any benefit to
> going 32bit instead of 64bit Linux?

Some, yes. A 32 bit system typically uses less memory (depends on the app).

Basic idea: if you recompile the application for 64 bit,
“integers” automatically double in size, even if they do
not need that size. Thus programmers have to learn the
trick of telling the compiler that they can make do with
smaller integers.

> - Should I look at using a 32bit version of Linux even though the chip
> can take 64bit?

I would.

> - Is there a benefit to installing the 64bit version of Linux?

No, unless you use apps that really benefit from 64 bit processing. Say
video manipulation, math, engineering, etc. And those that do not use
lots of memory, just heavy processing.

However, the 32 bit version is getting less testing, so more bugs get
through. Previously it was the other way round, the 64 bit version had
more bugs.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I have an older Dell Dimension C521, with Athlon processor and 2G of memory. It is working pretty well with 64-bit. As it happens, I also have the 32-bit opensuse-li-f-e (linux for education) on an alternate partition. And I don’t think I have noticed any difference between 32bit and 64bit, with respect to performance.

Looking around, I am not sure if it is a Gateway LT2022u, or a Gateway LT3103u. I am leaning towards to 3103 currently. Regardless, I know it is running the AMD Athlon 64 chip at about 1.2 GHz.

It is a handy portable system to carry around for taking notes, email, browsing, remote desktop & SSH, video chat and non-intensive gaming.

I already have a 32bit Windows 7 Enterprise disk, otherwise I would skip it. I’m not plan on purchasing Windows for it.

I’ve had luck with SUSE and KDE on an OLD system (“Pentium w/MMX”) so I am thinking maybe I’ll give it a shot here. It doesn’t like Gnome, but KDE might actually work well with it. Currently it is running Xubuntu 64-bit.

It’s just whether I should go with 32- or 64-bit.

On 2014-10-08, Carlos E. R. <robin_listas@no-mx.forums.opensuse.org> wrote:
> Basic idea: if you recompile the application for 64 bit,
> “integers” automatically double in size, even if they do
> not need that size. Thus programmers have to learn the
> trick of telling the compiler that they can make do with
> smaller integers.

Who told you that? Most of Linux is written in C, but its integer datatypes (e.g. char', short’, int', and long’)
don’t suddenly change in size just because you’ve change from 32-bit to 64-bit! Sure, the general purpose CPU registers
accommodate the double the size, but when assembling with respect to 32-bit addresses, 64-bit registers just use their
lower half and this incurs no memory overhead! It’s true that some compilers sneakly switch the FPU from 32-bit to
64-bit floating point operations without telling you (single FLOPs are sometimes often slower than double for this
reason), but that’s as true for 32-bit architectures as it is for 64-bit…

On 2014-10-08 17:22, flymail wrote:
> On 2014-10-08, Carlos E. R. <> wrote:

>> Basic idea: if you recompile the application for 64 bit,
>> “integers” automatically double in size, even if they do
>> not need that size. Thus programmers have to learn the
>> trick of telling the compiler that they can make do with
>> smaller integers.
>
> Who told you that?

I verified it myself.

There was a thread somewhere about the issue, and we wrote code to
verify it. Some programs simply used double ram when compiled for a 64
bit processor. The defaults they used years ago when they were written,
perhaps before 64 bit cpus were (commonly) available, made the compiler
use the larger register and integer size available.

Yes, it is a mistake in coding. But it does exist.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Well, just verified it is an LT3103u.

The only upgrade I think I can do to this machine would be to give it an SSD hard drive.

On 2014-10-08, Carlos E. R. <robin_listas@no-mx.forums.opensuse.org> wrote:
> The defaults they used years ago when they were written,
> perhaps before 64 bit cpus were (commonly) available, made the compiler
> use the larger register and integer size available.

There are no larger' or smaller’ registers on the same CPU: all general purpose registers are the same size, whether
32-bit or 64-bit. Of course it is possible to fill the lowest 16-bits of either register size or the lowest 32-bits of a
64-bit register, but they are not separate registers.

On 2014-10-08, Carlos E. R. <robin_listas@no-mx.forums.opensuse.org> wrote:
> On 2014-10-08 17:22, flymail wrote:
>> On 2014-10-08, Carlos E. R. <> wrote:
>
>>> Basic idea: if you recompile the application for 64 bit,
>>> “integers” automatically double in size, even if they do
>>> not need that size. Thus programmers have to learn the
>>> trick of telling the compiler that they can make do with
>>> smaller integers.
>>
>> Who told you that?
>
> I verified it myself.

Sorry, I do not understand, and I cannot see how what you say can be true for C code. Consider the following program:


# include <stdio.h>

int main() {
int data[2];
printf("Bytes used by int data type: %d
", (char*)&data[1] - (char*)&data[0]);
return 0;
}

The 32-bit compile generates this assembler:


sh-4.2$ gcc -m32 -save-temps a.c
sh-4.2$ cat a.s
.file   "a.c"
.section        .rodata
.align 4
..LC0:
.string "Bytes used by int data type: %d
"
.text
.globl  main
.type   main, @function
main:
..LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl    %esp, %ebp
.cfi_def_cfa_register 5
andl    $-16, %esp
subl    $32, %esp
movl    $4, 4(%esp)
movl    $.LC0, (%esp)
call    printf
movl    $0, %eax
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
..LFE0:
.size   main, .-main
.ident  "GCC: (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]"
.section        .note.GNU-stack,"",@progbits

… which as you can see is 100% 32-bit code. Now if we compile in 64-bit:


sh-4.2$ gcc -m64 -save-temps a.c
sh-4.2$ cat a.s
.file   "a.c"
.section        .rodata
.align 8
..LC0:
.string "Bytes used by int data type: %d
"
.text
.globl  main
.type   main, @function
main:
..LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq    %rsp, %rbp
.cfi_def_cfa_register 6
subq    $16, %rsp
movl    $4, %esi
movl    $.LC0, %edi
movl    $0, %eax
call    printf
movl    $0, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
..LFE0:
.size   main, .-main
.ident  "GCC: (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]"
.section        .note.GNU-stack,"",@progbits

Now let’s have a stack size comparing the two stack pointer register substractions:


subl    $32, %esp
subq    $16, %rsp

So someone might say “Aha! the 32-bit instruction subtracts a long (subl) whereas the 64-bit instructions substracts a
quad (subq)”. But you’ll also see the minuend is halved from $32 to $16 in correspondence - in other words there’s no
difference in stack size usage. On a more subtle note, you may notice other differences in the generated assembler
associated with byte alignment, but that will have little effect on the memory load. But the real proof that integer
data type sizes remained unchanged is in the running of the program comparing the 32-bit and 64-bit compiles:


sh-4.2$ gcc -m32 -save-temps a.c
sh-4.2$ ./a.out
Bytes used by int data type: 4
sh-4.2$ gcc -m64 -save-temps a.c
sh-4.2$ ./a.out
Bytes used by int data type: 4
sh-4.2$

As you can see: no difference. Or am I missing something?

On 2014-10-08, Carlos E. R. <robin_listas@no-mx.forums.opensuse.org> wrote:
> The defaults they used years ago when they were written,
> perhaps before 64 bit cpus were (commonly) available, made the compiler
> use the larger register and integer size available.

There are no larger' or smaller’ registers on the same CPU: all general purpose registers are the same size, whether
32-bit or 64-bit. Of course it is possible to fill the lowest 16-bits of either register size or the lowest 32-bits of a
64-bit register, but they are not separate registers.

On 2014-10-08, Carlos E. R. <robin_listas@no-mx.forums.opensuse.org> wrote:
> On 2014-10-08 17:22, flymail wrote:
>> On 2014-10-08, Carlos E. R. <> wrote:
>
>>> Basic idea: if you recompile the application for 64 bit,
>>> “integers” automatically double in size, even if they do
>>> not need that size. Thus programmers have to learn the
>>> trick of telling the compiler that they can make do with
>>> smaller integers.
>>
>> Who told you that?
>
> I verified it myself.

Sorry, I do not understand, and I cannot see how what you say can be true for C code. Consider the following program:


# include <stdio.h>

int main() {
int data[2];
printf("Bytes used by int data type: %d
", (char*)&data[1] - (char*)&data[0]);
return 0;
}

The 32-bit compile generates this assembler:


sh-4.2$ gcc -m32 -save-temps a.c
sh-4.2$ cat a.s
.file   "a.c"
.section        .rodata
.align 4
..LC0:
.string "Bytes used by int data type: %d
"
.text
.globl  main
.type   main, @function
main:
..LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl    %esp, %ebp
.cfi_def_cfa_register 5
andl    $-16, %esp
subl    $32, %esp
movl    $4, 4(%esp)
movl    $.LC0, (%esp)
call    printf
movl    $0, %eax
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
..LFE0:
.size   main, .-main
.ident  "GCC: (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]"
.section        .note.GNU-stack,"",@progbits

… which as you can see is 100% 32-bit code. Now if we compile in 64-bit:


sh-4.2$ gcc -m64 -save-temps a.c
sh-4.2$ cat a.s
.file   "a.c"
.section        .rodata
.align 8
..LC0:
.string "Bytes used by int data type: %d
"
.text
.globl  main
.type   main, @function
main:
..LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq    %rsp, %rbp
.cfi_def_cfa_register 6
subq    $16, %rsp
movl    $4, %esi
movl    $.LC0, %edi
movl    $0, %eax
call    printf
movl    $0, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
..LFE0:
.size   main, .-main
.ident  "GCC: (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]"
.section        .note.GNU-stack,"",@progbits

Now let’s have a stack size comparing the two stack pointer register substractions:


subl    $32, %esp
subq    $16, %rsp

So someone might say “Aha! the 32-bit instruction subtracts a long (subl) whereas the 64-bit instructions substracts a
quad (subq)”. But you’ll also see the minuend is halved from $32 to $16. On a more subtle note, you may notice other
differences in the generated assembler associated with byte alignment, but that will have little effect on the memory
load. But the real proof that integer data type sizes remained unchanged is in the running of the program comparing the
32-bit and 64-bit compiles:


sh-4.2$ gcc -m32 -save-temps a.c
sh-4.2$ ./a.out
Bytes used by int data type: 4
sh-4.2$ gcc -m64 -save-temps a.c
sh-4.2$ ./a.out
Bytes used by int data type: 4
sh-4.2$

As you can see: no difference. Or am I missing something?