-
Notifications
You must be signed in to change notification settings - Fork 175
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
[EPIC]: CUB large input support #50
Labels
2.8.0
target for 2.8.0 release
cub
For all items related to CUB
feature request
New feature or request.
Comments
3 tasks
jrhemstad
changed the title
Determine and finalize design for large input support in CUB
CUB large input support
Apr 21, 2023
miscco
added
feature request
New feature or request.
cub
For all items related to CUB
labels
Jul 12, 2023
legend for offset type: ✅ considered done | 🟡 considered lower priority | 🟠 considered higher priority, as it prevents usage for larger-than- legend for testing columns: ✅ considered done | 🟡 to be done | 🟠 needs to support wider offset types first
|
This was referenced Feb 21, 2024
This was referenced Apr 3, 2024
This was referenced Apr 30, 2024
Closed
10 tasks
2 tasks
This was referenced Aug 12, 2024
4 tasks
elstehle
changed the title
[FEA]: CUB large input support
[EPIC]: CUB large input support
Dec 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
2.8.0
target for 2.8.0 release
cub
For all items related to CUB
feature request
New feature or request.
As a lower-level interface, CUB should optimize for flexibility and performance. As a result, CUB will not guarantee a large input will work by default. However, it should enable users to specify their desired offset type.
This means CUB should not perform any dynamic dispatch based on the input size. Instead, users should have a way to statically specify the offset type. In previous discussion we favored making the type of
num_items
a template and infer the offset type from the type ofnum_items
.Design-related research
Testing large number of items
DeviceSegmentedRadixSort
#2139DeviceSegmentedSort
#2140DeviceScan::*ByKey
Enable large
num_items
in CUB algorithms that are sensitive to the choice ofoffset_t
num_items
todevice_scan.cuh
#2062num_items
toDeviceScan::*ByKey
#2458num_items
todevice_select.cuh
#1422num_items
todevice_partition.cuh
#1437num_items
toDevicePartition::ThreeWayPartition
#2442num_items
toDeviceReduce::{ArgMin,ArgMax}
#2515num_items
tocub::DeviceTransform
#2714device_segmented_sort.cuh
#3132num_items
todevice_merge.cuh
#3134num_items
todevice_segmented_radix_sort.cuh
#3133num_items
toDeviceSegmentedReduce::{ArgMin,ArgMax}
#2522num_items
toDeviceRunLengthEncode::Encode
#2521num_items
toDeviceRunLengthEncode::NonTrivialRuns
#2520DeviceSegmentedReduce
#3242Add support for largenum_items
todevice_spmv.cuh
Limit the number of kernel template instantiations by reducing the set of offset types
DeviceMergeSort
#3312Clean up interim testing infrastructure
Device*
interface inDeviceSelect
Device*
interface inDeviceScan
Documentation
Dispatch
interface (see Portthrust::merge[_by_key]
to CUB #1817 (comment))The text was updated successfully, but these errors were encountered: