GPU-Accelerated Data Manipulation and Preparation
Free NVIDIA-Certified Associate: Accelerated Data Science practice — 6 questions on GPU-Accelerated Data Manipulation and Preparation, with explanations. No sign-up. Full 12-question mixed test →
A data science team has an existing pandas ETL script that calls a third-party plotting library, which internally manipulates pandas objects. They want to accelerate the script using `cudf.pandas` (`%load_ext cudf.pandas` / `python -m cudf.pandas script.py`) without modifying the third-party library. When `cudf.pandas` encounters an operation inside that library which is not implemented on the GPU, what actually happens?
cudf.pandas is a proxy layer that dispatches each operation to cuDF when supported and falls back per-operation to CPU pandas when not, so unsupported calls in third-party code do not break the script.
A cuDF Series holding free-text log messages is queried with `series.str.contains(pattern, regex=True)`, where `pattern` uses a Python-specific regex feature such as a lookahead assertion `(?=...)`. What is the most likely outcome?
cuDF's GPU string regex engine implements a restricted regex grammar for performance and does not support advanced constructs like lookahead/lookbehind, so such patterns either error out or behave unexpectedly.
A developer notices that in pandas, adding a missing value to an integer column forces pandas to upcast the entire column to float64 (using NaN as the missing-value sentinel), but performing the same operation in cuDF keeps the column as int64 with missing entries intact. What explains cuDF's behavior?
cuDF adopts the Arrow columnar memory model, where each column carries a separate validity (null) bitmask alongside its data buffer, allowing nulls to be represented in any dtype — including integers — without needing a float sentinel like NaN.
A pipeline runs `left.merge(right, on='id', how='inner')` on two cuDF DataFrames, and downstream code assumes the resulting row order matches the row order of `left`. This assumption held with the equivalent pandas merge but occasionally breaks when running the same logic with cuDF on GPU. What is the correct explanation and recommended fix?
cuDF merges typically use GPU hash-join algorithms whose output row order is not guaranteed to match either input DataFrame's order; code that depends on order must request sorting explicitly or re-sort after the merge.
A benchmarking task requires generating a large synthetic timeseries DataFrame directly in GPU memory — including an id column, a timestamp index, and several random float columns — without first constructing it in pandas and copying it to the GPU. Which RAPIDS approach is the intended, native way to accomplish this?
cuDF ships `cudf.datasets.timeseries()`, which generates a synthetic timeseries DataFrame directly on the GPU for benchmarking and testing, avoiding a CPU-to-GPU copy step.
A team needs to apply a custom Python function to each group of a cuDF `groupby` object to perform a non-trivial numeric transformation not available as a built-in cuDF aggregation. Calling `.apply(custom_func)` directly (as they would in pandas) runs extremely slowly. What is the recommended RAPIDS approach to accelerate this workload?
cuDF supports JIT-compiling user-defined functions via Numba for groupby `apply`, generating actual GPU kernels for the UDF; writing the function in a Numba-compatible style is the recommended way to get GPU-accelerated performance instead of falling back to slow, non-compiled execution.
Ready for the real thing?
The full course: two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed explanations.
$99.99 $34.99 with code FREETEST33 — valid through September 7.
Get my $34.99 deal →