Closed ranjanan closed 7 years ago
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?
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.
With #7 closed, what's the status of this project? I'd like to fix the unit tests, but not sure where to begin.
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.
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.
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.
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.
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.
Yes, I ran into the same problem. Perhaps it works in newer versions?
Tests pass now. DSS was removed. Pardiso.jl can be used for MKL sparse solving.
Hey, the tests don't run, because
Base.LinAlg.A_ldiv_B
doesn't exist, therefore the tests associated with them would fail. You import them in dss.jl in the tests folder.