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

Implement cupy.partition #162

Closed
takagi opened this issue Jun 18, 2017 · 3 comments · Fixed by #270
Closed

Implement cupy.partition #162

takagi opened this issue Jun 18, 2017 · 3 comments · Fixed by #270
Labels
cat:feature New features/APIs
Milestone

Comments

@takagi
Copy link
Member

takagi commented Jun 18, 2017

cupy.partition, the counterpart of numpy.partition, creates a copy of an array with its elements rearranged in such a way that the value of the element in k-th position is in the position it would be in a sorted array. This function is equivalent to std::nth_element of C++ STL.

numpy.partition
https://docs.scipy.org/doc/numpy/reference/generated/numpy.partition.html

std::nth_element
http://en.cppreference.com/w/cpp/algorithm/nth_element

Unfortunately, neither of the following parallel algorithm libraries implement this kind of parallel selection algorithm:

For now, the most likely is to implement radix select based on CUB's radix sort implementation.

@okuta okuta added the cat:feature New features/APIs label Jun 20, 2017
@takagi
Copy link
Member Author

takagi commented Jun 22, 2017

cupy.partiotion as well as numpy.partition belong to a problem domain called unordered partial sort, which is a very similar problem with selection of kth element.

https://en.wikipedia.org/wiki/Selection_algorithm#Unordered_partial_sorting

There are the following algorithms to solve such kind of problems:

  • Quickselect
  • Median of median
  • Heap select
  • Introselect
  • Radixselect

numpy.partition uses introselect, which is a hybrid algorithm of quickselect and median of medians and does not paralellize well. For GPU environment with CuPy, radixselect would be the most likely option.

The following papers mention on radixselect:

The first paper has its public source code and Tensorflow guys have some discussion on it recently.

@takagi
Copy link
Member Author

takagi commented Jun 24, 2017

I compared the performance of:

  • radixselect on CPU
  • std::sort & choose on CPU
  • thrust::sort & choose on GPU

(Celeron G3900 @ 2.80GHz and GeForce GTX 750 Ti)

Just thrust::sort & choose may be enough at first because its performance fit well to O(n) in time complexity.

https://gist.github.com/sonots/7e11231af2f2cc6b1f519ad832632566

$ nvcc radixselect.cu -O2 -std=c++11 -Wno-deprecated-gpu-targets && ./a.out

----- n = 1000, k = 100
radixselect : 59233 Time elapsed 0.000006 sec
std::sort   : 59233 Time elapsed 0.000043 sec
thrust::sort: 59233 Time elapsed 0.000583 sec

----- n = 10000, k = 1000
radixselect : 59017 Time elapsed 0.000032 sec
std::sort   : 59017 Time elapsed 0.000597 sec
thrust::sort: 59017 Time elapsed 0.000586 sec

----- n = 100000, k = 10000
radixselect : 58992 Time elapsed 0.000347 sec
std::sort   : 58992 Time elapsed 0.006836 sec
thrust::sort: 58992 Time elapsed 0.000436 sec

----- n = 1000000, k = 100000
radixselect : 58953 Time elapsed 0.004255 sec
std::sort   : 58953 Time elapsed 0.074907 sec
thrust::sort: 58953 Time elapsed 0.002840 sec

----- n = 10000000, k = 1000000
radixselect : 58986 Time elapsed 0.039464 sec
std::sort   : 58986 Time elapsed 0.745077 sec
thrust::sort: 58986 Time elapsed 0.023981 sec

----- n = 100000000, k = 10000000
radixselect : 58983 Time elapsed 0.489075 sec
std::sort   : 58983 Time elapsed 7.569387 sec
thrust::sort: 58983 Time elapsed 0.235514 sec

@takagi
Copy link
Member Author

takagi commented Jul 3, 2017

According to Fig. 7 in the paper,

sort & choose has O(N) complexity in time for vector length N as theoretically shown, and is at least just four times slower than radixselect in case vector length is 2^27.

It seems reasonable to first implement cupy.partition with naive sort & choose.

@okuta okuta added this to the Closed issues and PRs milestone Oct 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cat:feature New features/APIs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants