<div class="gmail_quote">On Fri, Dec 30, 2011 at 3:25 PM, Alan W. Irwin <span dir="ltr"><<a href="mailto:irwin@beluga.phys.uvic.ca">irwin@beluga.phys.uvic.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have investigated further, and I now think Dave is right with his<br>
desire to go ahead with the release of the rc2 versions of the<br>
lapack/blas find modules. (Sorry, Dave, for this flip-flop at the<br>
last minute, but such deeper investigations take time.)<br>
<br>
What appears to be going on is that in 2.8.5 the usual mechanisms to<br>
choose libraries (CMAKE_LIBRARY_PATH, CMAKE_FIND_ROOT_PATH) work<br>
correctly because they trump (according to my tests) the vendor choice<br>
(which defaults to ALL).<br>
So even though my system has both an atlas and generic version of blas installed, that<br>
is ignored for 2.8.5 and the generic blas version is used instead from<br>
the location designated by CMAKE_LIBRARY_PATH or CMAKE_FIND_ROOT_PATH).<br>
<br>
But in 2.8.7-rc2, the vendor choice trumps CMAKE_LIBRARY_PATH and<br>
CMAKE_FIND_ROOT_PATH. So given a choice between the generic version<br>
of blas in CMAKE_LIBRARY_PATH and my system's generic and atlas<br>
versions of blas, rc2 picks the system atlas version. I guess that is<br>
a reasonable choice because for large matrices atlas is normally<br>
faster than the generic version. However, for small matrices (such as<br>
in FreeEOS) it is noticeably slower.<br>
<br>
So in sum, there has been a fundamental shift in how the lapack/blas<br>
libraries are chosen. I assume that was a deliberate change in design<br>
so it was probably unfair for me to call it a regression, but a<br>
prominent announcement of this important change would have been<br>
appropriate to avoid misunderstandings.<br>
<br>
For my own use case, I have found setting -DBLA_VENDOR:STRING=Generic<br>
and CMAKE_LIBRARY_PATH (or presumably CMAKE_FIND_ROOT_PATH which<br>
I haven't tested for this configuration) gives me<div class="im"><br>
<br>
-- LAPACK_LIBRARIES =<br>
/home/software/lapack/install_<u></u>double/lib/liblapack.a;/home/<u></u>software/lapack/install_<u></u>double/lib/libblas.a<br>
<br></div>
i.e., the results I want for FreeEOS both 2.8.5 and 2.8.7-rc2.<br>
<br>
That'a slightly more complicated for FreeEOS users (which tend to have<br>
their own built versions of lapack/blas just like I do) than what<br>
worked up to and including CMake-2.8.5. But that additional<br>
complication is completely acceptable.<div class="HOEnZb"><div class="h5"><br>
<br>
Alan<br>
__________________________<br>
Alan W. Irwin<br>
<br>
Astronomical research affiliation with Department of Physics and Astronomy,<br>
University of Victoria (<a href="http://astrowww.phys.uvic.ca" target="_blank">astrowww.phys.uvic.ca</a>).<br>
<br>
Programming affiliations with the FreeEOS equation-of-state<br>
implementation for stellar interiors (<a href="http://freeeos.sf.net" target="_blank">freeeos.sf.net</a>); the Time<br>
Ephemerides project (<a href="http://timeephem.sf.net" target="_blank">timeephem.sf.net</a>); PLplot scientific plotting<br>
software package (<a href="http://plplot.sf.net" target="_blank">plplot.sf.net</a>); the libLASi project<br>
(<a href="http://unifont.org/lasi" target="_blank">unifont.org/lasi</a>); the Loads of Linux Links project (<a href="http://loll.sf.net" target="_blank">loll.sf.net</a>);<br>
and the Linux Brochure Project (<a href="http://lbproject.sf.net" target="_blank">lbproject.sf.net</a>).<br>
__________________________<br>
<br>
Linux-powered Science<br>
__________________________<br>
</div></div></blockquote></div><div><br></div><br><div><div>I don't know about the rest of you here, but I certainly welcome flip-floppers when they flip over to my side of a debate. :-)</div><div><br></div><div>2.8.7 is imminent!</div>
</div><div><br></div>