Add @threads :dynamic

[jks-liu]

Better balance if tasks in iteration have different time costs.

julia> Threads.nthreads()
8

julia> function foo(x)
       if x <= 8
           sleep(1)
       end
   end
foo (generic function with 1 method)

julia> @time Threads.@threads for i in 1:16
       foo(i)
   end

  2.055390 seconds (17.37 k allocations: 1023.688 KiB, 0.00% compilation time)

julia> @time Threads.@threads :dynamic for i in 1:16
       foo(i)
   end
  1.052706 seconds (70.21 k allocations: 3.986 MiB, 0.39% compilation time)

[JeffBezanson]

We will need to come up with a different approach here. We need to avoid generating two copies of the code: the code size is 2^n for nesting depth n. Even though nesting @threads loops is not common, avoiding this is the best practice.

[chriselrod]

Shouldn't the compiler be able to constprop the schedule to delete the branch not taken?

[chriselrod]

That said, I'd just check if schedule === :dynamic or schedule === :static.

[jks-liu]

Sorry for late reply.
I think the :dynamic version is just like the default version which only use multi-threads in thread 1. So I don't think the 2^n thing will happen.
This is why I said ":dynamic creates one task per thread if possible" in the doc string.

[JeffBezanson]

4 space indent

[JeffBezanson]

Welcome, and thanks for working on this! Very good first PR.

I think we'll want to discuss exactly how the scheduling should work. You version works fine for small iteration counts, but I wonder if we still want to do some chunking to prevent excessive overhead.

[lstagner]

I was thinking that it would be nice to be able to specify how many threads I want to split the loop into e.g.

@threads 4 for i=1:100 # <--- split loop into 4 tasks
    do_work()
end

[IanButterworth]

A similar approach has been implemented in #43919 and the current idea is to develop more advance dynamic scheduling into that namespace, or new schedule names