# Multithreaded compute farm

**URL:** <https://discourse.julialang.org/t/multithreaded-compute-farm/65047>\
**Category:** Performance\
**Tags:** review, multithreading\
**Created:** [July 21, 2021, 4:11pm UTC](https://discourse.julialang.org/t/multithreaded-compute-farm/65047 "2021-07-21T16:11:55Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [July 24, 2021, 10:19pm UTC](https://discourse.julialang.org/t/multithreaded-compute-farm/65047/11 "2021-07-24T22:19:48Z")

</div>

I don’t think ThreadPools.jl is relevant here unless, e.g., you want to combine this with a GUI application:

> [@Multithreaded mapping of an iterator (not a collection)](https://discourse.julialang.org/t/multithreaded-mapping-of-an-iterator-not-a-collection/47906/9):
>
> - The main goal of ThreadPools.jl is to separate latency-critical code from throughput-oriented code. ThreadPools.jl achieves this by a clever trick but unfortunately this impedes dynamic scheduling by the `julia` runtime. As a result, using this at library level means we will loose composable nested parallelism ecosystem that Julia’s parallel runtime is designed to support.

See also the last paragraph of [Automatically fusing together several for-loops - #18 by tkf](https://discourse.julialang.org/t/automatically-fusing-together-several-for-loops/46097/18) and the discussion.

---

_[View the full topic](https://discourse.julialang.org/t/multithreaded-compute-farm/65047)._