<div dir="ltr">Hi Takeshi,<div><br></div><div>Thanks for the response. <br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 7:55 AM, Takeshi Enomoto <span dir="ltr">&lt;<a href="mailto:takeshi@macports.org" target="_blank">takeshi@macports.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
* LAPACK from netlib is active.<br></blockquote><div><br></div><div>I do not doubt that the netlib LAPACK is active -- this is of course the reference implementation that the vendors use in optimization.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* the man pages can be generated from LAPACK source by make man.<br></blockquote><div><br></div><div>The existence of the port lapack-manpages certainly is useful to provide these manpages, but that is separate from the lapack port, isn&#39;t it?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* the most of the performance gain is due to BLAS, which can be obtained from BLAS. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* CBLAS and LAPACKE can be provided.<br></blockquote><div><br></div><div>Both of these are true of the OpenBLAS port already, in fact.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I believe that there is nothing to be harmful to leave the port.<br></blockquote><div><br></div><div>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?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The message from the upstream developer on 15 March 2016.<br>
<br>
&gt; Dear Takeshi,<br>
&gt; I am ccing Julien Langou - he is one of the PI of LAPACK and our most active contributor.<br>
&gt; I saw your vecLibFort port - this is awesome and it was dearly needed.<br>
&gt; &gt; 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.<br>
&gt;<br>
&gt; First, there is no real complete “optimized LAPACK” library around that I know if except the one&#39;s from vendors (for Example: MKL INTEL)<br></blockquote><div><br></div><div>Indeed, so for Apple the vendor-optimized version is Accelerate.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; Second, most of the performance from a LAPACK code will come from an Optimized BLAS library (i.e. Veclib)<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; 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.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>Best,</div><div>David</div></div><br></div></div></div>