Stephan Wiesand wrote:

> Hi Yannick,
>
>
Hi,

> This is not what I see at least on my single CPU P4 (things may be
> different on a dual Opteron though):
>
> OS    app    root 4.00.08 stress ROOTmarks
> ==    ==    =============================
> 64    64    1056.7 1047.9 1059.8
> 64    32    942.5 945.7 942.5
> 32    32    945.0 945.0 947.2

>
> I'll do some more of these measurements eventually, with different
> applications and also on dual Opterons.
>
>> Anyone has an idea of the reason ?
>
>
> There's an overhead for 32-bit system calls. The 64-bit kernel
> has additional entry points for those, and the input parameters and
> values
> returned have to be converted. x86_64 has hardware instructions tailored
> for doing this, but - depending on the application - it may become
> significant.

Ok. I suspected such things but I wonder if someone got ways
to reduce the problem.

>
> Which kind of programmes did you try? How long do they take to run?

It is tested with a set of real jobs that are scheduled on our
farm. These jobs are choosen because they need many CPU
(we also have test jobs that need many I/O).
Each job runs at least one hour, often several hours.

In fact we were trying that in order to decide wether we install
64+32 everywhere or just pure 32. We do not have for the moment
an heavy demand for 64 bits computation, so most of our jobs will
be 32 bits, and it don't seems to be efficient to use 64+32 for the
whole farm...

>
>> -> installing 32 bits over 64 bits:
>>
>> The "magic" way to do it is to use the option
>> '--excludepath=XXX' many times. I used a set of
>> 'excludepath' in order to prevent installation on each
>> directory that is not supposed to get libraries (it
>> would have been easier if a '--onlypath=XX' had
>> existed).
>
>
> Works nicely. The excluded files are not only not installed, they're
> also not removed when the i386 package is erased. Now all we need is
> a way to teach yum how to do this, during installation and updates ;-)

If people get feedback about the 'excludepath' list, I'm interrested.
Because the list I build is only tested on the current set of RPMs we
use... A more complete list should prevent problems in case of new
RPM addition :o)

--
Yannick

>
> Cheers,
>       Stephan
>