[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Atlas proposal



Le mardi 17 août 2010 à 22:45 +0100, Roger Leigh a écrit :
> 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 ? 
[...]

> 
> 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.
C/C from the FAQ:
http://math-atlas.sourceforge.net/faq.html#tnum
"Can I vary the number of threads ATLAS uses dynamically?
No. The maximum number of threads to use is determined at compile time.
ATLAS will never use more than this, but may use less if the problem
sizes are too small to get speedup from the additional parallelism."

> 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.
OK, I forgot to add something.

I know upstream is doing it "wrong" from our distro point of view.
However, I am not upstream, I don't plan to patch atlas to manage this
and I don't think upstream is interested in it. It is not the approach
of upstream and I don't think the current build system will allow the
introduction of such features easily.

For example, software like Scilab (under Windows) and Matlab are
shipping pre-optimized packages of Atlas.

Sylvestre



Reply to: