Hello,

I'll soon buy a laptop, most of those i've taken a look at
are running 64 bits processors.

I'd like to continue using Slackware on them as I do now whith
my "old" i586, is there any problem with that (e.g. kernel, libraries,
binaries...)?

I'm particularly interrested in buying a machine running
an Intel Core duo processor, thanks in advance for your
explanations about possible issues and use of SMP whith
this type of machine.

Sorry if the subject has already been treated.

Olcol

olcol <olcol@cannotspamfree.fr> wrote:
> I'll soon buy a laptop, most of those i've taken a look at
> are running 64 bits processors.
>
> I'd like to continue using Slackware on them as I do now whith
> my "old" i586, is there any problem with that (e.g. kernel, libraries,
> binaries...)?

No, there is no problem. Those CPUs are fully 32 bit backwards compatible
and are capable of running a 32 bit operating system at full performance.
The big advantage of running a 64 bit operating system like slamd64 comes
if you have more than 4 GB of RAM in the computer.

> I'm particularly interrested in buying a machine running
> an Intel Core duo processor, thanks in advance for your
> explanations about possible issues and use of SMP whith
> this type of machine.

Default Slackware kernels does not have support for SMP compiled in. The
old solution for this has been to recompile your own kernel and kernel
modules with support for SMP. However, in Slackware 11 in the extra
directory there is a directory called linux-smp-2.6.17.13. That directory
contains a precompiled kernel and modules with SMP support.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net root@localhost

Le Sun, 17 Dec 2006 02:15:26 +0100, Henrik Carlqvist a écrit*:

> olcol <olcol@cannotspamfree.fr> wrote:
>> I'll soon buy a laptop, most of those i've taken a look at
>> are running 64 bits processors.
>>
>> I'd like to continue using Slackware on them as I do now whith
>> my "old" i586, is there any problem with that (e.g. kernel, libraries,
>> binaries...)?
>
> No, there is no problem. Those CPUs are fully 32 bit backwards compatible
> and are capable of running a 32 bit operating system at full performance.
> The big advantage of running a 64 bit operating system like slamd64 comes
> if you have more than 4 GB of RAM in the computer.
>

Could you explain me more about that? Is it all about the capacity
of adressing memory? I thought that 64 bits binaries would be running
faster on a 64 bits processor than "same" 32 bits binaries on a 32 bits
processor...

>> I'm particularly interrested in buying a machine running an Intel Core
>> duo processor, thanks in advance for your explanations about possible
>> issues and use of SMP whith this type of machine.
>
> Default Slackware kernels does not have support for SMP compiled in. The
> old solution for this has been to recompile your own kernel and kernel
> modules with support for SMP. However, in Slackware 11 in the extra
> directory there is a directory called linux-smp-2.6.17.13. That
> directory contains a precompiled kernel and modules with SMP support.
>
> regards Henrik

Thank you very much Henrik,

Olcol

Olcol <olcol@cannotspamfree.fr> wrote:
>> Those CPUs are fully 32 bit backwards compatible and are capable of
>> running a 32 bit operating system at full performance. The big
>> advantage of running a 64 bit operating system like slamd64 comes if
>> you have more than 4 GB of RAM in the computer.

> Could you explain me more about that? Is it all about the capacity of
> adressing memory?

Mostly yes. A CPU operating in full 64 bit mode uses 64 bits do describe
every address. Compared to 32 bit mode this means two things:

1) To load an address you will have to fetch twice as much data from RAM
(64 bits instead of 32 bits).

2) You are able to represent a much bigger memory space. 32 bits are able
to address 2^32 different addresses which translates to roughly 4000000000
different addresses. 64 bits are able to address 2^64 different addresses
which translates to roughly 16000000000000000000 different addresses. This
is a bit of oversimplification, for instance, on a highmem kernel with
support for up to 4 GB of RAM a single process can not address more than 2
GB.

> I thought that 64 bits binaries would be running faster on a 64 bits
> processor than "same" 32 bits binaries on a 32 bits processor...

As you understand from the two points above it could even be less
performance on the 64 bit code as it has to handle twice as much data. If
you compare the size of a binary or library for a 64 bit architecture with
the size of the "same" binary for a 32 bit architecture you will most
likely find that the 32 bit binary is smaller. Example:

$ tar -tzvf coreutils-5.97-x86_64-3.tgz | grep bin/ls
-rwxr-xr-x root/root 81992 2006-08-09 16:28:33 bin/ls
$ tar -tzvf coreutils-5.97-i486-1.tgz | grep bin/ls
-rwxr-xr-x root/root 72468 2006-06-25 03:59:26 bin/ls
$ tar -tzvf glibc-solibs-2.3.6-x86_64-8.tgz | grep libc-2
-rwxr-xr-x root/root 1495098 2006-06-14 04:38:14 lib64/.../libc-2.3.6.so
-rwxr-xr-x root/root 1487812 2006-06-14 04:38:14 lib64/.../libc-2.3.6.so
$ tar -tzvf glibc-solibs-2.3.6-i486-6.tgz | grep libc-2
-rwxr-xr-x root/root 1441201 2006-09-14 09:54:43 lib/.../libc-2.3.6.so
-rwxr-xr-x root/root 1421670 2006-09-14 09:54:43 lib/.../libc-2.3.6.so

