3 ms·

There is no need to call join more than once in a work stealing pipeline, join is the terminal operation. In other words it rather similar to future.get(), it i

by jerven 11y ago

There is no need to call join more than once in a work stealing pipeline, join is the terminal operation. In other words it rather similar to future.get(), it is a synchronisation point; which yes is amdalhs law target. Futures and workstealing parallel execution are two techniques that work hand in hand. Practically it can't be compared with C++ annotated OpenMP for loops, which have an implicit join at the loop termination. In a parallel data flow system like Rayon there are no implicit joins, only explicit as required. join() in this system is more like return dataflow as show in the presentation you link too.

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 ago
  In 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.

by jerven 11y ago

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 ago
In 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.