Here's what I get:

julia> K = randn(2500,2500);

julia> K = K' * K;

julia> @which inv(lufact(K))
inv{T<:Union(Float64,Complex{Float64},Complex{Float32},Float32),S<:Union(DenseArray{T,2},SubArray{T,2,A<:DenseArray{T,N},I<:(Union(Range{Int64},Int64)...,)})}(A::LU{T<:Union(Float64,Complex{Float64},Complex{Float32},Float32),S<:Union(DenseArray{T,2},SubArray{T,2,A<:DenseArray{T,N},I<:(Union(Range{Int64},Int64)...,)})})
 
at linalg/lu.jl:145


On Monday, May 19, 2014 3:25:30 AM UTC-5, Andreas Noack Jensen wrote:
>
> In generaI, I don't think most people experience that MKL is faster that 
> OpenBLAS. On my MacBook, Julia with OpenBLAS and Matlab performs very 
> similar on the symmetric inversion problem.
>
> Some time ago, there used to be a problem with inv falling back on a 
> slower method. I should be fixed now, but maybe the difference you see is 
> my fault and not OpenBLAS'. What do you see if you type 
>
> @which inv(lufact(K))
>
>
> 2014-05-19 1:46 GMT+02:00 Thomas Covert <[email protected] <javascript:>>
> :
>
>> Thanks for sending that along - might go down that route once it's clear 
>> that MKL would do the trick and that the fixed costs of building it myself 
>> are worth it.  
>>
>> Are there other mac users using the pre-built binaries that see these 
>> same performance differences?  Why do the mac binaries report libgfortblas 
>> and liblapack when the windows and Linux binaries report libopenblas?
>>
>>
>> On Sunday, May 18, 2014, Leah Hanson <[email protected] <javascript:>> 
>> wrote:
>>
>>> There are instructions in the Julia README and on Intel's website for 
>>> running Julia with MKL:
>>>
>>> https://github.com/JuliaLang/julia#intel-math-kernel-libraries
>>>
>>> https://software.intel.com/en-us/articles/julia-with-intel-mkl-for-improved-performance
>>>
>>> -- Leah
>>>
>>>
>>> On Sun, May 18, 2014 at 3:59 PM, Thomas Covert <[email protected]>wrote:
>>>
>>>> Seems like the windows and Mac versions of Julia call different 
>>>> blas/lapack routines.  Might that be the cause?  Is it possible for me to 
>>>> ask julia to use a different blas/lapack?
>>>>
>>>>
>>>> On Sunday, May 18, 2014, J Luis <[email protected]> wrote:
>>>>
>>>>> Funny, in a similar machine (but running Windows) I get the opposite
>>>>>
>>>>> Matlab 2012a (32 bits)
>>>>> >> tic; inv(K); toc
>>>>> Elapsed time is 3.837033 seconds.
>>>>>
>>>>>
>>>>> julia> tic(); inv(K); toc()
>>>>> elapsed time: 1.157727675 seconds
>>>>> 1.157727675
>>>>>
>>>>> julia> versioninfo()
>>>>> Julia Version 0.3.0-prerelease+3081
>>>>> Commit eb4bfcc* (2014-05-16 15:12 UTC)
>>>>> Platform Info:
>>>>>   System: Windows (x86_64-w64-mingw32)
>>>>>   CPU: Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
>>>>>   WORD_SIZE: 64
>>>>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>>>>   LAPACK: libopenblas
>>>>>   LIBM: libopenlibm
>>>>>
>>>>> Domingo, 18 de Maio de 2014 19:16:48 UTC+1, Thomas Covert escreveu:
>>>>>>
>>>>>> I am finding that MATLAB is considerably faster than Julia for simple 
>>>>>> linear algebra work on my machine (mid-2009 macbook pro).  Why might 
>>>>>> this 
>>>>>> be?  Is this an OpenBLAS vs Intel MKL issue?
>>>>>>
>>>>>> For example, on my machine, matrix inversion of a random, symmetric 
>>>>>> matrix is more than twice as fast in MATLAB as it is in Julia:
>>>>>>
>>>>>> MATLAB code:
>>>>>> K = randn(2500,2500);
>>>>>> K = K' * K;
>>>>>> tic; inv(K); toc
>>>>>> Elapsed time is 2.182241 seconds.
>>>>>>
>>>>>> Julia code:
>>>>>> K = convert(Array{Float32},randn(2500,2500));
>>>>>> K = K' * K;
>>>>>> tic(); inv(K); toc()
>>>>>> elapsed time: 6.249259727 seconds
>>>>>>
>>>>>> I'm running a fairly recent MATLAB release (2014a), and versioninfo() 
>>>>>> in my Julia install reads:
>>>>>> Julia Version 0.3.0-prerelease+2918
>>>>>> Commit 104568c* (2014-05-06 22:29 UTC)
>>>>>> Platform Info:
>>>>>>   System: Darwin (x86_64-apple-darwin12.5.0)
>>>>>>   CPU: Intel(R) Core(TM)2 Duo CPU     P8700  @ 2.53GHz
>>>>>>   WORD_SIZE: 64
>>>>>>    BLAS: libgfortblas
>>>>>>   LAPACK: liblapack
>>>>>>   LIBM: libopenlibm
>>>>>>
>>>>>> Any advice is much appreciated.
>>>>>>
>>>>>>
>>>  
>
>
> -- 
> Med venlig hilsen
>
> Andreas Noack Jensen
>  

Reply via email to