Skip to content
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

[DOC]: Document work complexity of Thrust/CUB algorithms #1661

Open
1 task done
jrhemstad opened this issue Apr 23, 2024 · 2 comments
Open
1 task done

[DOC]: Document work complexity of Thrust/CUB algorithms #1661

jrhemstad opened this issue Apr 23, 2024 · 2 comments
Labels
doc Documentation-related items.

Comments

@jrhemstad
Copy link
Collaborator

Is this a duplicate?

Is this for new documentation, or an update to existing docs?

New

Describe the incorrect/future/missing documentation

As a user of Thrust and CUB algorithms, I often want to know things like:

  • Am I guaranteed that each element of the input range is accessed only once?
  • Am I guaranteed that each element of the output is only written to once?
  • Can my operator have side-effects?
  • Can dereferencing my input/output iterator have side-effects?

All of these questions are inter-related and the answer is unique to each algorithm.

To address these questions, I would like for each Thrust and CUB algorithm to have a "Complexity" section similar to what cppreference has:

image

If this is a correction, please provide a link to the incorrect documentation. If this is a new documentation request, please link to where you have looked.

No response

@bernhardmgruber
Copy link
Contributor

While I can understand the wish for more knowledge on the user side, there is a trade-off here, since promising too much about the implementation's behavior can also lock us out of future algorithmic evolution. Unless the complexity we advertise is pure documentation that we are allowed to break at any time :)

I vaguely remember Andrei Alexandrescu mentioning in a talk that there could be a faster implementation than the common ones for std::binary_search, but they would not fulfill the complexity guarantees of the STL. I couldn't find the talk right now, so it may just be a myth as well.

@jrhemstad
Copy link
Collaborator Author

promising too much about the implementation's behavior can also lock us out of future algorithmic evolution.

Oh I completely agree. I neglected to mention it, but I fully intended that the "Complexity" section for most algorithms may not make any guarantees at all. for_each is the one algorithm where we definitely need to make strong guarantees, but all the others may not.

The goal is just to give people that information on a per-algorithm basis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Documentation-related items.
Projects
Status: Todo
Development

No branches or pull requests

2 participants