Bug#697041: atlas: FTBFS: tune/sysinfo/GetSysSum.c:47: GetL1CacheSize: Assertion `system(ln) == 0' failed

[Sébastien Villemot]

Le dimanche 28 juillet 2013 à 15:04 +0000, Thorsten Glaser a écrit :
> S�bastien Villemot dixit:
> | The ATLAS build system, before creating the binaries, first performs a very
> | long series of timing tests in order to tune the library to the precise CPU on
> | which it is built.
> 
> I think this is conceptionally broken, especially when an architecture
> has a very broad range (think of i386 as prime example: it’s perfectly
> valid to build atlas on an i80486DX CPU and use it on a multi-core
> multi-GHz system, or the other way round).

I agree with you, but the point is that ATLAS was not designed to
provide a generic binary package. Instead, ATLAS is meant to be
recompiled on every host for optimal performance, as explained in the
description of the package and in its README.Debian.

However, Debian does not support the concept of “source-only” packages,
so we have to provide a binary. This binary package will be tuned for a
given machine (typically a buildd or a developer machine) and will
therefore not be optimal for all machines, but we cannot do anything
about that. Again, the optimal way of using ATLAS is to recompile on
every user machine.

> Please tell me how the differences between the CPUs will affect the
> generated package, i.e. whether these precomputed timings should be
> done on one of the slower machines. On m68k, we have machines from
> about 25 MHz (I think) up to 66/80 MHz, and “virtual machine” buildds
> with roughly 60-200 MHz (I only have access to the latter).

I actually don't know enough about ATLAS internal tunings to give you an
answer. My inclination would be to choose a machine that is closest to
the average m68k hardware that people are using nowadays. Ideally it
should not be done on a VM, but on real hardware; but if you don’t have
access to real hardware, then let’s do it on a VM.

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20130728/5cb069a9/attachment.sig>