# Question About New GC Threads

**URL:** <https://discourse.julialang.org/t/question-about-new-gc-threads/108117>\
**Category:** General Usage\
**Tags:** multithreading, garbage-collection\
**Created:** [December 28, 2023, 3:52am UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117 "2023-12-28T03:52:03Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![TI36XPro](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ti36xpro/32/33658_2.png) [@TI36XPro](https://discourse.julialang.org/u/TI36XPro)\
**Post date:** [December 28, 2023, 3:52am UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117/1 "2023-12-28T03:52:03Z")

</div>

I am excited to start using Julia 1.10.0 since I have a particular set of simulations which are allocation heavy (many small allocations) and I believe the GC is the current bottleneck.

I want to make sure I am doing this right. I think to start, it would make sense to split total threads available between those used for GC and those for computing. In that case I am running the following.

My run script contains the following lines (summarizing)

```bash
# runscript.slurm

#SBATCH --ntasks-per-node=12

GC_THREADS=6
COMPUTE_THREADS=6

main="my_simulation.jl"

export OMP_NUM_THREADS=$COMPUTE_THREADS

julia --project=@. --gcthreads=$GC_THREADS $main

```

The idea here is that I don’t want the GC threads to compete with the BLAS threads right? So it wouldn’t make sense to have both be set to 12 (total threads in this example).

Also - I can double check the number of BLAS threads by doing `BLAS.get_num_threads()`. Is there any similar function for checking number of GC threads?

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [December 28, 2023, 9:19am UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117/2 "2023-12-28T09:19:33Z")

</div>

Try this:

```julia
--gcthreads=6,1

```

For me it gives a significant improvement.

And I don’t think BLAS threads compete with GC threads because the GC stops everything else while running, but I might be wrong.

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [December 28, 2023, 1:28pm UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117/3 "2023-12-28T13:28:20Z")

</div>

> [@TI36XPro](#):
>
> Also - I can double check the number of BLAS threads by doing `BLAS.get_num_threads()`. Is there any similar function for checking number of GC threads?

`Threads.ngcthreads()` (although not public API)

> [@TI36XPro](#):
>
> `export OMP_NUM_THREADS=$COMPUTE_THREADS`

Note that, while this works (because we explicitly check for it), you should rather set `OPENBLAS_NUM_THREADS` because Julia isn’t using OpenBLAS with OpenMP threads but pthreads.

---

<div class="post-metadata">

**Author:** ![TI36XPro](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ti36xpro/32/33658_2.png) [@TI36XPro](https://discourse.julialang.org/u/TI36XPro)\
**Post date:** [December 28, 2023, 5:36pm UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117/4 "2023-12-28T17:36:31Z")

</div>

Thanks!

I was using `OMP_NUM_THREADS` because on my cluster we have intel and AMD CPUs and I have the run script built so that if the architecture is AMD it won’t use `MKL` (defaults to OpenBLAS). Since I could possibly use either OpenBLAS or MKL depending on how slurm dispatches the run, I thought I should use `OMP_NUM_THREADS`. Sorry if that’s completely wrong or a bad practice (was just my naive first attempt). If you have any recommendation on how to do that better please let me know.

I suppose I could constrain slurm to only use intel CPUs and then use `MKL_NUM_THREADS`?

---

<div class="post-metadata">

**Author:** ![TI36XPro](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ti36xpro/32/33658_2.png) [@TI36XPro](https://discourse.julialang.org/u/TI36XPro)\
**Post date:** [December 28, 2023, 5:37pm UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117/5 "2023-12-28T17:37:33Z")

</div>

Good to know, I will try that today.

Regarding whether the threads compete, that would also be good to know.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [December 28, 2023, 5:39pm UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117/6 "2023-12-28T17:39:34Z")

</div>

I cannot answer this question, but you should know that MKL also works nicely on AMD CPUs… Just benchmark yourself if OpenBLAS or MKL is better for your use case…  
Running MTK simulations multi-threaded, that only works with MKL…

---

<div class="post-metadata">

**Author:** ![TI36XPro](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ti36xpro/32/33658_2.png) [@TI36XPro](https://discourse.julialang.org/u/TI36XPro)\
**Post date:** [December 28, 2023, 5:40pm UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117/7 "2023-12-28T17:40:20Z")

</div>

Hm - yes I suppose I will have to then. I thought I had read somewhere that Intel made it run worse if it detected an AMD CPU.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [December 28, 2023, 5:47pm UTC](https://discourse.julialang.org/t/question-about-new-gc-threads/108117/8 "2023-12-28T17:47:51Z")

</div>

This is the relevant link, might be outdated: [How to circumvent Intel's AMD discrimination in MKL from v1.7 onwards?](https://discourse.julialang.org/t/how-to-circumvent-intels-amd-discrimination-in-mkl-from-v1-7-onwards/105075)