Workstealing for the scheduler #8356
Conversation
|
This is a great start, and I'm happy it was so easy to implement. Most of my comments are minor:
Finally, the way that the vectors of work queues are managed here doesn't allow more schedulers that participate in work stealing to be added dynamically. This isn't important now, but I believe it will be necessary in the future. We don't necessarily need to fix this, but should have a plan for it. |
|
Also, the notes about perf are very encouraging. |
|
Wooo! |
|
Re the RNG stuff: This is a bit of a finicky issue. The actual "correct" solution is that we need to put an XorShift rng back in the task struct and expose it via Task::rng(), which would fetch it from TLS. I'll write that code up and put up a separate PR as it is an entirely separate issue. |
|
Dynamically adding schedulers to the workstealing set looks like it could be simple. We could add a new type of scheduler message that wraps a new WorkQueue handle and to process it we could modify the queue vector. When creating a new scheduler to be inserted just send that message to every other scheduler. To make this work we would need a set of scheduler handles accessible someplace though. |
…ork queue shared by each scheduler. Now there is a separate work queue for each scheduler, and work is "stolen" from other queues when it is exhausted locally.
This pull request converts the scheduler from a naive shared queue scheduler to a naive workstealing scheduler. The deque is still a queue inside a lock, but there is still a substantial performance gain. Fiddling with the messaging benchmark I got a ~10x speedup and observed massively reduced memory usage. There are still *many* locations for optimization, but based on my experience so far it is a clear performance win as it is now.
Simplify if let statements fixes: rust-lang#8288 --- changelog: Allowing [`qustion_mark`] lint to check `if let` expressions that immediatly return unwrapped value
This pull request converts the scheduler from a naive shared queue scheduler to a naive workstealing scheduler. The deque is still a queue inside a lock, but there is still a substantial performance gain. Fiddling with the messaging benchmark I got a ~10x speedup and observed massively reduced memory usage.
There are still many locations for optimization, but based on my experience so far it is a clear performance win as it is now.