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

Het Podium en de Spelers

Stel je voor dat je een 3D-model van een kamer probeert te bouwen met behulp van een camera die duizenden foto's maakt. Om dit mogelijk te maken, moet je computer een enorme hoeveelheid gegevens organiseren over elk minuscuul stukje ruimte in die kamer. Dit is de wereld van GPU-programmering, waar "GPU's" de supersnelle grafische chips in computers zijn die ook nog eens briljant zijn in het tegelijkertijd uitvoeren van miljoenen wiskundige berekeningen.

Meestal, wanneer mensen verschillende programmeertalen voor deze chips vergelijken, testen ze ze op zeer nette, voorspelbare taken, zoals het vermenigvuldigen van gigantische rasters met getallen. Het is alsof je een racewagen test op een perfect rechte, lege snelweg. Elke rijstrook is hetzelfde en elke bestuurder weet precies hoe lang de race zal duren. Maar de echte wereld is rommelig. In toepassingen zoals virtuele realiteit of robotnavigatie moet de computer omgaan met chaotische, onvoorspelbare gegevens. Het is alsof je diezelfde racewagen naar een drukke, kronkelende stadsstraat stuurt, waar verkeersopstoppingen willekeurig ontstaan en bestuurders constant moeten stoppen en optrekken. Dit artikel stelt een eenvoudige maar cruciale vraag: Wanneer de weg rommelig wordt, presteren alle programmeertalen dan hetzelfde, of komen sommigen vast te zitten in de file terwijl anderen er dwars doorheen racen?

De Grote GPU-Taalstrijd

In dit onderzoek namen onderzoekers drie populaire manieren om met deze superchips te communiceren — CUDA C++ (de oude, handgeschreven standaard), Rust (een moderne taal die bekend staat om veiligheid) en Triton (een nieuwere tool die het coderen makkelijker maakt) — en zetten ze aan het werk op een zeer specifieke, chaotische taak: het bouwen van een 3D-kaart van een kamer met behulp van een "hash tabel".

Beschouw een hash tabel als een enorme, chaotische kleedkamer. Je hebt duizenden mensen (datapunten) die proberen een kluisje (een plek in het geheugen) te vinden om hun spullen op te bergen. Soms is het kluisje dat ze willen leeg, dus nemen ze het. Maar vaak is het kluisje al bezet, dus moeten ze het volgende controleren, en het volgende, totdat ze een open plek vinden. In een perfecte wereld vindt iedereen direct een kluisje. In deze "onregelmatige" werklast vindt een deel van de mensen direct een kluisje, terwijl anderen lang moeten zoeken, en iedereen vecht tegelijkertijd om dezelfde paar kluisjes.

De onderzoekers voerden exact dezelfde taak uit op alle drie de talen en maten hoe snel ze klaar waren. De resultaten waren een schok: De talen gedroegen zich volkomen verschillend, afhankelijk van het type werk.

Het "Reguliere" Deel: Een Gelijke Stand

Eerst testten ze het "reguliere" deel van de taak, wat lijkt op het lopen door een gang en elke muur die je ziet verven. Dit deel is voorspelbaar. Voor deze taak waren alle drie de talen bijna identiek. Of je nu de ouderwetse CUDA gebruikte, de moderne Rust, of de gebruiksvriendelijke Triton, ze waren in ongeveer dezelfde tijd klaar. Als je alleen naar deze nette, voorspelbare tests zou kijken (wat de meeste andere studies doen), zou je denken dat het niet uitmaakt welke taal je kiest.

Het "Onregelmatige" Deel: De Grote Splitsing

Daarna testten ze het "onregelmatige" deel: de chaotische zoektocht in de kleedkamer. Dit is waar het verhaal drastisch verandert.

• Rust versus CUDA C++: De taal Rust presteerde bijna precies even goed als de handgeschreven CUDA C++. Het was slechts een klein beetje langzamer (ongeveer 1% tot 3% in sommige gevallen), wat in de praktijk gelijkstaat aan een gelijkspel. Rust bewees dat het de rommelige, onvoorspelbare file net zo goed kon afhandelen als de veteraan.
• Tritons Strijd: Triton liep echter tegen een enorme muur op. Bij de chaotische zoektaak was het meer dan 10 keer langzamer dan de andere twee. In sommige praktijktests met echte kamer-scans was het zelfs bijna 30 keer langzamer.

