Threads macro load balancing option

[ChrisRackauckas]

As discussed with @JeffBezanson in the Slack, @threads still uses a static schedule. However, there are some cases where we are using it as a simple way to express a lot of similar computations to be done on threads, each of which is actually quite expensive and not the same size. Thus for our purposes it would make sense to utilize @par to get the dynamic scheduling, but it makes sense "aesthetics-wise" to just put @threads on the loop. Thus it would make sense to have something like @threads dynamic for i in ... where

macro par(expr)
    thunk = esc(:(()->($expr)))
    quote
        local task = Task($thunk)
        task.sticky = false
        schedule(task)
        task
    end
end

it turns the loop

_f = (i) -> # inner expression of the loop
for i in 1:100
  @par _f(i)
end

If I'm not mistaken that's all that's necessary?

[quinnj]

We should probably also think about asyncmap; maybe it could take a dynamic=true keyword argument or something.

[vchuravy]

Not quite, I think the right way of doing this is to enhance @async so that it can set task.sticky, since you will need an @sync.

@sync for i in 1:100
  @async par=true _f(i)
end

[stevengj]

Should it just default to a dynamic schedule once partr is working well? That's what Cilk does, right?

[StefanKarpinski]

Balanced workload is the exception rather than the rule, so imo, yes.

[JeffBezanson]

Duplicate of #21017

[andreasnoack]

Why not close if it's a duplicate?