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
signature.asc
Description: This is a digitally signed message part