-
Notifications
You must be signed in to change notification settings - Fork 928
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
[FEA] Add 64-bit size type option at build-time for libcudf #13159
Comments
On Dictionary errors
AtomicAdd errors
Thrust
Device span errors
Assorted errors
|
The java code right now hard codes a signed 32-bits as the size type in many places. We can switch it to 64-bits everywhere along with a dynamic check depending on how the code is compiled. But also just so you are aware Spark has a top level limitation of a singed 32-bit int for the number of rows in a table. We can work around this in some places, but moving the Spark plugin over to a 64-bit index is not going to be super simple. |
Many libcudf users have expressed interest in using a 64-bit size type (see #3958 for reference). The
cudf::size_type
uses aint32_t
data type that limits the number of elements in libcudf columns toINT_MAX
(2.1 billion) elements. For string columns this imposes a ~2 GB limit, for int32 columns this imposes a ~8 GB limit, and for list columns this imposes a leaf element count <2.1 billion. Downstream libraries must partition their data to avoid these limits.We expect that using a 64-bit size type will incur significant penalties to memory footprint and data throughput. Memory footprint will double for all offset vectors, and runtime of most functions will increase due to the larger data sizes. Kernel performance may degrade even further due to increased register count and unoptimized shared memory usage.
As GPUs increase in memory, the limit from a 32-bit
cudf::size_type
will force data partitions to become smaller fractions of device memory. Excessive data partitioning also leads to performance penalties, so libcudf should enable its community to start experimenting with a 64-bit size type. Scoping for 64-bit size types in the cuDF-python layer will be tracked in a separate issue (#TBD).copy_if
,reduce
,parallel_for
,merge
andsort
may have unresolved issues.cudf::size_type
From this stage we will have a better sense of the impact and value of using a 64-bit size type with libcudf.
The text was updated successfully, but these errors were encountered: