help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave for Mac with Reference Lapack


From: Alexander Hansen
Subject: Re: Octave for Mac with Reference Lapack
Date: Sat, 09 Jun 2012 12:29:33 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

On 6/9/12 12:12 PM, Lukas Reichlin wrote:
> On 08.06.2012, at 05:28, Alexander Hansen wrote:
> 
>> On 5/31/12 10:47 AM, Lukas Reichlin wrote:
>>> On 31.05.2012, at 18:48, Alexander Hansen wrote:
>>>
>>>> On 5/30/12 2:41 PM, Alexander Hansen wrote:
>>>>> On 5/30/12 4:03 AM, c. wrote:
>>>>>>
>>>>>> On 29 May 2012, at 23:19, Lukas Reichlin wrote:
>>>>>>
>>>>>>>
>>>>>>> I'm surprised to see it working, also on my machine. I fear it doesn't 
>>>>>>> help much, as Accelerate 10.6 used to be the best out of three:
>>>>>>>
>>>>>>> 1. Accelerate OSX 10.6
>>>>>>> 2. ATLAS 3.9 from MacPorts
>>>>>>> 3. Accelerate OSX 10.7
>>>>>>>
>>>>>>> I don't have access to 10.7 this evening, and when I build the variant 
>>>>>>>
>>>>>>>         octave-devel +atlas +fltk +gcc45
>>>>>>>
>>>>>>> from the attached MacPorts portfile, mkoctfile returns
>>>>>>>
>>>>>>> nothing for  $(shell $(MKOCTFILE) -p LAPACK_LIBS)
>>>>>>> framework veclib for  $(shell $(MKOCTFILE) -p BLAS_LIBS)
>>>>>>
>>>>>> this seems to indicate that although you specified atlas as an option 
>>>>>> your Octave was linked 
>>>>>> against the Accelerate framework rather than ATLAS, I'm not an expert in 
>>>>>> portfile syntax so 
>>>>>> I don't see where the problem is there.
>>>>>>
>>>>>> To further check whether Octave is actually linking to vecLib you should 
>>>>>> do something like:
>>>>>>
>>>>>> otool -L /opt/octave/3.7/lib/octave/3.7.0+/liboctave.dylib 
>>>>>>
>>>>>> what I get is the following:
>>>>>>
>>>>>> octave/3.7.0+/liboctave.dylib:
>>>>>>  /opt/octave/3.7/lib/octave/3.7.0+/liboctave.1.dylib (compatibility 
>>>>>> version 2.0.0, current version 2.1.0)
>>>>>>  /opt/octave/3.7/lib/octave/3.7.0+/libcruft.1.dylib (compatibility 
>>>>>> version 2.0.0, current version 2.0.0)
>>>>>>  /opt/arpackng/3.0.2/lib/libarpack.2.dylib (compatibility version 3.0.0, 
>>>>>> current version 3.0.0)
>>>>>>  /opt/qrupdate/1.1.1/lib/libqrupdate.1.dylib (compatibility version 
>>>>>> 0.0.0, current version 0.0.0)
>>>>>>  /sw/lib/libreadline.5.dylib (compatibility version 5.0.0, current 
>>>>>> version 5.2.0)
>>>>>>  /sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0, 
>>>>>> current version 5.0.0)
>>>>>>  /opt/pcre/8.20/lib/libpcre.0.dylib (compatibility version 1.0.0, 
>>>>>> current version 1.1.0)
>>>>>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
>>>>>> version 125.2.11)
>>>>>>  /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 
>>>>>> (compatibility version 1.0.0, current version 4.0.0)
>>>>>>  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
>>>>>> version 7.9.0)
>>>>>>  /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 
>>>>>> (compatibility version 1.0.0, current version 268.0.1)
>>>>>>
>>>>>> I think your problem might rather be with mixing up different LAPACK 
>>>>>> implementations rather than choosing the wrong one.
>>>>>>
>>>>>>
>>>>>>> Lukas
>>>>>> c.
>>>>>
>>>>> I'm in the process of collecting data from my own systems
>>>>> (control-2.3.50 and Octave 3.6.1)  to post.  Real life keeps getting in
>>>>> the way, though. :-)
>>>>>
>>>>> I've mandated in Fink that Octave Forge packages which use BLAS or
>>>>> LAPACK use the same provider as does Octave, so there shouldn't be an
>>>>> opportunity for any mixing.
>>>>
>>>> I've uploaded the test_control log files here:
>>>>
>>>> http://akh.users.finkproject.org/test_control/
>>>>
>>>> Notes:
>>>>
>>>> 1)  They cover Fink's currently supported platforms:  10.5/powerpc,
>>>> 10.5/i386, 10.6/i386, 10.6/x86_64, 10.7/x86_64 (10.5/x86_64 is
>>>> quasi-supported and I'm in the process getting data for that, too).
>>>>
>>>> 2)  Octave 3.4.3+ won't build in Fink on 10.5/x86_64 or 10.6/x86_64
>>>> using Accelerate because of configure-time failures involving the
>>>> interaction of gfortran and Accelerate.  powerpc, i386, and 10.7 don't
>>>> seem to have this issue.
>>>>
>>>> 3)  Most of the atlas-based results are for atlas-3.9.11 because that
>>>> was our current version until a couple of days ago.  The exception for
>>>> 10.7 was because I have a machine that was too new for atlas-3.9.11.
>>>> I'll upload results from 10.7/x86_64/atlas-3.9.11 for completeness,
>>>> however, since I have an older machine where atlas-3.9.11 works.
>>>>
>>>> -- 
>>>> Alexander Hansen, Ph.D.
>>>> Fink User Liaison
>>>> http://finkakh.wordpress.com/2012/02/21/got-job/
>>>
>>> Wow, thanks for your work! In general, your results look familiar to me. I 
>>> experienced failing algorithms with Accelerate 10.7 as in
>>>
>>> http://akh.users.finkproject.org/test_control/control-10.7-x86_64-Accelerate.txt
>>>
>>> I hope we can circumvent these problems with a reference LAPACK variant 
>>> once and for all.
>>>
>>> Best regards,
>>> Lukas
>>>
>>
>> I've put a reference LAPACK/BLAS package in Fink--it's called
>> "lapack341", and I have it set up to build shared libraries.
>>
>> From my testing, control-2.3.51 passed its tests on OS X Lion if built
>> with this LAPACK and BLAS regardless of whether Octave was built with
>> lapack341, atlas, or even Accelerate.  So, for right now, only the
>> control package has a variant that builds against lapack341.
>>
>> -- 
>> Alexander Hansen, Ph.D.
>> Fink User Liaison
>> http://finkakh.wordpress.com/2012/02/21/got-job/
> 
> Hi Alexander
> 
> Thanks for the lapack241 package! Are there any news regarding an octave 
> variant linked against lapack341? I'm awaiting it eagerly, especially for Mac 
> OS X 10.7 :-)
> 
> Best regards,
> Lukas
> 

I can probably pull something together on that after this weekend.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]