# Parallelizing for loop in the computation of a gradient

**URL:** <https://discourse.julialang.org/t/parallelizing-for-loop-in-the-computation-of-a-gradient/9154>\
**Category:** Performance\
**Tags:** question\
**Created:** [February 19, 2018, 5:50am UTC](https://discourse.julialang.org/t/parallelizing-for-loop-in-the-computation-of-a-gradient/9154 "2018-02-19T05:50:49Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![saschatimme](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/saschatimme/32/10313_2.png) [@saschatimme](https://discourse.julialang.org/u/saschatimme)\
**Post date:** [February 22, 2018, 10:21am UTC](https://discourse.julialang.org/t/parallelizing-for-loop-in-the-computation-of-a-gradient/9154/18 "2018-02-22T10:21:30Z")

</div>

> [@tkoolen](#):
>
> You shouldn’t have to do that, right? @threads should do that for you

Yeah but so I can add an additional function barrier with the explicit kernel function and even if some types are messed up due to the closure bug, I only have to pay `nthreads()` times for the dynamic dispatch.

---

_[View the full topic](https://discourse.julialang.org/t/parallelizing-for-loop-in-the-computation-of-a-gradient/9154)._