Reproducibility and Transparency Audit of Parallel Runtime Performance Reporting in Open-Source Benchmarks: A Case Study of the Rust, Julia, Haskell, and Python Ecosystems

In de wereld van de computerwetenschappen vergelijken onderzoekers voortdurend verschillende programmeertalen om te zien welke het zware werk beter aan kan. Stel je een team werkers voor die een enorme stapel dozen proberen te verplaatsen. Sommige teams gebruiken één sterke persoon, terwijl andere teams veel mensen gebruiken die samenwerken. In de digitale wereld wordt dit "samenwerken" parallelle prestatie genoemd, waarbij een computer een moeilijke taak verdeelt over meerdere processors om het sneller af te ronden. Wetenschappers gebruiken deze vergelijkingen om te beslissen welke taal ze gaan gebruiken voor alles van weersvoorspellingen tot webdiensten. Echter, voor deze vergelijkingen om betrouwbaar te zijn, moeten de onderzoekers een volledig recept verstrekken van precies hoe ze hun tests hebben uitgevoerd. Ze moeten de specifieke computer vermelden die ze gebruikten, de exacte versie van de software, hoeveel werkers ze aan de taak hebben toegewezen, en hoe ze de tijd hebben gemeten. Zonder deze details is een bewering dat de ene taal sneller is dan de andere slechts een verhaal, en geen wetenschappelijk feit.

Een onderzoeker aan University College London, Magnus Bright, besloot te onderzoeken of wetenschappers daadwerkelijk deze noodzakelijke details verstrekken. In plaats van nieuwe tests op computers uit te voeren, voerde Bright een systematische audit uit van 160 gepubliceerde studies die betrekking hadden op vier populaire programmeertalen: Rust, Julia, Haskell en Python. Het doel was niet om te zien welke taal won, maar om te controleren of de winnaars eerlijk werden uitgeroepen. De studie keek naar papers die gepubliceerd zijn tussen 2015 en 2025, en onderzocht of de auteur de specifieke informatie had opgenomen die nodig is voor iemand anders om het experiment te herhalen en hetzelfde resultaat te krijgen. De bevindingen onthullen een landschap waar sommige details vrijelijk worden gedeeld, terwijl andere vaak ontbreken, waardoor het wetenschappelijke verslag incompleet blijft.

De audit toonde aan dat onderzoekers over het algemeen goed zijn in het rapporteren van de basiszaken. De meeste papers vermelden duidelijk de omvang van de gegevens die ze verwerkten en hoeveel werkers of threads ze gebruikten om deze te verwerken. Dit zijn de meest voor de hand liggende onderdelen van het experiment, en het weglaten ervan zou de resultaten onbegrijpelijk maken. De studie onthulde echter aanzienlijke hiaten in de subtielere, maar cruciale details. Zo rapporteerde slechts ongeveer een derde van de studies hoe zij de initiële "warm-up"-periode afhandelden. Dit is een cruciale stap voor bepaalde talen die zichzelf moeten voorbereiden voordat ze op volle snelheid draaien; zonder te weten hoe lang deze voorbereiding duurde, is het onmogelijk om te weten of de gerapporteerde snelheid echt was of slechts een artefact van de opstelling. Evenzo legde minder dan één op de vier studies uit hoe zij hun werkers op de processors van de computer plaatsten. Deze plaatsing kan de snelheid waarmee een taak wordt uitgevoerd drastisch veranderen, toch lieten de meeste auteurs deze informatie weg.

De situatie was zelfs nog ongelijkmatiger als het ging om statistische nauwkeurigheid. In veel wetenschappelijke velden rapporteren onderzoekers niet alleen een gemiddeld resultaat, maar ook hoeveel dat resultaat varieert. Deze variatie vertelt de lezer of het verschil tussen twee talen echt is of slechts willekeurige ruis. In deze audit bevatte slechts ongeveer 40 procent van de studies enige maatstaf voor deze variatie. Zonder deze maatstaf kan een lezer niet zien of een gerapporteerd snelheidsverschil betekenisvol is of dat het door toeval had kunnen gebeuren. De studie keek ook naar de vraag of de werkelijke code en gegevens beschikbaar waren voor anderen om te controleren. Hoewel bijna 70 procent van de studies de broncode leverde, leverde zeer weinig de volledige omgeving die nodig is om deze te draaien, zoals een vooraf verpakte digitale container die ervoor zorgt dat de software zich exact hetzelfde gedraagt op een andere machine. Slechts ongeveer 9 procent van de studies bood een dergelijke container aan, wat betekent dat zelfs wanneer de code beschikbaar is, het vaak moeilijk is om deze te gebruiken om de resultaten te verifiëren.

De onderzoekers merkten ook op dat de kwaliteit van de rapportage sterk afhing van waar de studie werd gepubliceerd en welke taalcommunity de studie produceerde. Studies die verschenen in podia die gewijd zijn aan high-performance computing systemen waren het meest grondig en bevatten vaak gedetailleerde hardware-specificaties en configuratie-instellingen. In contrast hiermee waren studies in algemene computing-vensters veel minder geneigd deze details op te nemen. Bovendien vertoonden de taalcommunities zelf verschillende gewoonten. De communities rondom Rust en Julia neigden er meer op te letten om softwareversies en compilerinstellingen te rapporteren, waarschijnlijk omdat hun tools zo zijn ontworpen dat dergelijke details gemakkelijk te volgen zijn. De Haskell-community vertoonde de laagste algehele rapportagescores, terwijl Python-studies vaak nalieten te rapporteren hoe vaak ze hun tests hadden uitgevoerd. De studie suggereert dat deze verschillen niet alleen gaan over individuele nauwkeurigheid, maar over de normen en verwachtingen van de specifieke groepen en tijdschriften.

Wanneer de onderzoekers keken naar waarom auteurs deze details achterlieten, kwamen ze erachter dat de redenen vaak praktisch van aard waren in plaats van kwaadwillend. Veel auteurs citeerden strikte pagina-limieten van conferentiepapers als de reden voor het weglaten van lange lijsten met technische specificaties. Anderen namen aan dat bepaalde details zo voor de hand liggend waren voor hun vakgenoten dat ze niet geschreven hoefden te worden. Sommige auteurs gaven simpelweg prioriteit aan de uiteindelijke resultaten boven de methode, in de veronderstelling dat het verhaal van de ontdekking belangrijker was dan het technische recept. De studie benadrukte ook een juridisch en ethisch blinde vlek: in meer dan de helft van de gevallen was het onduidelijk of de gebruikte gegevens of code legaal hergebruikt mochten worden door anderen. Dit gebrek aan duidelijkheid maakt het voor toekomstige onderzoekers moeilijk om voort te bouwen op eerder werk zonder juridische problemen te riskeren.

Om deze problemen aan te pakken, stelt de studie een eenvoudige, minimale checklist voor voor iedereen die een vergelijking van programmeertalen publiceert. Deze checklist vraagt auteurs om de specifieke computerhardware, de exacte softwareversies, de configuratie van de parallelle werkers, de omvang en de bron van de gegevens, hoe vaak de test is uitgevoerd en de statistische maten die zijn gebruikt voor de analyse te vermelden. Het vra much ook om de code en gegevens te delen op een manier die het anderen gemakkelijk maakt om deze te draaien. De studie concludeert dat de geloofwaardigheid van een prestatieclaim volledig afhangt van de documentatie die het ondersteunt. Een snelheidscijfer zonder context is slechts een getal; met de juiste details wordt het een betrouwbaar stuk wetenschappelijke kennis. Door deze duidelijkere standaarden te adopteren, kan de gemeenschap ervoor zorgen dat de aanzienlijke inspanning die in prestatieonderzoek wordt gestoken, leidt tot resultaten die door iedereen vertrouwd, begrepen en erop gebouwd kunnen worden.