GPU-Accelerated Data Science Fundamentals
Free NVIDIA-Certified Professional: Accelerated Data Science practice — 6 questions on GPU-Accelerated Data Science Fundamentals, with explanations. No sign-up. Full 12-question mixed test →
A data pipeline moves NumPy arrays from host to a GPU-backed cuDF workflow using thousands of separate transfer calls, each moving less than 1MB. Profiling shows total runtime is dominated by transfer overhead rather than the achievable PCIe bandwidth. Which change BEST addresses this bottleneck?
Small, frequent host-to-device transfers are latency-bound because each transfer pays a fixed setup cost regardless of size. Consolidating into fewer, larger transfers amortizes that overhead, and pinned memory enables faster DMA-based copies instead of pageable-memory staging, directly targeting the measured bottleneck.
A team must deploy an identical RAPIDS environment across on-prem workstations and cloud GPU instances that run different host OS versions, and they need CUDA toolkit and driver compatibility that is validated and supported by NVIDIA. Which deployment approach BEST satisfies this requirement?
NGC container images are pre-built, tested, and versioned by NVIDIA against specific CUDA toolkit and driver combinations, giving guaranteed compatibility and reproducibility across heterogeneous host OS versions without per-host build or dependency resolution work.
You initialize RMM with a pool allocator to reduce allocation fragmentation, but you want the pool to be able to grow beyond its initial size if the workload needs more memory, rather than failing or falling back to raw cudaMalloc. Which RMM configuration achieves this?
RMM's pool allocator supports specifying both an initial_pool_size and a larger maximum_pool_size, letting the pool start small and expand on demand as the workload requires more memory, while still keeping allocations pooled to reduce fragmentation.
A cuDF workflow allocates a working set larger than physical GPU memory using CUDA Unified Memory (RMM managed_memory=True). When the workflow accesses data pages that are not currently resident on the GPU, what actually happens?
CUDA Unified Memory allows oversubscription: memory can be logically allocated beyond physical GPU capacity, and accessing non-resident pages triggers on-demand page migration between host and device, which works correctly but introduces page-fault latency that can significantly slow the workload compared to fully GPU-resident data.
A pandas workflow performs groupby and merge operations on a 50MB CSV and completes in about 2 seconds on a single CPU core. A junior engineer proposes porting this exact workflow to cuDF on an A100 GPU expecting a speedup. What is the MOST accurate assessment and recommendation?
For small datasets, fixed costs — host-to-device transfer, CUDA context/kernel launch overhead — dominate over the already-fast CPU execution time, so GPU acceleration typically does not pay off until data volume and operation complexity are large enough to amortize those costs. The correct guidance is to stay on CPU (pandas) until scale justifies the switch.
A Dask-CUDA cluster (LocalCUDACluster) spans 4 GPUs and runs a groupby-aggregate job on a dataset larger than the combined GPU memory across all 4 devices. The job repeatedly fails with GPU out-of-memory errors before completing, even though total GPU memory is close to the dataset size. Which change most directly resolves this without reducing the dataset size?
Dask-CUDA supports spilling GPU data to host memory (and optionally disk) when a configured device_memory_limit is reached, using mechanisms like JIT-unspill. This lets a working set larger than aggregate GPU memory complete successfully by offloading less-active data rather than erroring out, without shrinking the input dataset.
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.
$129.99 $34.99 with code FREETEST33 — valid through September 9.
Get my $34.99 deal →