Xlera8

Speculatie voor simulatie. Innovatie in verificatie

Dit is een interessant idee, waarbij gebruik wordt gemaakt van door hardware ondersteund speculatief parallellisme om simulatie te versnellen, met een draai die aangepaste hardware vereist. Paul Cunningham (Senior VP/GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, ondernemer, voormalig CTO van Synopsys en nu CTO van Silvaco) en ik vervolgen onze serie over onderzoeksideeën. Zoals altijd, feedback welkom.

Speculatie voor simulatie

De innovatie

De keuze van deze maand is Chronos: efficiënte speculatieve parallelliteit voor versnellers. De auteurs presenteerden de paper op de 2020 Conference on Architectural Support for Programming Languages ​​and Operating Systems en zijn afkomstig van MIT.

Het benutten van parallellisme met behulp van multicore-processors is een optie voor toepassingen waarbij parallellisme vanzelfsprekend is. Andere algoritmen kunnen misschien niet zo gemakkelijk worden gepartitioneerd, maar kunnen profiteren van speculatieve uitvoering die misbruik maakt van intrinsiek parallellisme. Gewoonlijk hangt speculatieve uitvoering af van cache-coherentie, een hoge overhead, vooral voor simulatie. Deze methode omzeilt de behoefte aan coherentie, door taakuitvoering fysiek te lokaliseren om tegels te berekenen op doellees-schrijfobject, zodat conflictdetectie lokaal kan worden gedetecteerd, zonder dat er wereldwijd coherentiebeheer nodig is. Taken kunnen speculatief parallel worden uitgevoerd; elk gedetecteerd conflict kan worden uitgerold van een taak via de onderliggende taken en vervolgens opnieuw worden uitgevoerd zonder dat andere threads moeten worden geblokkeerd.

Een ander punt van aandacht hier. Deze methode ondersteunt op vertraging gebaseerde simulatie, in tegenstelling tot de meeste hardwareversnellingstechnieken.

De mening van Paul

Wauw, wat een prachtig papier met een hoog octaangehalte van MIT! Als ik word gevraagd naar parallelle berekeningen, denk ik meteen aan threads, mutexen en geheugencoherentie. Dit is natuurlijk hoe moderne multi-core CPU's zijn ontworpen. Maar het is niet de enige manier om parallellisatie in hardware te ondersteunen.

Dit artikel stelt een alternatieve architectuur voor parallellisatie voor, genaamd Chronos, die gebaseerd is op een geordende wachtrij van taken. Tijdens runtime worden taken uitgevoerd in tijdstempelvolgorde en elke taak kan nieuwe subtaken creëren die dynamisch aan de wachtrij worden toegevoegd. De uitvoering begint door enkele initiële taken in de wachtrij te plaatsen en eindigt wanneer er geen taken meer in de wachtrij staan.

