Shutting down the Atlas port

[Ryan Schmidt]

On Nov 3, 2020, at 04:52, Vincent Habchi wrote:

> Atlas, the software meant to provide scientific computing tools with a high-performance assembly-based library has, IMHO, reached its end of life. 
> 
> My case is this:
> 
> • Last developer (unstable) release is more than two years old;
> • Last stable release is twice older (2016);
> • Consequently, ASM snippets Atlas relies on might not be up to date with the latest Intel processors;
> • Atlas will prolly never be ported to the new ARM-based architecture Apple is about to unveil;
> • The method used by Atlas to select the best assembly snippet (a.k.a “kernel”) for a given computation task is defeated by the power saving steps included in recent versions of MacOS, namely a gradual lowering of the priority of any power consuming task. This can lead to erratic, non-reproducible, and sub-optimal choices, rendering Atlas pointless;
> • Atlas build time from sources varies around 3 to 4 hours, regardless of the number of cores available (the selection process is mono-threaded), which makes Atlas cumbersome to build, and still more cumbersome to debug, barring on the quickest machines;
> • Since Atlas is CPU-based, no precompiled binaries should be available: at best, they will be suboptimal; at worse, they could contain unknown instructions old CPUs would crash on.
> 
> For all these reasons, I’m convinced that pulling the plug on Atlas is a good idea. Any thoughts?

Can all of the ports that currently depend on atlas be made to work correctly without atlas? If so, that would probably be the first step. You can't remove atlas while other ports depend on it.


DSDP
R
esmf
gr-specest
itpp
levmar
lua-numlua
nco
psfex
py-numpy
py-scipy
scamp
shogun
shogun-devel
source-extractor
stimfit
sundials
sundials2