A data scientist loads a 500-row CSV into a cuDF DataFrame, applies a single group-by aggregation, and finds the operation is slower than the equivalent pandas operation. What is the most likely explanation?
- AcuDF does not support group-by aggregations on small DataFrames and falls back silently to a CPU-based path.
- BGroup-by aggregations require sorting as a prerequisite, and sorting is a serial algorithm that GPUs cannot accelerate compared to a modern CPU core.
- CThe GPU's clock speed is lower than a modern CPU's single-core clock speed, so any single-threaded aggregation step will always be slower on the GPU.
- DThe host-to-device and device-to-host data transfers dominate the total wall-clock time when the dataset is small, erasing any parallelism benefit from the GPU kernel itself. Correct
Why A is wrong: cuDF does support group-by aggregations regardless of DataFrame size; there is no automatic silent fallback that would explain the slowdown as a capability gap.
Why B is wrong: Sorting is not strictly required for all group-by strategies, and GPU-based radix and merge sorts can be faster than CPU sorts for larger data; this reasoning does not explain the small-data slowdown.
Why C is wrong: While GPUs do have lower per-core clock speeds, cuDF group-by operations are data-parallel and use thousands of CUDA cores simultaneously; raw clock speed comparison is not the correct explanation for this scenario.
Why D is correct: GPU acceleration carries a fixed overhead for copying data across the PCIe bus. On a 500-row dataset the transfer cost exceeds the compute savings, making the GPU path net slower than an in-process pandas call.