A team maintains a large existing ETL script written against pandas that performs several merges, group-by aggregations, and column assignments on multi-gigabyte tables. They want GPU acceleration with the fewest possible edits to the script's logic, ideally without rewriting the pandas calls themselves. Which mechanism is purpose-built to deliver GPU acceleration for an existing pandas script with minimal code change?
- AReplace every pandas DataFrame construction in the script with an explicit cuDF DataFrame construction and rewrite each operation against the cuDF API by hand.
- BEnable the cudf.pandas accelerator so the existing pandas calls are dispatched to cuDF on the GPU where supported and fall back to pandas on the CPU otherwise, leaving the script's pandas code essentially unchanged. Correct
- CWrap the whole pandas script in a Dask delayed graph so the scheduler dispatches the unchanged pandas calls to GPU workers automatically.
- DMove the script onto a larger-memory CPU node and increase the number of worker threads, which gives pandas the same throughput as a GPU without changing the library.
Why A is wrong: Porting to the cuDF API does give GPU acceleration, but it requires editing every operation in the script, which is the opposite of the minimal-change goal the team set.
Why B is correct: The cudf.pandas accelerator intercepts pandas operations and routes them to cuDF on the GPU when supported, falling back to CPU pandas when not, delivering acceleration with essentially no changes to the script's pandas logic.
Why C is wrong: Dask can distribute work, but wrapping pandas in Dask delayed produces a CPU pandas task graph; it does not transparently turn pandas calls into GPU operations, so this does not accelerate the existing calls on the device.
Why D is wrong: More CPU memory and threads can help marginally, but pandas operations are largely single-threaded and CPU-bound, so this neither matches GPU throughput nor provides the acceleration the team wants.