[103464] trunk/dports/math/atlas/Portfile

[Vincent Habchi]

Hi (Hallo ?) Rainer,

> Personally, I think that there is no benefit from building our own
> atlas. The Accelerate.framework shipped with Mac OS X is optimized for
> the hardware shipped by Apple - isn't that enough? I am still using
> -atlas in variants.conf for my installations (a relict from the times
> before we had binary archives).

True, but the Accelerate.framework: 
1. Is not looked for by most scientific OpenSource that are mainly developed under Linux and as such expect standard libraries like Atlas to be available;
2. Does not provide any Lapack API AFAIK (only BLAS, which is very limited);
3. Does not provide a Fortran API (C API only);

> Building a version of atlas tailored for the current machine is out of
> the scope of MacPorts in my opinion – that would require -march=native
> and a higher optimization level than our default of -O2.

I don’t think so. Atlas has been created in order to be able to chose automatically the parameters that give the highest performance. Most if not all of the critical portions of Atlas are written in assembly, which makes it somewhat independent of the C compiler and its flags; but, you’re right, there are some parts still written in C. The flags are tweaked by the configure process, though, and, for example O3 is used throughout.
 
> If we now even have to force building from source for the atlas port,
> that is one reason more to make the -atlas variant the default for
> py-numpy, py-scipy…

Atlas is not so lengthy to compile. As long as you stick to known hardware configuration for which there are pre-computed figures available, the build process avoids the various ‘try and error’ phases, that are responsible for 99 % of the build time. For example, on my old unibody MacBook late 2008, Core2Duo, building a universal version of Atlas takes less than half an hour, which is surely acceptable. Qt4, in comparison, takes much much longer.

> Note that atlas is not exclusively used for scientific computation.
> Through dependency chains such as py-pygtk or py-cairo it is pulled in
> by other software, e.g. inkscape or gimp for image manipulation. Users
> of these ports most probably don't care about a highly optimized atlas.

As long as they do not apply gaussian kernels on 4000x4000 pixels images or do not process a lot of images in batch.

> If the threaded version is an addition over the serial version, then
> this should be a single +threaded variant.
> 
> The default_variants could be selected automatically, such that
> +threaded is used for multiple cores and -threaded if only a single CPU
> is installed. Furthermore, the selection of variants could be validated
> against the current machine and raise an error if +threaded is selected
> on a mono-processor computer as that would lead to a build error.
> 
> This would still allow to create binary archives without breaking the
> build process for systems with a single CPU only.

If that makes everybody happy, I’ll add this in the rev. 3 of the Portfile.

Cheers
Vincent