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

Reply via email to