Olcol <olcol@cannotspamfree.fr> wrote:
> If I try to summarize:
> 1) 32 bits binaries can run on 64 bits CPUs.

Yes, at least on x86_64.

> 2) They won't run faster than what the frequency of
> those CPUs allows.

In some cases you will see a performance gain when running a 64 bit
binary, in other cases there will be a performance penalty instead.

> 3) If the CPU is an Itanium they surely will run
> slower due to architectural reasons.

Yes, IA64 is optimized for 64 bit binaries and does a bad job running 32
bit binaries.

> 4) The 64 bits binaries are bigger they potentially
> could create bottlenecks over memory bus and CPU
> cache.

Yes, this is the main explanation that you sometimes see better
performance of a 32 bit binary.

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

It is possible to compile a 32 bit kernel i different ways.
Without highmem support it can only address up to 1 GB of RAM.
With highmem4G it can address up to 4 GB of RAM.
With highmem64G it can address up to 64 GB of RAM, however this is done
with a performance penalty.

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

A multi core system could best be described as a multi CPU system which
also is known as an SMP system. Depending on the architecture the
different cores or CPUs might share things like memory buses or cache
memories. However, you need an SMP kernel to take advantage of this and
you will also get the most use of it if you are running multithreaded
applications or several applications at once.

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

I would say that 64 bits will give better performance if you are dealing
with huge amounts of data or if your application are working on 64 bit
data. Integers and floats are usually 32 bits. Double precision floats are
usually 64 bits.

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

"Kees Theunissen" typed:
> Ayaz Ahmed Khan wrote:
>> 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.

The data bus is *usually* as big as the instruction it has to carry. In
the case of a 64-bit long instruction format, the data bus is 64-bit. It
can be smaller than that (for example, a 32-bit bus would take two rounds
to fetch a 64-bit instruction).

--
Ayaz Ahmed Khan

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