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
This micro-benchmark is kind of a worst case for rayon -- maximally splitting into jobs with very little actual work involved in each. Some quick perf analysis shows that we're spending most time between crossbeam deques and our sleep code, which isn't surprising to me.
A possibly nicer implementation of that could use rayon::iter::split, so it can avoid recursing quite so deeply. That is more complicated to write though, and I fear it's still not going to be favorable in the small input case.
We don't have current plans to work on the overhead, but of course I'd love to see any improvements that folks can come up with. I wonder if it would be possible to even rewrite rayon-core internals with that heartbeat scheduling approach.
See the README in https://github.com/judofyr/spice
Why is the overhead of Rayon that huge? Are there any plans to reduce it?
The text was updated successfully, but these errors were encountered: