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
It would be nice to provide implementations of parallel algorithms, especially if it would be possible to have them with the same API as their sequential counterparts. The goal is to try to implement a parallel algorithm in order to discover obstacles, rough edges, necessary API extensions/changes and helpful internals for implementing parallel algorithms in general.
A good candidate may be connected components. That will require implementing fundamentals such as parallel API on graph storages and parallel BFS.
Parallel algorithms may need more constraints on the graph (e.g., parallel iterators?) and these should not be required by default. Thus there should be a parallel() method on the algorithms builders which changes the constraints on the generics such that parallel algorithms are allowed. In other words, parallel algorithms should be opt-in instead of the default. Note that calling the parallel() method does not guarantee that a parallel algorithm will be used, that is up to the algorithm auto-selection.
It would be nice to provide implementations of parallel algorithms, especially if it would be possible to have them with the same API as their sequential counterparts. The goal is to try to implement a parallel algorithm in order to discover obstacles, rough edges, necessary API extensions/changes and helpful internals for implementing parallel algorithms in general.
A good candidate may be connected components. That will require implementing fundamentals such as parallel API on graph storages and parallel BFS.
Some resources I found online:
The text was updated successfully, but these errors were encountered: