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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
