# Best strategy to choose the number of gc threads on a cluster

**URL:** <https://discourse.julialang.org/t/best-strategy-to-choose-the-number-of-gc-threads-on-a-cluster/107596>\
**Category:** General Usage\
**Tags:** multithreading, threads, gc\
**Created:** [December 14, 2023, 4:02am UTC](https://discourse.julialang.org/t/best-strategy-to-choose-the-number-of-gc-threads-on-a-cluster/107596 "2023-12-14T04:02:35Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jishnub](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jishnub/32/33620_2.png) [@jishnub](https://discourse.julialang.org/u/jishnub)\
**Post date:** [December 14, 2023, 4:02am UTC](https://discourse.julialang.org/t/best-strategy-to-choose-the-number-of-gc-threads-on-a-cluster/107596/1 "2023-12-14T04:02:35Z")

</div>

I have a multithreaded code that I am running on a cluster using Julia v1.10, and it allocates many temporary arrays. The computation is quite linear algebra heavy, and I would like to keep freeing memory from time to time. Assuming that I need 10 threads to carry out my calculation, would a good strategy be to request for 10+n CPUs, and start julia with `julia -t 10 --gcthreads n,1`? So with 15 CPUs, this would be `julia -t 10 --gcthreads 5,1`? Would having free CPUs for the GC threads help, or is this unnecessary? Also, would the `1` dedicated thread for the concurrent sweep phase make a difference? In that case, would requesting for 16 CPUs be a better idea?

Sorry about the vague question, but I am just looking for general guidelines that I can play around with.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [December 14, 2023, 4:12am UTC](https://discourse.julialang.org/t/best-strategy-to-choose-the-number-of-gc-threads-on-a-cluster/107596/2 "2023-12-14T04:12:42Z")

</div>

For this you should likely use `julia -t 15 --gcthreads 8,1`. Julia doesn’t have a concurrent GC, so when the GC is running, the regular threads aren’t running. That said, if you are seeing substantial amounts of time spent in GC, it might be worth reducing the number of temporary arrays needed (e.g. via preallocation). Especially once you start scaling up threads (e.g. running on 30-60 cores), gc can be an issue if not mitigated since garbage collection (pretty much inherently) doesn’t achieve perfect scaling. That said, if your arrays are relatively large, I would expect garbage collection to be pretty quick.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [December 14, 2023, 9:45am UTC](https://discourse.julialang.org/t/best-strategy-to-choose-the-number-of-gc-threads-on-a-cluster/107596/3 "2023-12-14T09:45:04Z")

</div>

One thing I would flag up here - think about thread pinning. You don’t want the OS Scheduler moving things around

BTW you say 15 CPUs - does that mean 15 CPU cores or 15 CPU sockets?  
Indeed anything not a power of 2 gives me the willies…

[GitHub - carstenbauer/ThreadPinning.jl: Readily pin Julia threads to CPU processors](https://github.com/carstenbauer/ThreadPinning.jl)