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?
We should probably also think about asyncmap; maybe it could take a dynamic=true keyword argument or something.
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
Should it just default to a dynamic schedule once partr is working well? That's what Cilk does, right?
Balanced workload is the exception rather than the rule, so imo, yes.
Duplicate of #21017
Why not close if it's a duplicate?
Most helpful comment
Should it just default to a dynamic schedule once partr is working well? That's what Cilk does, right?