You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Potentially related to or overlapping with #75, I think it'd be good if there was a scheduler that had a pre-allocated set of Tasks stored inside it that are then re-used, like how Polyester.jl handles its tasks.
This could help users avoid allocations and GC-latency, and also potentially do other things like re-use TaskLocalValues between multiple calls to tmapreduce. Definitely an advanced feature we shouldn't recommend to everyone, but in certain circumstances, it could be useful.
The text was updated successfully, but these errors were encountered:
I agree, this could be useful. If we want to implement new schedulers - say a dynamic load-balancing one that only uses a fixed subset of the threads - we probably need/want something like this. However, this is isn't just more advanced from a users POV but also (much?) more ambitious for us. AFAIR, Polyester jumps through a number of hoops to make the basics of this work.
Potentially related to or overlapping with #75, I think it'd be good if there was a scheduler that had a pre-allocated set of
Task
s stored inside it that are then re-used, like how Polyester.jl handles its tasks.This could help users avoid allocations and GC-latency, and also potentially do other things like re-use
TaskLocalValues
between multiple calls totmapreduce
. Definitely an advanced feature we shouldn't recommend to everyone, but in certain circumstances, it could be useful.The text was updated successfully, but these errors were encountered: