sean at macports.org
Mon Oct 17 11:18:08 PDT 2016
Takeshi Enomoto <takeshi at macports.org> writes:
> 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.
So many things I could say but I will refrain.
> * 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.
Yeah, that's fine with me. I see there's a linear_algebra portgroup
which should abstract away all these ports, correct (perhaps with some
More information about the macports-dev