Bigger binaries means more data over your memory bus which might become a
bottleneck. It also means that your CPUs cache gets filled up more quickly.

>>> I'm particularly interrested in buying a machine running an Intel Core
>>> duo processor, thanks in advance for your explanations about possible
>>> issues and use of SMP whith this type of machine.

The Core duo is able to run 32 bit code at full speed. The old intel 64
bit archtecture IA64 was only able to run 32 bit code at very low speed.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net root@localhost

"Henrik Carlqvist" typed:
> Olcol <olcol@cannotspamfree.fr> wrote:
>> I thought that 64 bits binaries would be running faster on a 64 bits
>> processor than "same" 32 bits binaries on a 32 bits processor...
>
> As you understand from the two points above it could even be less
> performance on the 64 bit code as it has to handle twice as much data. If
> you compare the size of a binary or library for a 64 bit architecture with
> the size of the "same" binary for a 32 bit architecture you will most
> likely find that the 32 bit binary is smaller. Example:
>
> $ tar -tzvf coreutils-5.97-x86_64-3.tgz | grep bin/ls
> -rwxr-xr-x root/root 81992 2006-08-09 16:28:33 bin/ls
> $ tar -tzvf coreutils-5.97-i486-1.tgz | grep bin/ls
> -rwxr-xr-x root/root 72468 2006-06-25 03:59:26 bin/ls
> $ tar -tzvf glibc-solibs-2.3.6-x86_64-8.tgz | grep libc-2
> -rwxr-xr-x root/root 1495098 2006-06-14 04:38:14 lib64/.../libc-2.3.6.so
> -rwxr-xr-x root/root 1487812 2006-06-14 04:38:14 lib64/.../libc-2.3.6.so
> $ tar -tzvf glibc-solibs-2.3.6-i486-6.tgz | grep libc-2
> -rwxr-xr-x root/root 1441201 2006-09-14 09:54:43 lib/.../libc-2.3.6.so
> -rwxr-xr-x root/root 1421670 2006-09-14 09:54:43 lib/.../libc-2.3.6.so
>
> Bigger binaries means more data over your memory bus which might become a
> bottleneck. It also means that your CPUs cache gets filled up more quickly.

I may be wrong, but the only way *I* see how a 64-bit proc boosts
performance is by supporting a bigger RAM (and, perhaps, larger internal
caches). The instruction format the 64-bit proc supports has been extended
to accomodate another 32-bits, a large portion of which bits supplement
the total bits used for addressing. There might well be an increase in the
instruction set (perhaps providing with more optimised instructions).
Unless the RAM gets any faster, accesses to RAM are still slower than the
speeds at which the proc operates (which is why there are intermediary
internal caches to cut down to as much extent as is possible the
bottlenecks imposed by slower speeds of memory access), and unless the
caches are getting bigger and cheaper, I don't see how else a 64-bit proc
would significantly affect performance.

--
Ayaz Ahmed Khan

It is impossible to defend perfectly against the attack of those who
want to die.

Ayaz Ahmed Khan wrote:
> "Henrik Carlqvist" typed:
>> Olcol <olcol@cannotspamfree.fr> wrote:
>>> I thought that 64 bits binaries would be running faster on a 64 bits
>>> processor than "same" 32 bits binaries on a 32 bits processor...
>> As you understand from the two points above it could even be less
>> performance on the 64 bit code as it has to handle twice as much data. If
>> you compare the size of a binary or library for a 64 bit architecture with
>> the size of the "same" binary for a 32 bit architecture you will most
>> likely find that the 32 bit binary is smaller. Example:
>>
>> $ tar -tzvf coreutils-5.97-x86_64-3.tgz | grep bin/ls
>> -rwxr-xr-x root/root 81992 2006-08-09 16:28:33 bin/ls
>> $ tar -tzvf coreutils-5.97-i486-1.tgz | grep bin/ls
>> -rwxr-xr-x root/root 72468 2006-06-25 03:59:26 bin/ls
>> $ tar -tzvf glibc-solibs-2.3.6-x86_64-8.tgz | grep libc-2
>> -rwxr-xr-x root/root 1495098 2006-06-14 04:38:14 lib64/.../libc-2.3.6.so
>> -rwxr-xr-x root/root 1487812 2006-06-14 04:38:14 lib64/.../libc-2.3.6.so
>> $ tar -tzvf glibc-solibs-2.3.6-i486-6.tgz | grep libc-2
>> -rwxr-xr-x root/root 1441201 2006-09-14 09:54:43 lib/.../libc-2.3.6.so
>> -rwxr-xr-x root/root 1421670 2006-09-14 09:54:43 lib/.../libc-2.3.6.so
>>
>> Bigger binaries means more data over your memory bus which might become a
>> bottleneck. It also means that your CPUs cache gets filled up more quickly.
>
> I may be wrong, but the only way *I* see how a 64-bit proc boosts
> performance is by supporting a bigger RAM (and, perhaps, larger internal
> caches). The instruction format the 64-bit proc supports has been extended
> to accomodate another 32-bits, a large portion of which bits supplement
> the total bits used for addressing. There might well be an increase in the
> instruction set (perhaps providing with more optimised instructions).
> Unless the RAM gets any faster, accesses to RAM are still slower than the
> speeds at which the proc operates (which is why there are intermediary
> internal caches to cut down to as much extent as is possible the
> bottlenecks imposed by slower speeds of memory access), and unless the
> caches are getting bigger and cheaper, I don't see how else a 64-bit proc
> would significantly affect performance.
>

