What Irregularity Costs: CUDA C++, Rust, and Triton on a Hash-Blocked GPU Workload

Il Palcoscenico e i Protagonisti

Immaginate di cercare di costruire un modello 3D di una stanza utilizzando una fotocamera che scatta migliaia di foto. Per far sì che ciò avvenga, il vostro computer deve organizzare una quantità massiccia di dati su ogni minuscola porzione di spazio in quella stanza. Questo è il mondo della programmazione GPU, dove le "GPU" sono i chip grafici superveloci all'interno dei computer, che sono anche bravissimi a eseguire milioni di calcoli matematici contemporaneamente.

Di solito, quando le persone confrontano diversi linguaggi di programmazione per questi chip, li testano su compiti molto ordinati e prevedibili, come moltiplicare enormi griglie di numeri. È come testare un'auto da corsa su un'autostrada perfettamente dritta e vuota. Ogni corsia è la stessa e ogni pilota sa esattamente quanto durerà la gara. Ma il mondo reale è disordinato. In applicazioni come la realtà virtuale o la navigazione dei robot, il computer deve gestire dati caotici e imprevedibili. È come mandare quella stessa auto da corsa in una strada cittadina affollata e tortuosa, dove gli ingorghi capitano casualmente e i conducenti devono fermarsi e ripartire continuamente. Questo articolo pone una domanda semplice ma cruciala: quando la strada diventa disordinata, tutti i linguaggi di programmazione si comportano allo stesso modo, o alcuni rimangono bloccati nel traffico mentre altri sfrecciano via?

Lo Scontro tra i Linguaggi GPU

In questo studio, i ricercatori hanno preso tre modi popolari per comunicare con questi super-chip — CUDA C++ (lo standard classico scritto a mano), Rust (un linguaggio moderno noto per la sua sicurezza) e Triton (uno strumento più recente progettato per rendere la codifica più facile) — e li hanno messi al lavoro su un compito molto specifico e caotico: costruire una mappa 3D di una stanza utilizzando una "tabella hash" (hash table).

Pensate a una tabella hash come a un enorme e caotico spogliatoio. Avete migliaia di persone (punti dati) che cercano di trovare un armadietto (un posto nella memoria) per riporre le loro cose. A volte l'armadietto che desiderano è vuoto, quindi lo prendono. Ma spesso, l'armadietto è già occupato, quindi devono controllare quello successivo, e quello dopo ancora, finché non trovano un posto libero. In un mondo perfetto, tutti trovano un armadietto istantaneamente. In questo carico di lavoro "irregolare", alcuni trovano gli armadietti immediatamente, mentre altri devono cercare a lungo, e tutti combattono per gli stessi pochi armadietti contemporaneamente.

I ricercatori hanno eseguito lo stesso identico lavoro su tutti e tre i linguaggi e hanno misurato quanto tempo ci avevano impiegato per finire. I risultati sono stati uno shock: i linguaggi si sono comportati in modo completamente diverso a seconda del tipo di lavoro.

La Parte "Regolare": Un Pareggio

Per prima cosa, hanno testato la parte "regolare" del lavoro, che è come camminare in un corridoio e dipingere ogni parete che si vede. Questa parte è prevedibile. Su questo compito, tutti e tre i linguaggi erano quasi identici. Che usaste il classico CUDA, il moderno Rust o l'facile-da-usare Triton, finivano all'incirca nello stesso tempo. Se guardaste solo a questi test ordinati e prevedibili (cosa che la maggior parte degli altri studi fa), pensereste che non importi quale linguaggio scegliate.

La Parte "Irregolare": La Grande Scissione

Poi, hanno testato la parte "irregolare": la ricerca caotica nello spogliatoio. Qui la storia cambia drasticamente.

