# Estimating when downside of parallelism becomes not so important
**URL:** https://discourse.julialang.org/t/estimating-when-downside-of-parallelism-becomes-not-so-important/10627
**Category:** New to Julia
**Created:** [April 30, 2018, 7:44pm UTC](https://discourse.julialang.org/t/estimating-when-downside-of-parallelism-becomes-not-so-important/10627 "2018-04-30T19:44:06Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Fatalon](https://discourse.julialang.org/u/Fatalon)
#### Post date: [April 30, 2018, 7:44pm UTC](https://discourse.julialang.org/t/estimating-when-downside-of-parallelism-becomes-not-so-important/10627/1 "2018-04-30T19:44:06Z")
Hello, I am new to Julia and I found this code snippet online, were somebody calculated the fibonacci number with and without parallelism. I was wondering about this magic n \< 40 statement were the person decides, if he uses the parallel implementation or the standard one. Is there a way without stepwise incrementing n to actually get the best value for situations like this?
I am a newby at parallel programming and I try to understand, when the usage of @parallel , @spawn and pmap becomes useful and which function calls are to small to calculate distributed.
```julia
@everywhere function parallel_fib_first(n)
if( **n < 40** )
fib(n)
end
x = @spawn parallel_fib_first(n - 1)
y = parallel_fib_first(n - 2)
fetch(x) + y
end
```
I hope you can help me to get a deeper understandig of julia and parallel programming
---
### Author:  [@iwelch](https://discourse.julialang.org/u/iwelch)
#### Post date: [May 1, 2018, 4:09am UTC](https://discourse.julialang.org/t/estimating-when-downside-of-parallelism-becomes-not-so-important/10627/2 "2018-05-01T04:09:00Z")
I have been experimenting with parallelism myself. [http://julia.cookbook.tips/doku.php?id=parallel](http://julia.cookbook.tips/doku.php?id=parallel) . alas, there are some aspects that you should be aware of.
julia can parallel-task on one process. this is not of any speedup use. (there are some cases when it can be convenient, such as serving socket requests.) (@async is one of them.)
julia has threads. for small tasks, with little memory use, they are almost perfect speed-up tools with perfect scaling. I think your task qualifies.
julia has processes, which are more heavyweight. when badly tuned, they can be _very_ bad. when well tuned, they can work well.
my little page has some benchmarks about the relative costs/benefits.
/iaw
---
### Author:  [@Fatalon](https://discourse.julialang.org/u/Fatalon)
#### Post date: [May 1, 2018, 7:52pm UTC](https://discourse.julialang.org/t/estimating-when-downside-of-parallelism-becomes-not-so-important/10627/3 "2018-05-01T19:52:58Z")
Thank you for your great respond, your link really helped me, too.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [May 1, 2018, 8:44pm UTC](https://discourse.julialang.org/t/estimating-when-downside-of-parallelism-becomes-not-so-important/10627/4 "2018-05-01T20:44:58Z")
> [@Fatalon](#):
>
> Is there a way without stepwise incrementing n to actually get the best value for situations like this?
Usually you repeatedly double it rather than incrementing it linearly. The point is that the base case has to be large enough for the computational savings of parallelizing to outweigh the communication cost of spawn/fetch (or any other form of parallelism), and there’s generally no way to determine this without application-specific benchmarking.