Atlas proposal

Roger Leigh rleigh at
Tue Aug 17 21:45:50 UTC 2010

On Tue, Aug 17, 2010 at 11:09:08PM +0200, Sylvestre Ledru wrote:
> After some discussions at the DebConf, here is a proposal on what should
> be done:
> * drop all optimized packages from the archive
> * only provide libatlas3gf-base & libatlas-base-dev without any
> extension and limited to one thread.
> * Update the description of the package with these information.
> * During the installation of the package, through debconf, inform the
> user that the current package is under optimized and better performances
> would be achieved by recompiling locally the package (which takes time
> anyway)
> * Through the DebConf process, propose to the user to build and install
> the optimized package
> My main questions are:
> * does it sound reasonable ? 

No.  Requiring the user to hand-build an optimised version for their
system is unacceptable.  Why can't this be fixed the correct way:
by building all optimised variants for a given architecture and
selecting the appropriate variant at runtime based upon the system's
capabilities e.g. from CPUID on i386/amd64?  I'm sure I saw this
question asked at least once on -release, and I don't recall seeing
it being addressed.

This is done by many other packages, from the kernel to video players
and games so is technically feasible.  It means a single version will
run on all systems and make use of each system to the best of its

Disabling threading is also suspect: how can the optimal number of
threads possibly be determined at build time?  This should also be
configurable or at least auto-detectable at runtime.

In short, Atlas' approach to optimisation by detecting everything at
build time is wrong.  Rather than working around this limitation by
totally crippling the library to work on a least-common-denominator
system by removing all optimisations and threading, it should be
actually fixed, probably best if done in collaboration with upstream.


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux   
 `. `'   Printing on GNU/Linux?
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <>

More information about the debian-science-maintainers mailing list