Re: [cooker-amd64] RC1 installation report

[Gwenole Beauchesne]

Hi,

> I thought that I would document the result of installing the RC1 for the 
> benefit of the list.

Thanks for testing.

> 32 bit Mandrake 9.2 ix86 installation: everything was fine, except that
> it didn't autodetect the scsi (had to select 79xx driver) nor the SATA
> (couldn't find one, so I left it; this was a test anyhow).

I think libata has experimental support for it but it's known to be
broken. I also got beta drivers from SIL but got no news for the final 
version schedule.

> 64 bit Mandrake 9.2 amd64 RC1 installation: exactly the same process, exactly 
> the same problems (no SATA, had to select the SCSI disk).

Concerning your SCSI controller, could you please tell me the exact PCI
id? As the result of lspcidrake -v + the driver you use.

> I tried installing the 32 bit RPMS from 9.2/x86 for those that didn't come 
> with 9.2/amd64 (there are several which didn't make it in, I guess due to non 
> 64-bit cleanliness),

There are still around 58 failures (down from 500 or so) I still haven't
checked. I won't add them for 9.2 release but if you had some examples of
missing ones of interest for you, I will probably have a look for the next
version or updates/unsupported mirrors.

> Problems with the environment:
> - Our auto-setup script expected the PAM modules in /lib, but they are in 
> /lib64.

Concerning PAM modules, there should not be any explicit dependency on
/lib pam modules left. If so, please report me which ones. Since rc1, PAM
support is biarch. i.e. there are both 32-bit & 64-bit PAM libraries. PAM
config files (/etc/pam.d/*) now have the explicit /lib/ path removed. 

> - The popt package installs libpopt.so.0, but no libpopt.so symlink.  
> This is for both 32 and 64 bit.  I had to create this manually.

The .so symlink is in the popt-devel package, as it should be.

> - Our auto-setup script calls URPMI after adding some package sources to the 
> list.  In order to satisfy dependencies, we have to point it to both 9.2/x86 
> and 9.2/amd64.  It then proceeded to ask us many questions about which 
> version we wanted, the libxxx or lib64xxx.  Maybe this could be made smarter 
> to know that the lib64xxx includes the libxxx, and so the choice is 
> unnecessary.

It should not ask for both libxxx or lib64xxx. Rather, this happens when 
urpmi can't resolve binaries dependencies. What could be done is to always 
prefer Elf64 packages on biarch systems.

> - It would be good to have a JDK

The 32-bit Sun JDK is available. There is a native version at Blackdown
but it's not publicly available yet.

> - (Not a problem with Mandrake): Generating both 32 and 64 bit versions
> of our custom libraries is not an easy exercise.  It involves lots of
> RPM specfile hacking, since most packages are not set up to allow this.

What do you mean? Building and shipping both versions in a single RPM? If 
so, you generally create separate subdirs prior to the configure steps. 
See e.g. glibc & gcc rpms.

> Benchmarking: I have only one result, which is a floating point intensive 
> simulation of a particular linguistic language model, in C++ and hand-tuned 
> SSE assembler.  About 50% of the time is spent in traversing large dynamic 
> state machines, and the other 50% of the time is spent in calculating a 
> vectorised kernel over a couple of megabyte working set.  (I can't be more 
> specific).  The same 32 bit binary was run on both machines.  For us, it is a 
> very real-world benchmark.
> 
> Dual Athlon-MP 2000+: 103 seconds.
> Dual Opteron 246: 57 seconds.

Interesting, have you tried an optimized AMD64 version with full use of 
all SSE2 registers?

> Compiling seems a little faster on the opteron (maybe 30% faster), but
> not nearly twice as fast like our language model.

It's indeed what I see. Typically, my oldish 800 MHz build system builds
faster a kdebase than our bi P3/800 systems. Anyhow, kdebase in non debug
build is UP but you save around 15 minutes on 1 hour.

Bye,
Gwenole.