Re: Why is the performance of 32bit program worse than 64bit program running on the same 64bit system, They are compiled from same source. Which gcc option can fix it?

[Florian Weimer <fweimer@redhat.com>]

On 03/25/2014 04:51 PM, Vincent Diepeveen wrote:

> a) for example if you use signed 32 bits indexation, for example
>
> int i, array[64];
>
> i = ...;
> x = array[i];
>
> this goes very fast in 32 bits processor and 32 bits mode yet a lot
> slower in 64 bits mode, as i needs a sign extension to 64 bits.
> So the compiler generates 1 additional instruction in 64 bits mode
> to sign extend i from 32 bits to 64 bits.

Is this relevant in practice?  I'm asking because it's a missed 
optimization opportunity—negative subscripts lead to undefined behavior 
here, so the sign extension can be omitted.

> b) some processors can 'issue' more 32 bits instructions a clock than 64
> bits instructions.

Some earlier processors also support more µop optimization in 32 bit mode.

> My chessprogram Diep which is deterministic integer code (so no vector
> codes) compiled 32 bits versus 64 bits is about 10%-12% slower in 64
> bits than in 32 bits. This where it does use a few 64 bits datatypes
> (very little though). In 64 bits the datasize used doesn't grow,
> instruction wise it grows immense of course.

Well, chess programs used to be the prototypical example for 64 bit 
architectures ...

> Besides the above reasons another reason why 32 bits programs compiled
> 64 bits can be a lot slower in case of Diep is:
>
> c) the larger code size causes more L1 instruction cache misses.

This really depends on the code.  Not everything is larger.  Typically 
it's the increased pointer size that cause increased data cache misses, 
which then casues slowdowns.

-- 
Florian Weimer / Red Hat Product Security Team