# Inconsistent CPU utilisation in @threads loops

**URL:** <https://discourse.julialang.org/t/inconsistent-cpu-utilisation-in-threads-loops/110512>\
**Category:** Performance\
**Tags:** parallel, multithreading, threads, threading\
**Created:** [February 21, 2024, 12:49pm UTC](https://discourse.julialang.org/t/inconsistent-cpu-utilisation-in-threads-loops/110512 "2024-02-21T12:49:19Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [February 21, 2024, 6:55pm UTC](https://discourse.julialang.org/t/inconsistent-cpu-utilisation-in-threads-loops/110512/7 "2024-02-21T18:55:25Z")

</div>

This is GC — yes, even with it only showing ~0% GC time.

`eigen` allocates an 800MB matrix to store its result right at the get-go. You’re doing that 8 times, all at once. It’s highly likely that Julia may think that — after allocating a few of them — it’s a good idea to do garbage collection. BUT: the GC does not do its collection multi-threaded-ly. Instead, it holds the thread until _all_ threads hit a GC safepoint. But a few of the threads have already kicked off into a multi-minute BLAS ccall. So it’s gotta wait for those to return. In the meantime, all the other threads are just sleeping. That sleeping time does not appear as GC time in `@time`’s metrics.

That’s why it’s inconsistent — both in number of times you perform the benchmark (it may be that you’ve not hit memory pressure the first time you do it) and in the machines folks are reporting back (they may have so much memory they don’t feel any pressure).

See: [GC-safe `ccall`s · Issue #51574 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/51574)

---

_[View the full topic](https://discourse.julialang.org/t/inconsistent-cpu-utilisation-in-threads-loops/110512)._