# Another slowdown when using \`Threads.@threads\`?

**URL:** <https://discourse.julialang.org/t/another-slowdown-when-using-threads-threads/78009>\
**Category:** General Usage\
**Tags:** performance\
**Created:** [March 17, 2022, 7:53am UTC](https://discourse.julialang.org/t/another-slowdown-when-using-threads-threads/78009 "2022-03-17T07:53:32Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [March 24, 2022, 8:01pm UTC](https://discourse.julialang.org/t/another-slowdown-when-using-threads-threads/78009/10 "2022-03-24T20:01:49Z")

</div>

What exactly are you trying to evaluate?

Libraries that use [PolyesterWeave.jl](https://github.com/JuliaSIMD/PolyesterWeave.jl) (this includes, among others, Polyester.jl and LoopVectorization.jl) use `PolyesterWeave.request_threads` to get the threads they are allowed to run on. This will make sure they do oversubscribe.

E.g., if you run `Octavian.matmul` from inside `@batch`, it’ll probably be single threaded. But if you run it from toplevel, it’ll be multithreaded.  
At one point, `Polyester` supported reserving threads per threads (e.g., if you have 16 threads total, it’d like you run 4 threads, that each have 3 extra ones reserved the others do not have access to). I didn’t want to keep maintaining that code, so I eventually took it out, but if someone wants something like that, I’d be happy to explain how to add support for this once again.

None of these libraries will work well when mixed with `Threads.@threads` or `Threads.@spawn`, however.

---

_[View the full topic](https://discourse.julialang.org/t/another-slowdown-when-using-threads-threads/78009)._