Update MKL instructions in README.md

[esd100]

Reference issue number #6367

[pao]

cc @tkelman @ivarne @andreasnoackjensen

[andreasnoack]

@esd100 Thank you for contributing. However, I don't think it is necessary to advice users to set the environment variables in their .profile, .bashrc etc., but I am open minded to the present description being elaborated.

[esd100]

@andreasnoackjensen I think maybe that it's just a little bit difficult to understand to the non-technically savvy person. i.e., people that haven't used a terminal very often, much less configure, make, install commands or people that are more familiar with a predominantly GUI OS, like Mac OS X users (even though it is very capable as a UNIX based system). For example, see one of my initial posts #6239, where I asked the question, "what does setting the MKL environment mean?" and ivarne was not able to answer my question. I finally figured it out, but I think that it would be nice to spare other people the trouble of searching the internet for an answer.

[StefanKarpinski]

Perhaps this can be phrased as "for example, but doing the following"?

[andreasnoack]

I don't see why it is easier to edit .profile than to copy-paste two lines into the terminal. If

...the MKL environment should be set up as

is unclear then I suggest that you change it to something like

...the MKL environment should be set up by copy-pasting ... into the terminal before building Julia.

[tkelman]

I agree with @andreasnoackjensen that it's better to recommend pasting those lines into the terminal within the session used to build Julia, than to edit profile files. Local temporary "for the task at hand" changes are generally preferable to global permanent system configuration changes, as long as it's something that's easy enough to remember to do each time.

Typically building Julia and all of its dependencies from source is something that's not recommended for users who aren't comfortable in the terminal, since the easy-to-use binary installations are available. But it's good you were able to get up and running with MKL, having people regularly testing a variety of configurations and getting performance comparisons is very valuable. A bit of clarification here on any points you struggled with absolutely doesn't hurt.

[esd100]

Here is a nice article on the difference between the files. http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html
So, changing one file versus another can give you different results, depending on what you might want, and doesn't necessarily mean a global permanent shell environment change.

I agree, though, that pasting the commands is also a reasonable alternative if the message is cleared up a little bit. It makes sense that building Julia is not for the terminal-naive. I would call myself maybe terminal-beginner, but not quite naive. Perhaps, my feedback then might serve to just make the process a bit more friendly to people like myself, who is kind of just doing this as an interesting pass-time.

[ViralBShah]

I know that at least on linux, we have been unable to get all tests to pass when linking MKL with gfortran compiled ARPACK, probably due to fortran calling conventions. It is perhaps best to compile everything with Intel compilers when using MKL, until we have fcall.

[esd100]

I was actually using gFortran when I did my MKL build, and aside from setting the environment variables up properly, it worked okay. I still have not gone on to try an experiment again with the intel compilers. I'll give that experiment a try a bit later.

[ViralBShah]

Did make testall pass? I still do not feel comfortable. MKL provides a different library to use for linking against gfortran but that has never worked for us.

[esd100]

I actually didn't run make testall. Do I need to do that? I just ran plain vanilla make. The gist for that particular make is in #6367 .

[tkelman]

Succeeding with make just means it compiled properly - which is a good start of course. We don't know whether the result is actually calculating the correct answers until you run the test suite with make testall.

[esd100]

So, do I have to delete the current installation? and just rebuild with make testall? or can I run testall after the fact?

[tkelman]

No need to rebuild. make testall is just a shortcut for cd test && ../usr/bin/julia runtests.jl all, it uses your existing build.

[esd100]

ah ... okay. I'll run it then and post the results in a gist.

[esd100]

Not sure what this means, but ...

ERROR: ProcessExitedException()
in remotecall_fetch at multi.jl:673
in remotecall_fetch at multi.jl:678
in anonymous at task.jl:1312
while loading /Applications/julia/test/runtests.jl, in expression starting on line 35

https://gist.github.com/esd100/11159218

[tkelman]

That remotecall, multi, task, part of the error doesn't really matter in the tests - what matters is which worker exited, which test it was working on, and any specific error messages from that test. In this case it was worker 6, which was working on arpack, and apparently gave no test-specific error messages for some reason. Arpack is known for intermittently failing tests, so try running make -C test arpack (equivalent to running make arpack in the test subdirectory) several times. Does it fail every time, or inconsistently?

[esd100]

okay...I'll check.

[esd100]

Not sure, what this means but it pretty much failed every time.
I ran ~50 tests. One time it did something more than the other 49 times.

https://gist.github.com/esd100/11159660

[ViralBShah]

This is most likely the fortran calling convention error I mentioned for which there is an open issue. Until this is resolved, I suggest not using MKL.

[esd100]

I was wondering if you could reference the issue that you are talking about, so that I can take a look at it.

[ViralBShah]

See #5363 and #5303

[lindahua]

I just built with MKL under Mac OS X. It works well (except that the test with ARPACK fails, all else works).

ARPACK is for computing eigenvalues of sparse matrices. It would be ok if your code doesn't need such functionalities.

[nolta]

Thanks for the patch @esd100. But i agree with @andreasnoack and @tkelman that we shouldn't suggest people edit their dot files. Plus there's a bit too much detail here for my tastes, especially since MKL support is still a bit experimental.