Problem with 2 Different Installations of Julia Pro Interfering One with Each Other

I downloaded Julia Pro 1.2.0-1 for Windows and installed it twice using the shared drive option.
One installation folder was D:\JuliaPro and the other was D:\JuliaProMKL.
In each installation folder I created a sub folder called Profile.
So we have D:\JuliaPro\Profile and D:\JuliaProMKL\Profile.

As one can infer from the name I intended one to have MKL (Using MKL.jl) and the other to use the default OpenBLAS.

I edited the Juno.bat file in the folder to set the system variables to the folder Profile in each of the installations. Then I copied .juliapro form %USERPROFILE% to Profile\.juliapro in each installation.

Basically I created a portable Julia Pro installation. Each folder should be independent of the system and keep all configuration files and packages in the respective Profile folder.

Then I started each of them, changed settings and indeed each settings I changed (About ATOM / Juno) was affecting only the installation it was run from. I checked the computer %APPDATA% and %USERPROFILE%and they were clean. Which means indeed everything works according to the environment variables I defined inJuno.bat`.

I started Juno.bat from the MKL installation and installed MKL.jl. It also build the system image.
I restarted ATOM of the MKL installation and verified t6hat indeed the BLAS vendor is Intel MKL as described in the MKL.jl package.

I then went to the non MKL installation, ran Juno.bat and checked the BLAS vendor as well.
It turned out to be :mkl as well.

So it raises some questions:

  1. Home come those 2 independent installations are using the same MKL BLAS library?
  2. When the MKL.jl package built again the system image, could it be it made both of them use it?
  3. When user build system image, where does Julia put the System Image file by defualt? What’s the file name? Does the location set by environment variable?
  4. I set the following environment variables: %ALLUSERSPROFILE%, %APPDATA%, %HOMEPATH%, %ProgramData%, %Public%, %TEMP%, %TMP% and %USERPROFILE%. Is there any other variable Julia might use? Is there a way it override the user definitions of those?
  5. Does Julia / Julia Pro use Registry entries and not only system variables?

I’ll be happy for assistance.

Update

I opened the JuliaPro (Non MKL) and ran ENV["PATH"]. This is what I got (Among other things):

D:\\JuliaProMKL\\Profile\\.juliapro\\JuliaPro_v1.2.0-1\\packages\\MKL\\goLVK\\deps\\usr\\bin"

First, this is not the system PATH, so on load Juno or Julia are altering the %PATH% system environment. The question is what triggers adding the MKL package which is on the JuliaPRoMKL folder to the path when launching Julia with non MKL.

I am not sure what you are trying to achieve. But you can grab one installation, and install it two times on different folders names:
I recommend using official binaries because JuliaPro doesn’t always have the latest version of the packages (MKL for this case):


The Users/yourName/.julia/packages is where packages are downloaded. This folder is shared between two different installations.

When you add MKL to one of those (https://github.com/JuliaComputing/MKL.jl#to-install), it downloads the package and then builds the files. So Julia-1.4-dev-MKL content is modified after installation.

You can install Atom:

Then uber-juno package for Atom:

You can change the Julia path for different installations doing this:
Go to Packages > Julia > Settings and change "Julia Path" to point to the Julia binary.

Alternatively, install Julia Pro and one Julia + MKL. Then point to the different path of Julia folders for two installations

I’m not sure what you display but in my case even if they don’t have the same location for packages (.julia/packages/) they both use MKL one I install on one of them.

So it has nothing to do with the path of the Julia binary but the path Julia use to look for packages (I might not be accurate as I’m not an expert on the way Julia handles things).

Look for the BLAS vendor on those two. Verify they are different.

Regarding the version of MKL.jl, it is not official package hence anyway it is being installed form the Git itself and not from a specific release of it.

I think you’d better use official binaries. It is simpler to have different installations. If works for me perfectly. JuliaPro is not really anything more than Atom+Julia

If JuliaPro is the same as usual official binaries: In the 2nd JuliaPro, Go to Packages > Julia > Settings and change "Julia Path" to point to the Julia binary. and point to the one which doesn’t use MKL.

@Amin_Yahyaabadi, Let me try to pinpoint the issue.
In my case not only they point to different Julia binary folder, they have different Base.DEPOT_PATH.
Yet, still something mix them to use the same BLAS although they shouldn’t be able to be aware of each other (Remember, each have its Environment Variable pointing to different paths).

I suggest you have a look on your installation and verify that indeed you different BLAS vendor on each.

I don’t want to use Julia’s binaries.
I’m old fashioned on this and I want a package which coherent form the producer. Different people will have different choice. Yet this is mine. Still it should work and something tricky I don’t understand happening here.

Let’s wait for an answer of someone who understand how Julia Pro sets some of its parameters. Specifically the Path. My indication (Since the folders are locked and I can’t delete them) that one of the processes doesn’t release the convhost.exe process. Which created a case when I launched them one after the other to “merge information”. Just a speculation.
We’ll have to patient until someone who is informed will explain.

For my case, given that I use official binaries, different installations have different BLAS.vendor().

Yes, I prefer Julia Pro users answer this. Move your thread to Tooling and JuliaPro section of the forum to get more answer.

Ok, here’s what I tried:

  1. Install JuliaPro (with shared drive option) in D:\\JuliaPro-1.2.0-1-mkl
  2. Install JuliaPro (normal user install, but shouldn’t matter) in D:\\JuliaPro-1.2.0-1
  3. Start the MKL JuliaPro, install MKL.jl, restart Julia processes a couple of times and check that
julia> using LinearAlgebra

julia> BLAS.vendor()
:mkl

julia> normpath(Sys.BINDIR, "..", "lib", "julia")
"D:\\Programme\\JuliaPro-1.2.0-1-mkl\\Julia-1.2.0\\lib\\julia"
  1. Start the other JuliaPro install and check that
julia> using LinearAlgebra

julia> BLAS.vendor()
:openblas64

Checking the changed date of both sys.dlls (D:\\JuliaPro-1.2.0-1-mkl\Julia-1.2.0\lib\julia\sys.dll and D:\\JuliaPro-1.2.0-1\Julia-1.2.0\lib\julia\sys.dll) shows that the MKL one was updated correctly.

Note that I didn’t mess around with any env vars etc, so both installations had MKL.jl available. That doesn’t really matter though, because MKL.jl installation modifies your Julia installation – it’s not purely a package (and also can’t really be uninstalled).

@pfitzseb, appreciate the effort to check this.

I found the mistake I made and fixed it. Now it works on my system as well.
I will update the post with the mistake I made and will create a guide - How to Create a Portable Installation of Julia Pro on Windows.

Thank You.

1 Like