Takeshi Enomoto <take...@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 extra work)? _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
