[oneDPL] Extend and improve the wording about parallel algorithms #657
Conversation
akukanov
requested review from
danhoeflinger,
dmitriy-sobolev,
rarutyun and
timmiesmith
| Additional Algorithms | ||
| +++++++++++++++++++++ | ||
|
|
||
| In addition to the standard aligned parallel algorithms, oneDPL provides the following algorithm functions. |
There was a problem hiding this comment.
| In addition to the standard aligned parallel algorithms, oneDPL provides the following algorithm functions. | |
| In addition to the standard aligned parallel algorithms, oneDPL provides the following algorithm functions | |
| defined in `<oneapi/dpl/algorithm>` header. |
P.S. we may want to move some algorithms to <oneapi/dpl/numeric>, but probably not in this PR.
There was a problem hiding this comment.
In this PR, we can say that certain functions (reduction, scans, and arguably histograms) are also accessible ("copied") in <oneapi/dpl/numeric>.
@danhoeflinger, @timmiesmith - what do you think about that? The previous discussion is here: uxlfoundation/oneDPL#1895
There was a problem hiding this comment.
Yes, I think that listing them as also accessible in numeric is a good idea.
There was a problem hiding this comment.
Done; please take a look.
| that take a oneDPL execution policy. | ||
|
|
||
| For all parallel algorithms (including ones with ranges) oneDPL implements list-initialization, where applicable, | ||
| as described in `P2248R8`_ proposal that is accepted for C++26. |
There was a problem hiding this comment.
Do we think that linking to the accepted proposal is overkill here beyond mentioning the C++26 working draft? It may be more accessible currently to list the proposal.
There was a problem hiding this comment.
I follow the pattern which we already use for the parallel range API.
I think referring to the working draft (without a link) is sufficient for the key message: the API follows the path taken by the standard. I suppose that somebody who needs the details can find those out in the working draft.
I can be convinced that referring to accepted proposals provides more value - especially if this feedback comes from the users of the API/specification :)
There was a problem hiding this comment.
I'm a bit torn. Obviously pointing to the standard draft is a little difficult to navigate if you are looking for specifics. However, it is likely the best long term option for the specification.
The paper provides easier to access details when we are talking at such a high level here without much verbosity or example etc.
I don't have a strong feeling either way, but a slight preference to including the paper with link.
4 participants
The patch is mostly editorial, but also extends the "Parallel Algorithms" page with some basic information about the C++17/20 standard-aligned parallel algorithms oneDPL provides.