4 ms·
In a literal sense, yes. But, and perhaps I am understanding this wrong, the article in the join primitive section states: "Once they have both finished, it wil
by craftkiller 11y ago
In a literal sense, yes. But, and perhaps I am understanding this wrong, the article in the join primitive section states: "Once they have both finished, it will return". If you ignore the cost of spinning up and tearing down the threads isn't this conceptually the same as the implicit join at the end of an OpenMP loop?
- jerven 11y agoIn this specific case yes, but so is the await await as shown at https://youtu.be/4OCUEgSNIAY?t=3545 https://youtu.be/4OCUEgSNIAY?t=3545 in your linked talk. The nice thing is that join is recursive in the quicksort example and that means its equivalent to the await await syntax in practical terms. Which also means when both are finished it will return. let mid = partition(v); let (lo, hi) = v.split_at_mut(mid); Future:of(|| quick_sort::<J,T>(lo)).await(), Future:of(|| quick_sort::<J,T>(hi)).await()); Is exactly the same in parallelism as this let mid = partition(v); let (lo, hi) = v.split_at_mut(mid); J::join(|| quick_sort::<J,T>(lo), || quick_sort::<J,T>(hi)); Except that join gives better scheduling due to work stealing which will avoid unbalanced cpu usage. My Rust is non existent but conceptually Rayon is similar to java9 parallel streams which I know well.
- CyberDildonics 11y ago> In a literal sense, yes. And that's why this isn't directly related to Amdalh's law, which is about data synchronization. If something is parallel yet not concurrent it doesn't need to be synchronized. So what you are describing is a pragmatic hangup.