Just a question, I never invested any time to look at this.
Is the data-bus, external to the CPU, also 64 bits wide?
A 64 bits wide memory bus would double the speed of block transfers
compared to 32 bits buses. Fetching instructions from memory would
also be faster.

Regards,

Kees.

--
Kees Theunissen.

Olcol <olcol@cannotspamfree.fr> wrote:
> Could you explain me more about that? Is it all about the capacity
> of adressing memory? I thought that 64 bits binaries would be running
> faster on a 64 bits processor than "same" 32 bits binaries on a 32 bits
> processor...

No, actually a bit slower. The "x86-64" cpu is actually a Pentium, extended
with 64-bit MEMORY addressing, so it is in itself not faster then a Pentium
(even slower as the clock speed mostly IS less), but can address much more
memory (but memory pointers are larger, so take up more space and loading
time). The "real" 64-bits cpu is the Intel Itanium, which is a completely
redesigned cpu (and IT runs 32-bits programs much slower).

The Intel Core 2 processors are TWO "x86-64" cores in a single chip, but
with only a single way out to the memory and I/O bus (it does have separate
L2 caches, as far as I know, though).

>>> I'm particularly interrested in buying a machine running an Intel Core
>>> duo processor, thanks in advance for your explanations about possible
>>> issues and use of SMP whith this type of machine.

You will need a SMP enabled kernel to really make use of that cpu, and
even then it only works for "multiple processes", as normal applications
are not parallel, so will run on a single core only (but two "cpu using"
applications can then each run on a different core).
As far as I understand it this is even true for multi-threaded processes,
as the threads run from the same in-memory code and share their data
segment (which means that the L2 cache from "core 2" is not updated
when "core 1" writes some data).
But I could be wrong, of course, not all that much experience here yet
with Core 2 machines (we only got 2, for about 2 weeks, now).
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************

Kees Theunissen <theuniss@rijnh.nl> wrote:
> Just a question, I never invested any time to look at this.
> Is the data-bus, external to the CPU, also 64 bits wide?

I'm skating on thin ice now, but I always understood the PCI (and AGP)
busses already _were_ 64-bits, as FLOATING point numbers could be
handled in 64-bits already.
According to a document I found in Google (probably a bit out of data):
> The PCI bus supports a 64 bit I/O address space, although this is not
> available on Intel based PCs due to limitations of the CPU.
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************

Thank you all for all those very interesting posts.

If I try to summarize:

1) 32 bits binaries can run on 64 bits CPUs.
2) They won't run faster than what the frequency of
those CPUs allows.
3) If the CPU is an Itanium they surely will run
slower due to architectural reasons.
4) The 64 bits binaries are bigger they potentially
could create bottlenecks over memory bus and CPU
cache.
5) You can't adress more than 4 Gb of RAM with a 32 bits
CPU, to go beyond this limit at the present time you
have to use a 64 bits CPU.
6) On dual 64 bits CPUs there won't be any parallelism except
if implemented in the code. Multi-threading is not
parallelism.Processs will be managed by only one CPU
which in turn manages only one L2 cache.
7) You can obtain a performance gain using 64 bits CPU
if memory speed, memory bus, data bus and CPU's cache
size are ad-hoc engineered and there's no evidence it
is the case.

Right?

Olcol <olcol@cannotspamfree.fr> wrote:
> 5) You can't adress more than 4 Gb of RAM with a 32 bits
> CPU, to go beyond this limit at the present time you
> have to use a 64 bits CPU.

You actually CAN (see the kernel CONFIG_HIGHMEM64G variable), but
then the memory will be adressed in a "segmented" way (that is, with
pointers that consist of a segment and a offset value, the latter will
be a full 32-bit number, the segment will NOT).
Of course your motherboard does have to support "that much" memory too.
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************