-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inefficient scheduling for par_iter #1204
Comments
It's a tough balancing act, because usually I hear that the adaptive scheduler was too aggressive. :) If your input |
Thanks for the pointer, I could probably get indexed iteration working but I'm actually not sure I understand what wins I'm getting there over just spawning each thread separately. My ideal would actually be something like this:
Is there a way to do this with rayon or will I need to build my own scheduler / switch to tokio? |
The benefit is that you would still be using the shared thread pool, even if your number of items is much larger than the number of threads. They'll just be "scheduled" individually if you add What is your source that you're calling |
I have an iterator where the work to be done for each task varies widely—most items finish very quickly, but a few take orders of magnitude longer.
It appears from my quick experiment that Rayon is being somewhat inefficient here since
spawn
performs much better than theParallelIterator
. It looks like Rayon is still queuing up fast tasks behind the slow task on the same thread pool, or otherwise running fast tasks after the slow task.The optimal strategy here, which spawn seems to support, is to continue chewing through tasks on other threads while 1 thread stays stuck on the slow task.
Is there a way to do this with
par_iter
which has much nicer iteration semantics, or do I need to manage spawning myself?The text was updated successfully, but these errors were encountered: