Dette er en interessant idé, ved å bruke maskinvarestøttet spekulativ parallellisme for å akselerere simulering, med en vri som krever tilpasset maskinvare. Paul Cunningham (Senior VP/GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, gründer, tidligere Synopsys CTO og nå Silvaco CTO) og jeg fortsetter vår serie om forskningsideer. Som alltid, tilbakemeldinger velkommen.
Innovasjonen
Denne månedens valg er Chronos: Effektiv spekulativ parallellisme for akseleratorer. Forfatterne presenterte artikkelen på 2020-konferansen om arkitektonisk støtte for programmeringsspråk og operativsystemer og er fra MIT.
Å utnytte parallellitet ved å bruke flerkjerneprosessorer er ett alternativ for applikasjoner der parallellisme er innlysende. Andre algoritmer er kanskje ikke så lett å partisjonere, men kan ha nytte av spekulativ utførelse som utnytter iboende parallellisme. Spekulativ utførelse avhenger vanligvis av cache-koherens, en høy overhead spesielt for simulering. Denne metoden omgår behovet for sammenheng, fysisk lokaliserer oppgaveutførelse for å beregne fliser etter mållese-skriveobjekt, og sikrer at konfliktdeteksjon kan oppdages lokalt, uten behov for global koherensstyring. Oppgaver kan utføres spekulativt parallelt; enhver oppdaget konflikt kan rulles ut fra en oppgave gjennom dens underordnede oppgaver og deretter kjøres på nytt uten å måtte stoppe andre tråder.
Et annet punkt å merke seg her. Denne metoden støtter forsinkelsesbasert simulering, i motsetning til de fleste maskinvareakselerasjonsteknikker.
Paulus syn
Wow, for et fantastisk høyoktanpapir fra MIT! Når jeg blir spurt om parallellberegning, tenker jeg umiddelbart på tråder, mutexes og minnekoherens. Dette er selvfølgelig hvordan moderne multi-core CPUer er designet. Men det er ikke den eneste måten å støtte parallellisering i maskinvare.
Denne artikkelen foreslår en alternativ arkitektur for parallellisering kalt Chronos som er basert på en ordnet kø med oppgaver. Under kjøring utføres oppgaver i tidsstempelrekkefølge, og hver oppgave kan opprette nye underoppgaver som legges dynamisk til i køen. Utførelsen begynner med å sette noen innledende oppgaver inn i køen og avsluttes når det ikke er flere oppgaver i køen.
Oppgaver i køen samles ut til flere prosesseringselementer (PE) parallelt – noe som betyr at Chronos spekulativt utfører fremtidige oppgaver før den nåværende oppgaven er fullført. Hvis den nåværende oppgaven ugyldiggjør eventuelle spekulativt utførte fremtidige oppgaver, blir handlingene til disse fremtidige oppgavene "angret" og de settes i kø på nytt. Å implementere dette konseptet riktig i maskinvare er ikke lett, men for den eksterne brukeren er det vakkert: du bare koder algoritmen din som om oppgavekøen kjøres serielt på en enkelt PE. Du trenger ikke å kode mutexes eller bekymre deg for vranglås.
Forfatterne implementerer Chronos i SystemVerilog og kompilerer det til en FPGA. Mye av artikkelen er viet til å forklare hvordan de har implementert oppgavekøen og eventuell nødvendig utrulling i maskinvare for maksimal effektivitet. Chronos er benchmarked på fire algoritmer som er godt egnet til en oppgavekøbasert arkitektur. Hver algoritme implementeres på to måter: først ved å bruke en dedikert algoritmespesifikk PE, og for det andre ved å bruke en hyllevare åpen kildekode 32-bits innebygd RISC-V CPU som PE. Chronos-ytelsen sammenlignes deretter med flertrådede programvareimplementeringer av algoritmene som kjører på en Intel Xeon-server med en lignende prislapp som FPGA-en som brukes for Chronos. Resultatene er imponerende – Chronos skalerer 3x til 15x bedre enn å bruke Xeon-serveren. Men å sammenligne tabell 3 med figur 14 gjør meg litt bekymret for at de fleste av disse gevinstene kom fra de algoritmespesifikke PE-ene i stedet for selve Chronos-arkitekturen.
Gitt at dette er en bekreftelsesblogg har jeg naturlig zoomet inn på gate-nivå simulering benchmark. EDA-industrien har investert tungt for å prøve å parallellisere logikksimulering, og det har vist seg vanskelig å se store gevinster utover noen få spesifikke brukstilfeller. Dette skyldes hovedsakelig at ytelsen til de fleste simuleringer i den virkelige verden domineres av laste-/lagerinstruksjoner som mangler i L3-cachen og går ut til DRAM. Det er bare en testcase som er referanseindeksert i dette papiret, og det er en liten 32-bits lagringsadder. Hvis du leser denne bloggen og er interessert i å gjøre litt mer grundig benchmarking, vennligst gi meg beskjed – hvis Chronos virkelig kan skalere godt på simuleringer i den virkelige verden, vil det ha stor kommersiell verdi!
Raúl syn
Hovedbidraget til denne artikkelen er Romlig lokaliserte ordnede oppgaver (SLOT) utførelsesmodell som er effektiv for maskinvareakseleratorer som utnytter parallellitet og spekulasjoner, og for applikasjoner som genererer oppgaver dynamisk under kjøring. Dynamisk parallellisme-støtte er uunngåelig for simulering og spekulativ synkronisering er et tiltalende alternativ, men koherensoverhead er for høy.
SLOT unngår behovet for sammenheng ved å begrense hver oppgave til å operere (skrive) på et enkelt objekt og støtter ordnede oppgaver for å muliggjøre atomitet med flere objekter. SLOT-applikasjoner er ordnede, dynamisk opprettede oppgaver preget av et tidsstempel og en objekt-ID. Tidsstempler spesifiserer ordrebegrensninger; objekt-IDer spesifiserer dataavhengighetene, dvs. oppgaver er dataavhengige hvis og bare hvis de har samme objekt-ID. (hvis det er en leseavhengighet kan oppgaven utføres spekulativt). Konfliktdeteksjon blir lokal (uten komplekse sporingsstrukturer) ved å kartlegge objekt-IDer til kjerner eller fliser og sende hver oppgave dit objekt-IDen er kartlagt.
De Chronos systemet ble implementert i AWS FPGA-rammeverket som et system med 16 fliser, hver med 4 applikasjonsspesifikke prosesseringselementer (PE), som kjører på 125MHz. Dette systemet sammenlignes med en baseline bestående av 20-kjerne/40-tråds 2.4 GHz Intel Xeon E5-2676v3, valgt spesifikt fordi prisen er sammenlignbar med FPGA-en (ca. $2/time). Chronos kjører én enkelt oppgave på én PE, og er 2.45 ganger raskere enn grunnlinjen. Etter hvert som antallet samtidige oppgaver øker, skaleres Chronos-implementeringen til en selvrelativ hastighet på 44.9x på 8 fliser, tilsvarende en 15.3x hastighetsøkning i forhold til CPU-implementeringen. De sammenlignet også en implementering basert på generell RISC-V i stedet for applikasjonsspesifikke PE-er; PE-er var 5 ganger raskere enn RISC-V.
Jeg syntes papiret var imponerende fordi det dekker alt fra et konsept til definisjonen av SLOT-utførelsesmodellen til implementeringen av maskinvare og den detaljerte sammenligningen med en tradisjonell Xeon CPU for 4 applikasjoner. Innsatsen er betydelig, Chronos er over 20,000 5.4 linjer med SystemVerilog. Resultatet er en 4x gjennomsnittlig hastighet (av de XNUMX applikasjonene) i forhold til programvareparallelle versjoner, på grunn av mer parallellitet og mer bruk av spekulativ utførelse. Oppgaven er også verdt å lese for bruk på ikke-simulerende oppgaver; papiret inneholder tre eksempler.
Del dette innlegget via:
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
- kilde: https://semiwiki.com/eda/326261-speculation-for-simulation-innovation-in-verification/