Tests don't pass about mklsparse.jl HOT 10 CLOSED

Also, even when I comment out those particular tests, I get the following message repeatedly:
MKL-DSS-DSS-Error, Zero pivot detected . Is this supposed to happen?

from mklsparse.jl.

Yes, this project is not really in a usable state yet. I started a while ago on fixing things up at #7 but it is not done yet and I have some troubles with method ambiguities.

The reason for the "MKL-DSS-DSS-Error, Zero pivot detected" messages is because I am testing if I get the correct error when trying to cholesky factor a non positive definite matrix. MKL does its own printing to stderror which is displayed. I should probably redirect the stdout for those tests.

I won't have much time to work on this right now but if you want to contribute I would start at #7 and go from there.

from mklsparse.jl.

With #7 closed, what's the status of this project? I'd like to fix the unit tests, but not sure where to begin.

from mklsparse.jl.

Wrong place to discuss, but I would love to see this project take off, and pave the way for flexible sparse matrix solvers in Julia.

from mklsparse.jl.

I just created a version of Julia with MKL support on one of our servers and will be able to look at this in more depth later in the week.

@Viral What is the likely path forward for using MKL? I see that Continuum is now shipping MKL with Anaconda and Miniconda (or perhaps it is installed with Pandas - I wasn't keeping careful track). Is it likely that there a distribution of Julia with MKL can be created?

@andreasnoack Is it still the case that gcc or clang can't create a Julia/MKL combination that passes all its test? That is, are icc/ifort still needed to compile Julia with MKL? Academic researchers and students can get a free copy of MKL but that doesn't include the compilers, AFAICT. Open Source contributors, however, can get a free copy of Intel Parallel Studio XE which includes the compilers.

By the way, I found that peakflops is faster under OpenBLAS than under MKL on the system where I compiled it yesterday (see my message in the julia-stats group). It wasn't a head-to-head comparison in that OpenBLAS was from the distribution of Julia-0.5.0 and the version with MKL was compiled from 0.6.0-dev sources. I'll try a head-to-head comparison when I get back to Madison tomorrow.

from mklsparse.jl.

I haven't tried in a while but I think ARPACK is having trouble with gfortran+MKL because of the use of z/xdotc.

I think OpenBLAS is a very good competitor to MKL for xGEMM. KML is faster for more exotic operations. I've also noticed significant differences in triangular solves where MKL seems to be quite a bit faster. OpenBLAS optimizes a few LAPACK functions whereas MKL optimizes many (I think because they don't write it explicitly) so for e.g. eigenvalue problems you can also see a difference.

from mklsparse.jl.

The solution is to link to the gcc compatible version of MKL (which is part of the MKL distribution). I never got it to work successfully a long while back, but it is definitely worth revisiting.

@dmbates The issue is not if open source developers can get MKL freely, but if an open source project can distribute the binaries freely. I thought someone mentioned that MKL licenses are now a lot more permissible than they were earlier. I haven't seen the licenses, if they changed recently.

from mklsparse.jl.

The problem is that we link to the convenience library libmkl_rt. To link to the gfortran compatible version I think we need the three library version. Something like -lmkl_gf_ilp64 -lmkl_core -lmkl_gnu_thread but I haven't been able to do that succesfully.

from mklsparse.jl.

Yes, I ran into the same problem. Perhaps it works in newer versions?

from mklsparse.jl.

Tests pass now. DSS was removed. Pardiso.jl can be used for MKL sparse solving.

from mklsparse.jl.