port:lapack useful?

[David Strubbe]

Hi Takeshi,

Thanks for the response.

On Mon, Oct 17, 2016 at 7:55 AM, Takeshi Enomoto <takeshi at macports.org>
wrote:

>
> * LAPACK from netlib is active.
>

I do not doubt that the netlib LAPACK is active -- this is of course the
reference implementation that the vendors use in optimization.


> * the man pages can be generated from LAPACK source by make man.
>

The existence of the port lapack-manpages certainly is useful to provide
these manpages, but that is separate from the lapack port, isn't it?


> * the most of the performance gain is due to BLAS, which can be obtained
> from BLAS.

* CBLAS and LAPACKE can be provided.
>

Both of these are true of the OpenBLAS port already, in fact.


> I believe that there is nothing to be harmful to leave the port.
>

Well, what do you respond to my concern: 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, and
therefore get slower performance. Additionally, it is just confusing if we
have too many version of the same software. In what situation would you
expect someone should use this port as opposed to the other ones?


>
> 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)
>

Indeed, so for Apple the vendor-optimized version is Accelerate.


> > Second, most of the performance from a LAPACK code will come from an
> Optimized BLAS library (i.e. Veclib)
>

But is there any clear reason why one needs this other combination
(Accelerate BLAS + netlib lapack) as opposed to Accelerate BLAS +
Accelerate LAPACK or OpenBLAS BLAS + netlib lapack which we already have?


> > 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.
>

I have not noticed any LAPACK routines missing from either vecLibFort or
ATLAS. If there are in fact missing routines, then that would change the
situation -- is there any evidence about that?

Best,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20161017/6b32193d/attachment.html>