Extending WRSS to Rust, Julia, Haskell, and Python Under Irregular Parallel Workloads

Wanneer ingenieurs software bouwen om enorme problemen op te lossen, breken ze het werk vaak op in kleinere stukjes en verdelen ze deze tegelijkertijd over vele processoren, in de hoop dat de taak sneller wordt voltooid. Deze strategie, bekend als parallel computing, werkt prachtig wanneer het werk perfect gelijkmatig is, zoals het sorteren van een kaartspel waarbij elke stapel hetzelfde aantal kaarten heeft. In deze ordelijke situaties hebben onderzoekers een manier ontwikkeld om exact te meten waar de snelheid stopt met verbeteren, een punt waarop het toevoegen van meer werkers niet langer helpt. Dit meetinstrument, de Workload–Runtime Scaling Signature genoemd, heeft succesvol de grenzen van prestaties in kaart gebracht voor verschillende programmeertalen wanneer de taken voorspelbaar en uniform zijn. De echte wereld is echter zelden zo netjes. Veel wetenschappelijke en zakelijke toepassingen maken gebruik van rommelige, onregelmatige data waarbij sommige werkers een berg werk krijgen terwijl anderen er bijna niets krijgen, wat een verborgen knelpunt creëert dat standaardtools niet kunnen zien.

Een onderzoeker zette zich in om te testen of hun bestaande meetinstrument deze chaos aan kon. Ze namen het raamwerk dat werkte voor nette, regelmatige taken en pasten het toe op vier moeilijke, onregelmatige taken: het doorzoeken van complexe netwerken, het navigeren door diepe beslissingsbomen, het vermenigvuldigen van ijle matrices en het simuleren van deeltjes die door de ruimte bewegen. Ze voerden deze taken uit met vier zeer verschillende programmeertalen — Rust, Julia, Haskell en Python — op een krachtig computersysteem. Het doel was om te zien of de oude methode nog steeds kon aangeven waar de vertragingen optraden wanneer de werkverdeling onvoorspelbaar was en afhankelijk van de data zelf.

De onderzoeker ontdekte dat het oorspronkelijke instrument een cruciaal onderdeel van de puzzel miste. In de oude methode werd alle tijd die aan berekeningen werd besteed, in één enkele categorie gegroepeerd. Maar bij deze onregelmatige taken moest de traagste werker vaak aanzienlijk meer werk verrichten dan de gemiddelde werker, simpelweg omdat de data hen hiertoe dwong. De onderzoeker realiseerde zich dat deze extra last, veroorzaakt door de ongelijkmatige spreiding van het werk, een afzonderlijk probleem was van de totale hoeveelheid berekening die nodig was. Ze stelden een nieuwe manier voor om naar de data te kijken, waarbij de rekentijd werd opgesplitst in twee delen: het gemiddelde werk dat iedereen doet, en het extra, onrechtvaardige werk dat de traagste werker wordt opgelegd. Dit nieuwe, vierdelige beeld onthulde dat de oude driedelige kijk vaak loog over waar het echte knelpunt lag.

Toen de onderzoeker deze nieuwe, meer gedetailleerde kijk toepaste op hun tests, veranderden de resultaten drastisch. Voor taken zoals het doorzoeken van complexe netwerken of het simuleren van deeltjes in dichte clusters, beweerde de oude methode dat de computers nog steeds werden beperkt door de pure hoeveelheid berekening. Het suggereerde dat het toevoegen van meer werkers nog steeds zou helpen. De nieuwe methode liet echter zien dat het echte probleem de onbalans zelf was. In veel gevallen was het extra werk op de traagste werker zo groot dat het de wetenschap maskeerde dat het systeem al een muur had geraakt veroorzaakt door wachten en coördinatie. Bijvoorbeeld, in één test met een netwerk van vier miljoen punten, toonde de nieuwe methode aan dat de onbalans tot wel 34 procent van de totale tijd besloeg, een factor die de oude methode binnen de algemene berekeningscijfers had verborgen.

Deze verschuiving in perspectief veranderde het begrip van de onderzoeker over wanneer men moet stoppen met het toevoegen van werkers. In de oude visie leek een programma goed te schalen tot zestien werkers. In de nieuwe visie toonde hetzelfde programma aan dat de voordelen al bij slechts vier of acht werkers stopten omdat de onbalans het dominante probleem was geworden. De studie vond dat dit nieuwe diagnostische middel essentieel was voor onregelmatige workloads, maar onnodig voor regelmatige taken, waarbij het werk van nature gebalanceerd is. De onderzoeker concludeerde dat zonder het te scheiden van het gemiddelde werk van het extra, onrechtvaardige werk, prestatiestudies ingenieurs systematisch konden misleiden over hoe ze hun software moesten optimaliseren.

De studie benadrukte ook hoe verschillende programmeertalen met deze chaos omgingen. De taal die bekend staat als Rust, die het geheugen zeer strikt beheert, toonde het beste vermogen om het werk in balans te houden, met de kleinste hoeveelheid onrechtvaardige extra tijd. Python, dat een andere aanpak gebruikt voor het uitvoeren van taken, vertoonde de grootste onbalans, waarschijnlijk omdat de methode van het verdelen van het werk te grofmazig was om de fijnmazige onregelmatigheden aan te kunnen. Julia en Haskell vielen ergens tussenin, waarbij Julia enige variabiliteit vertoonde afhankelijk van de specifieke data die het tegenkwam. Deze bevindingen suggereren dat voor rommelige, onvoorspelbare taken, het kiezen van een taal niet alleen gaat over ruwe snelheid, maar over hoe goed die taal de ongelijkmatige last onder de werkers kan verdelen.

Uiteindelijk biedt het onderzoek een duidelijker kaart voor het navigeren door de complexiteiten van moderne computing. Het demonstreert dat wanneer het werk onregelmatig is, de oude vuistregels niet langer van toepassing zijn. Door simpelweg de gemiddelde inspanning te scheiden van de extra last die op de traagste werker wordt gelegd, kunnen ingenieurs eindelijk de ware grenzen van hun systemen zien. Deze helderheid stelt hen in staat om betere beslissingen te nemen over wanneer ze meer kracht moeten toevoegen en wanneer ze zich moeten richten op het balanceren van de last, zodat hun software zo efficiënt mogelijk presteert in de chaotische realiteit van echte werelddata.