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 

* 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 
* 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,

macports-dev mailing list

Reply via email to