-
Notifications
You must be signed in to change notification settings - Fork 266
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
rayon parallel iterators execute serially #383
Comments
Due to the structure of the table, the parallel iterator won't split groups of 16 elements across threads. If you increase the number of elements in the table then you will see parallel execution. |
Interesting, is the granularity always 16 consecutive elements in iteration order? Is this a hard limitation, or a consequence of the current implementation? It would be great if it can be made more granular, unless there are trade offs I'm not aware of. |
The granularity comes from the group width which is 16 elements on x86 because that is the number of bytes in a 128-bit SSE regsiter. On other platforms is it 8 elements. |
I was affected by this issue, and ended up doing stuff like this to fix it if map.len() < THRESHOLD {
Either::Left(map.iter().par_bridge())
} else {
Either::Right(map.par_iter())
} Please consider having something similar built into the |
I tried to use a
HashMap::par_iter()
and was surprised to see that it does not execute in parallel. Is this something that can be fixed, or documented somewhere? As it stands, I'm not sure why I would ever use par_iter over par_bridge if I wanted parallel iteration.My repro case:
This is on 0.13.1 with the
rayon
feature flag enabled.The text was updated successfully, but these errors were encountered: