Molti data scientist passano gran parte del tempo su dati tabulari, workload storicamente eseguiti su CPU. Un articolo di Towards Data Science apre una serie che percorre una tipica pipeline di machine learning per capire, passo dopo passo, dove la GPU acceleration è già disponibile e quanto codice serve cambiare. Il primo capitolo riguarda la data preparation, usando come dataset i NYC Yellow Taxi Trip Records (i primi tre mesi, circa 9–10 milioni di righe).
Due strade per portare pandas su GPU
La prima è l’API nativa cuDF, parte di RAPIDS, la suite open source di NVIDIA per data science accelerata. cuDF espone un’API simile a pandas ma esegue le operazioni sulla GPU: nella maggior parte dei casi basta sostituire pandas.read_* con cudf.read_*. Attenzione però: non è un drop-in replacement completo, quindi alcuni comportamenti possono differire. Il passaggio dei dati tra CPU e GPU si gestisce con cudf.from_pandas e to_pandas, utile quando una libreria a valle supporta solo pandas.
La seconda strada è cudf.pandas, una modalità accelerator che velocizza il codice pandas esistente senza modificarlo: basta caricare l’estensione con %load_ext cudf.pandas prima di importare pandas. Ogni operazione viene tentata prima sulla GPU con cuDF e, se non supportata, ricade automaticamente su pandas in CPU. È incluso anche un profiler (%%cudf.pandas.profile e la variante line_profile) che mostra quali operazioni sono girate su GPU e quali sono cadute in fallback.
Il Polars GPU Engine
Chi usa Polars può sfruttare il suo GPU engine, anch’esso basato su cuDF. Con la Lazy API, l’unica differenza è passare engine="gpu" a collect(): Polars costruisce un query plan ottimizzato e, se le operazioni sono supportate, le esegue con cuDF, altrimenti torna al motore CPU. Le funzioni Python passate con map_elements(), ad esempio, non sono supportate dal GPU engine e forzano il fallback. Per dataset più grandi o più GPU, si può passare a RayEngine, che usa tutte le GPU visibili al processo.
Quando conviene davvero
La conclusione dell’autrice è pragmatica: le GPU danno il massimo su operazioni grandi e data-intensive come filtering, join, groupby aggregation e sorting. Per i dataset piccoli, invece, le CPU sono spesso altrettanto veloci, perché l’overhead di spostare i dati sulla GPU annulla il vantaggio. Il punto è che oggi non serve riscrivere l’intera codebase: si può alternare esecuzione GPU e CPU a seconda del workload.
In sintesi
- cuDF (API nativa) e
cudf.pandas(accelerator con fallback automatico) coprono i due scenari principali per accelerare pandas su GPU. - Il Polars GPU Engine attiva l’accelerazione con un solo parametro in
collect(), con fallback su CPU per operazioni non supportate. - Il vantaggio GPU emerge su join, groupby e sorting di grandi dataset; su dati piccoli l’overhead di trasferimento rende la CPU competitiva.
Fonte: How Much of a Data Science Workflow Can Run on a GPU Today? Part 1: Accelerating Data Preparation — https://towardsdatascience.com/how-much-of-a-data-science-workflow-can-run-on-a-gpu-today-part-1-accelerating-data-preparation/
Hai qualcosa da aggiungere? Unisciti alla discussione.