[wellylug] 32 Bit vs. 64 Bit

[Daniel Pittman]

Gerald Roehrbein <Gerald.Roehrbein at oraforecast.com> writes:

> I've not done assembler programming for 10 years.  I have a lot of old
> books describing assembler mnemonics and machine code instructions
> with the number of machine cycles they need to produce the result.
>
> In the past I used very often the fastest instruction or combination
> of instructions to solve a problem.
>
> Yesterday I searched at Intel for documentation of the 32 Bit and 64
> Bit instruction sets and I found something but in the published
> documentation there is no information about the duration in machine
> cycles of an opcode.
>
> So it seems difficult to compare 32 Bit and 64 Bit machine code.

A little -- but, mostly, they run at about the same general speed.  The
extra registers and other ancillary parts add performance but the core
of the CPU is essentially similar.

[...]

> In general you are right. 64 Bit instructions uses longer
> arguments. 64 Bit registers are longer and operations need probably
> more time (cycles).
>
> The number of IO cycles required to move data from random access
>memory into the CPU took in the past some cycles more for newer
>instructions (Intel 16 Bit instruction set compared with Intel 32 Bit
>instruction set).

That wasn't my point.  My point was this:

  a 8K cache holds 8K of data
         ... holds 2048 32-bit words
         ... holds 1024 64-bit words

That second part, plus the longer immediate values in the instruction
stream and the extra prefixes used occasionally makes your cache fill
faster -- and, therefore, your CPU spend more time waiting for cache
load or store operations to complete.

That is also why code compiled with '-Os', or optimize for smaller size,
is sometimes[1] faster than code compiled to "run fast" by unrolling
loops, etc.


> Oracle describes at Metalink that 32 Bit Oracle is faster as 64 Bit
> Oracle. So in my opinion if there is no requirement to address more
> RAM as possible with 32 Bit (2^32 = 4GB) than using 32 Bit seems to be
> a good option.

Generally, yes.  32-bit software is going to be faster if all other
things are equal; Sparc-64 is a good example of that.  Linux on Sparc is
almost uniformly a 64-bit kernel with a 32-bit userspace -- and a
minimal number of 64-bit userspace programs.

On x86-64 all things are /not/ equal.  You roughly double your number of
general purpose registers as well as being able to assume a bunch more
basic CPU features in 64-bit mode compared to 32-bit mode.

The result of that -- especially as x86 is incredibly starved of
registers, and given that older GCC was not very good at handling
register allocation -- is that x86-64 may be faster than -32 in more
cases...

Which doesn't make it easy. :)

Footnotes: 
[1]  Depending on the test this can be anything up to 100 percent of the
     tested code, so YMMV.  Also, GCC is not very good at optimizing for
     size at this stage, so has room for future improvement.

-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au
                 http://digital-infrastructure.com.au/