Waarom Liep Triton Vast?

De onderzoekers zeiden niet alleen "Triton is traag"; ze ontdekten precies waarom het vastliep, en dat kwam niet omdat de code slecht geschreven was. Het kwam door de manier waarop de taal is opgebouwd.

Stel je voor dat Triton een strenge leraar is die erop staat dat elke leerling in een klas een vastgesteld aantal minuten in zijn stoel moet blijven zitten, zelfs als ze hun werk eerder af hebben. In de chaotische kleedkamer vindt een deel van de threads (leerlingen) een kluisje in één seconde, terwijl anderen tien second seconden nodig hebben.

• Het Probleem: Triton dwingt de snelle threads om in een lus te wachten totdat de langzaamste thread klaar is, ook al hebben zij niets meer te doen. Het is als een race waarbij de winnaar stil moet blijven staan en moet wachten tot de laatste persoon de finishlijn passeert voordat iedereen het parcours mag verlaten.
• Het "Mask"-Probleen: Bovendien beschikt Triton niet over een specif으로 gereedschap (een "masker" genoemd) dat de snelle threads in staat stelt om volledig te stoppen met werken. In plaats daarvan moeten ze een dummy-taak blijven uitvoeren, wat energie verspilt en het systeem verstopt. De onderzoekers ontdekten dat deze ontwerpkeuze de computer dwong om een enorme hoeveelheid nutteloos werk te verrichten, wat alles met een factor 10 tot 30 vertraagde.
• Een Verborgen Gevaar: Er was ook een veiligheidsprobleem. Omdat Triton een vaste tijdslimiet oplegt aan de zoektocht, kan het zijn dat de zoektocht opgeeft en stopt met zoeken als de kleedkamer te druk wordt. Dit betekent dat de computer stilletjes delen van de 3D-kamer weggooit, waardoor er onzichtbare gaten in het uiteindelijke model ontstaan. De onderzoekers ontdekten dat bij bepaalde druktepeilen Triton hele stukken van het oppervlak zou verliezen, terwijl de andere talen deze perfect vonden.

Waarom Rust Iets Langzamer Was (De Onzichtbare Valstrik)

Rust kwam heel dicht bij de winst, maar was net niet zo snel als de handgeschreven CUDA-code. De onderzoekers besteedden veel tijd aan het onderzoeken van waarom, waarbij ze het aantal instructies en het gebruikte geheugen controleerden. Ze ontdekten dat Rust feitelijk minder werk deed dan CUDA, maar toch langzamer was.

De boosdoener was een verborgen valstrik in hoe Rust met veiligheid omgaat. Rust heeft een functie die het lezen van gedeelde gegevens "veilig" maakt door te garanderen dat iedereen dezelfde versie ziet. Echter, op deze specifieke chips dwingt de "veilige" manier om gegevens te lezen de computer om de snelste geheugencache over te slaan en naar een langzamere te gaan. Het is als een beveiliger die erop staat elk pakketje bij de voordeur te controleren, ook al zijn de pakketjes al bekend als veilig. Deze extra stap vertraagde Rust met ongeveer 20-30%, maar dat was een kleine prijs vergeleken met de enorme vertraging van Triton.

De Conclusie

De belangrijkste les van dit artikel is dat je een programmeertaal niet kunt beoordelen op basis van hoe deze presteert bij nette, voorspelbare taken.

Als je alleen test op de "regelmatige" snelweg, zien Rust, CUDA en Triton er allemaal uit als kampioenen. Maar zodewegs je ze in de "onregelmatige" stadsverkeer van echte 3D-mapping werpt, splitsen de resultaten zich radicaal.

• Rust is een sterke kandidaat en blijft bijna even snel als de beste handgeschreven code.
• Triton, hoewel geweldig voor nette taken, worstelt zwaar met chaotisch, onvoorspelbaar werk, waardoor het tientallen malen langzamer wordt en potentieel zonder dat iemand het merkt gegevens verliest.

De onderzoekers concluderen dat bij taken die betrokken zijn bij rommelige, echte gegevens, het kiezen van de verkeerde taal niet slechts een klein ongemak is; het kan je programma onbruikbaar traag maken of ervoor zorgen dat het stilzwijgend faalt. Ze vonden ook dat veel eerdere studies dit misten omdat ze alleen de "regelmatige" delen testten, waardoor de gevaarlijke, rommelige delen onverkend bleven.