port:lapack useful?
Takeshi Enomoto
takeshi at macports.org
Mon Oct 17 07:55:26 PDT 2016
Dear David,
> I just noticed that you created a port lapack (including BLAS) in r146856. Is this really useful? We already have the ATLAS port which provides BLAS and LAPACK; the OpenBLAS port which provides exactly the same implementation of LAPACK from netlib as your port lapack; and the built-in Accelerate Framework and the vecLibFort port providing a Fortran interface for it. All of these are optimized and therefore should be faster than the straightforward netlib implementation, and use directly of Accelerate/vecLibFort is of course by far the fastest to install. So, what is the use of a separate port lapack? I suspect its main effect will be to have users or port packagers use this one instead of an optimized implementation because they do not realize the optimized ones exist. For example, see the recent r153943. I would suggest removing it.
I started LAPACK port to provide man pages after Apple removed them.
Some email exchanges with the LAPACK developers I became aware of the followings:
* LAPACK from netlib is active.
* the man pages can be generated from LAPACK source by make man.
* the most of the performance gain is due to BLAS, which can be obtained from BLAS.
* CBLAS and LAPACKE can be provided.
I believe that there is nothing to be harmful to leave the port.
The message from the upstream developer on 15 March 2016.
> Dear Takeshi,
> I am ccing Julien Langou - he is one of the PI of LAPACK and our most active contributor.
> I saw your vecLibFort port - this is awesome and it was dearly needed.
> > vecLibFort is lightweight but flexible shim designed to rectify the incompatibilities between the Accelerate/vecLib BLAS and LAPACK libraries shipped with Mac OS X and FORTRAN code compiled with modern compilers such as GNU Fortran.
>
> First, there is no real complete “optimized LAPACK” library around that I know if except the one's from vendors (for Example: MKL INTEL)
> Second, most of the performance from a LAPACK code will come from an Optimized BLAS library (i.e. Veclib)
> Veclib is based on Atlas, and I did not check, but I believe the LAPACK included inside VecLib and vecLibFort correspond to the ATLAS LAPACK - which is a small subset of LAPACK library.
>
> So I think to write a port for LAPACK itself is a great idea.
> Also LAPACK now includes LAPACKE - A C Standard Interface to LAPACK - A lot of users are using it.
>
> Regards,
> Julie
Best wishes,
Takeshi
More information about the macports-dev
mailing list