Taken in de wachtrij worden parallel uitbesteed aan meerdere verwerkingselementen (PE's), wat betekent dat Chronos speculatief toekomstige taken uitvoert voordat de huidige taak is voltooid. Als de huidige taak speculatief uitgevoerde toekomstige taken ongeldig maakt, worden de acties van die toekomstige taken "ongedaan gemaakt" en worden ze opnieuw in de wachtrij geplaatst. Dit concept correct implementeren in hardware is niet eenvoudig, maar voor de externe gebruiker is het prachtig: je codeert gewoon je algoritme alsof de taakwachtrij serieel wordt uitgevoerd op een enkele PE. U hoeft geen mutexen te coderen of u zorgen te maken over een impasse.

De auteurs implementeren Chronos in SystemVerilog en compileren het naar een FPGA. Een groot deel van het artikel is gewijd aan het uitleggen hoe ze de taakwachtrij hebben geïmplementeerd en het eventueel noodzakelijke uitrollen van hardware voor maximale efficiëntie. Chronos is gebenchmarkt op vier algoritmen die zeer geschikt zijn voor een op taken gebaseerde architectuur. Elk algoritme wordt op twee manieren geïmplementeerd: eerst met behulp van een speciale algoritme-specifieke PE, en ten tweede met behulp van een kant-en-klare open source 32-bits embedded RISC-V CPU als de PE. De prestaties van Chronos worden vervolgens vergeleken met multi-threaded software-implementaties van de algoritmen die draaien op een Intel Xeon-server met een vergelijkbaar prijskaartje als de FPGA die voor Chronos wordt gebruikt. De resultaten zijn indrukwekkend - Chronos schaalt 3x tot 15x beter dan het gebruik van de Xeon-server. Als ik Tabel 3 met Afbeelding 14 vergelijk, maak ik me echter een beetje zorgen dat de meeste van deze voordelen voortkwamen uit de algoritmespecifieke PE's en niet uit de Chronos-architectuur zelf.

Aangezien dit een verificatieblog is, heb ik natuurlijk ingezoomd op de simulatiebenchmark op poortniveau. De EDA-industrie heeft zwaar geïnvesteerd in het parallelliseren van logische simulatie en het is moeilijk gebleken om grote winsten te zien die verder gaan dan een paar specifieke use-cases. Dit is voornamelijk te wijten aan het feit dat de prestaties van de meeste real-world simulaties worden gedomineerd door laad-/opslaginstructies die ontbreken in de L3-cache en uitgaan naar DRAM. Er is slechts één testcase gebenchmarkt in dit artikel en het is een kleine 32-bits carry-save-opteller. Als je deze blog aan het lezen bent en geïnteresseerd zou zijn in een meer grondige benchmarking, laat het me dan weten. Als Chronos echt goed kan schalen op real-world simulaties, zou het een enorme commerciële waarde hebben!

De mening van Raúl

De belangrijkste bijdrage van dit artikel is de Ruimtelijk gelegen geordende taken (SLOT) uitvoeringsmodel wat efficiënt is voor hardwareversnellers die gebruikmaken van parallellisme en speculatie, en voor toepassingen die tijdens runtime dynamisch taken genereren. Ondersteuning voor dynamische parallelliteit is onvermijdelijk voor simulatie en speculatieve synchronisatie is een aantrekkelijke optie, maar de coherentieoverhead is te hoog.

SLOT vermijdt de behoefte aan coherentie door elke taak te beperken tot het werken (schrijven) op een enkel object en ondersteunt geordende taken om atomiciteit met meerdere objecten mogelijk te maken. SLOT-applicaties zijn geordende, dynamisch gecreëerde taken die worden gekenmerkt door een tijdstempel en een object-ID. Tijdstempels specificeren orderbeperkingen; object-ID's specificeren de gegevensafhankelijkheden, dwz taken zijn gegevensafhankelijk als en slechts als ze dezelfde object-ID hebben. (als er een leesafhankelijkheid is, kan de taak speculatief worden uitgevoerd). Conflictdetectie wordt lokaal (zonder complexe volgstructuren) door object-ID's toe te wijzen aan kernen of tegels en elke taak te sturen naar waar de object-ID is toegewezen.

De Chronos systeem is geïmplementeerd in het AWS FPGA-framework als een systeem met 16 tegels, elk met 4 applicatiespecifieke verwerkingselementen (PE), draaiend op 125 MHz. Dit systeem wordt vergeleken met een baseline bestaande uit 20-core/40-thread 2.4 GHz Intel Xeon E5-2676v3, speciaal gekozen omdat de prijs vergelijkbaar is met die van FPGA (ongeveer $ 2/uur). Chronos voert een enkele taak uit op één PE en is 2.45x sneller dan de basislijn. Naarmate het aantal gelijktijdige taken toeneemt, schaalt de Chronos-implementatie naar een relatieve versnelling van 44.9x op 8 tegels, wat overeenkomt met een versnelling van 15.3x ten opzichte van de CPU-implementatie. Ze vergeleken ook een implementatie op basis van RISC-V voor algemene doeleinden in plaats van toepassingsspecifieke PE's; PE's waren 5x sneller dan RISC-V.

Ik vond de paper indrukwekkend omdat het alles behandelt, van een concept tot de definitie van het SLOT-uitvoeringsmodel tot de implementatie van hardware en de gedetailleerde vergelijking met een traditionele Xeon CPU voor 4 applicaties. De inspanning is aanzienlijk, Chronos is meer dan 20,000 regels van SystemVerilog. Het resultaat is een 5.4x gemiddelde (van de 4 applicaties) versnelling ten opzichte van software-parallelle versies, vanwege meer parallellisme en meer gebruik van speculatieve uitvoering. Het artikel is ook de moeite waard om te lezen voor toepassing op niet-simulatietaken; het papier bevat drie voorbeelden.

Deel dit bericht via:

Chat met ons

Hallo daar! Hoe kan ik u helpen?