• Rust vs. CUDA C++: Il linguaggio Rust ha performato quasi esattamente bene quanto il CUDA C++ scritto a mano. Era solo un pochino più lento (circa l'1% o il 3% in alcuni casi), il che è praticamente un pareggio. Rust ha dimostato di poter gestire il traffico disordinato e imprevedibile altrettanto bene del veterano.
• La Lotta di Triton: Triton, tuttavia, si è scontrato con un muro enorme. Nel compito di ricerca caotica, era più di 10 volte più lento degli altri due. In alcuni test del mondo reale con scansioni di stanze reali, era quasi 30 volte più lento.

Perché Triton è Rimasto Bloccato?

I ricercatori non si sono limitati a dire "Triton è lento"; hanno capito esattamente perché fosse bloccato, e non era perché il codice fosse scritto male. Era dovuto a come il linguaggio è costruito.

Immaginate che Triton sia un insegnante severo che insiste affinché ogni studente in una classe debba rimanere al proprio posto per un tempo fisso, anche se finisce il proprio lavoro in anticipo. Nel caotico spogliatoio, alcuni thread (studenti) trovano un armadietto in un secondo, mentre altri ne impiegano dieci.

• Il Problema: Triton costringe i thread veloci ad aspettare in un ciclo finché il thread più lento non finisce, anche se non hanno più nulla da fare. È come una gara in cui il vincitore deve stare fermo ad aspettare che l'ultimo corridore tagli il traguardo prima che chiunque possa lasciare la pista.
• Il Problema della "Maschera": Inoltre, Triton manca di uno strumento specifico (chiamato "maschera") che permetta ai thread veloci di smettere completamente di lavorare. Inveve, devono continuare a eseguire un compito fittizio, sprecando energia e intasando il sistema. I ricercatori hanno scoperto che questa scelta di progettazione ha costretto il computer a fare una quantità enorme di lavoro inutile, rallentando tutto di un fattore di 10 o 30.
• Un Pericolo Nascosto: C'era anche un problema di sicurezza. Poiché Triton impone un limite di tempo fisso alla ricerca, se lo spogliatoio diventa troppo affollato, la ricerca potrebbe arrendersi e smettere di cercare. Ciò significa che il computer scarta silenziosamente parti della stanza 3D, creando buchi invisibili nel modello finale. I ricercatori hanno scoperto che, a determinati livelli di affollamento, Triton perderebbe interi pezzi della superficie, mentre gli altri linguaggi li trovavano perfettamente.

Perché Rust Era Leggermente Più Lento (La Trappola Invisibile)

Rust era molto vicino alla vittoria, ma non era veloce quanto il codice CUDA scritto a mano. I ricercatori hanno passato molto tempo a cercare di capire il perché, controllando il numero di istruzioni e la memoria utilizzata. Hanno scoperto che Rust stava in realtà facendo meno lavoro di CUDA, eppure era comunque più lento.

Il colpevole era una trappola nascosta nel modo in cui Rust gestisce la sicurezza. Rust ha una funzione che rende la lettura dei dati condivisi "sicura", assicurando che tutti vedano la stessa versione. Tuttavia, su questi chip specifici, il modo "sicuro" di leggere i dati costringe il computer a saltare la sua cache di memoria più veloce per andare verso una più lenta. È come un guardiano della sicurezza che insiste nel controllare ogni singolo pacco alla porta d'ingresso, anche se i pacchi sono già noti per essere sicuri. Questo passaggio extra ha rallentato Rust di circa il 20-30%, ma è stato un prezzo esiguo rispetto al massiccio rallentamento di Triton.

Il Messaggio Principale

La lezione principale di questo articolo è che non potete giudicare un linguaggio di programmazione solo in base a come performa su compiti ordinati e prevedibili.

Se testate solo sull'autostrada "regolare", Rust, CUDA e Triton sembrano tutti campioni. Ma una volta lanciati nel traffico cittadino "irregolare" della mappatura 3D del mondo reale, i risultati si dividono nettamente.

• Rust è un forte contendente, rimanendo quasi veloce quanto il miglior codice scritto a mano.
• Triton, pur essendo ottimo per i compiti ordinati, fatica enormemente con il lavoro caotico e imprevedibile, diventando decine di volte più lento e potenzialmente perdendo dati senza che nessuno se ne accorga.

I ricercatori concludono che per compiti che coinvolgono dati disordinati del mondo reale, scegliere il linguaggio sbagliato non è solo un piccolo inconveniente; può rendere il vostro programma inutilizzabile o causarne il fallimento silenzioso. Hanno anche scoperto che molti studi precedenti hanno perso questo dettaglio perché hanno testato solo le parti "regolari", lasciando inesplorate le parti pericolose e disordinate.