Julia: Difference between revisions

The first time you add a package to a Julia project (using <code>Pkg.add</code> or the package mode), the package will be downloaded, installed in <code>~/.julia</code>, and pre-compiled. The same package can be added to different projects, in which case the data in <code>~/.julia</code> will be reused. Different versions of the same package can be added to different projects; the required package versions will coexist in <code>~/.julia</code>. (Compared to Python, Julia projects replace “virtual environments” while avoiding code duplication.)

To avoid this issue, you can store your personal Julia “depot” (containing packages, registries, pre-compiled files, etc.) in a different location, such as your project space. For example, user <code>alice</code>, a member of the <code>def-bob</code> project, could add the following to her <code>~/.bashrc</code> file:

JULIA_EXCLUSIVE to anything non-zero. As per the [https://docs.julialang.org/en/v1/manual/environment-variables/#JULIA_EXCLUSIVE documentation] this takes control of thread scheduling away from the OS, and pins threads to cores (sometimes referred to 'green' threads with affinity). Depending on the computation that threads execute, this can improve performance when one has precise information on cache access patterns or otherwise unwelcome scheduling patterns used by the OS. Setting JULIA_EXCLUSIVE works only if your job has exclusive access to the compute nodes (all available CPU cores were allocated to your job). Since SLURM already pins processes and threads to CPU cores, asking Julia to re-pin threads may not lead to any performance improvement.