Speculation For Simulation. Innovation In Verification

Julkaissut Platon

seuraajia: 0

Tämä on mielenkiintoinen ajatus, jossa käytetään laitteistotuettua spekulatiivista rinnakkaisuutta simuloinnin nopeuttamiseen, ja kierre vaatii mukautettua laitteistoa. Paul Cunningham (Senior VP/GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, yrittäjä, entinen Synopsysin teknologiajohtaja ja nyt Silvacon teknologiajohtaja) ja minä jatkamme tutkimusideoiden sarjaamme. Kuten aina, palaute on tervetullutta.

Spekulaatiota simulaatioon

Innovaatio

Tämän kuukauden valinta on Chronos: Tehokas spekulatiivinen rinnakkaisuus kiihdyttimille. Kirjoittajat esittelivät artikkelin vuoden 2020 ohjelmointikielten ja käyttöjärjestelmien arkkitehtuurisen tuen konferenssissa ja ovat MIT:stä.

Rinnakkaisuuden hyödyntäminen moniytimisprosessoreilla on yksi vaihtoehto sovelluksille, joissa rinnakkaisuus on itsestään selvää. Muut algoritmit eivät ehkä ole niin helposti osioitavissa, mutta ne voivat hyötyä spekulatiivisesta suorituksesta, joka hyödyntää luontaista rinnakkaisuutta. Yleensä spekulatiivinen suoritus riippuu välimuistin koherenssista, joka on suuri lisäkustannus erityisesti simuloinnissa. Tämä menetelmä ohittaa koherenssin tarpeen ja paikantaa fyysisesti tehtävien suorittamisen laskeakseen laatat kohdeluku-kirjoitusobjektin mukaan. Näin varmistetaan, että ristiriitojen havaitseminen voidaan havaita paikallisesti ilman globaalia koherenssin hallintaa. Tehtävät voidaan suorittaa spekulatiivisesti rinnakkain; havaitut ristiriidat voidaan purkaa tehtävästä sen alitehtävien kautta ja suorittaa sitten uudelleen ilman, että muita säikeitä tarvitsee pysäyttää.

Tässä vielä yksi huomio. Tämä menetelmä tukee viivepohjaista simulointia, toisin kuin useimmat laitteistokiihdytystekniikat.

Paavalin näkemys

Vau, mikä upea korkeaoktaaninen paperi MIT:ltä! Kun minulta kysytään rinnakkaislaskennasta, ajattelen välittömästi säikeitä, mutexeja ja muistin koherenssia. Näin tietysti modernit moniytimiset prosessorit on suunniteltu. Mutta se ei ole ainoa tapa tukea rinnakkaisua laitteistossa.

Tässä artikkelissa ehdotetaan vaihtoehtoista arkkitehtuuria rinnakkaisuudelle nimeltä Chronos, joka perustuu järjestettyyn tehtäväjonoon. Suorituksen aikana tehtävät suoritetaan aikaleimajärjestyksessä ja jokainen tehtävä voi luoda uusia alitehtäviä, jotka lisätään dynaamisesti jonoon. Suoritus alkaa asettamalla joitakin alkutehtäviä jonoon ja päättyy, kun jonossa ei ole enää tehtäviä.

Jonossa olevat tehtävät viljellään useille prosessointielementeille (PE) rinnakkain – mikä tarkoittaa, että Chronos suorittaa spekulatiivisesti tulevia tehtäviä ennen kuin nykyinen tehtävä on valmis. Jos nykyinen tehtävä mitätöi spekulatiivisesti suoritetut tulevat tehtävät, näiden tulevien tehtävien toimet "perutaan" ja ne asetetaan uudelleen jonoon. Tämän konseptin oikea toteuttaminen laitteistossa ei ole helppoa, mutta ulkopuoliselle käyttäjälle se on kaunista: vain koodaat algoritmisi ikään kuin tehtäväjonoa suoritettaisiin sarjassa yhdellä PE:llä. Ei tarvitse koodata mutexeja tai huolehtia umpikujasta.

Kirjoittajat toteuttavat Chronosin SystemVerilogissa ja kääntävät sen FPGA:ksi. Suuri osa paperista on omistettu selittämään, kuinka he ovat toteuttaneet tehtäväjonon ja mahdollisen tarvittavan laitteiston purkamisen maksimaalisen tehokkuuden saavuttamiseksi. Chronos on benchmarkissa neljällä algoritmilla, jotka sopivat hyvin tehtäväjonopohjaiseen arkkitehtuuriin. Jokainen algoritmi toteutetaan kahdella tavalla: ensin käyttämällä omistettua algoritmikohtaista PE:tä ja toiseksi käyttämällä hyllyltä saatavaa avoimen lähdekoodin 32-bittistä sulautettua RISC-V-suoritinta PE:nä. Chronosin suorituskykyä verrataan sitten Intel Xeon -palvelimella toimivien algoritmien monisäikeisiin ohjelmistototeutuksiin, joilla on samanlainen hintalappu kuin Chronosissa käytettävällä FPGA:lla. Tulokset ovat vaikuttavia – Chronos skaalautuu 3 kertaa 15 kertaa paremmin kuin Xeon-palvelimen käyttäminen. Taulukon 3 ja kuvion 14 vertailu saa minut kuitenkin hieman huolestumaan siitä, että suurin osa näistä eduista tuli algoritmikohtaisista PE:istä eikä itse Chronos-arkkitehtuurista.

Koska tämä on vahvistusblogi, lähensin luonnollisesti porttitason simulaation vertailuarvoa. EDA-teollisuus on investoinut voimakkaasti yrittääkseen rinnastaa logiikan simulaation, ja on osoittautunut vaikeaksi nähdä suuria voittoja muutamien erityisten käyttötapausten lisäksi. Tämä johtuu pääasiassa siitä, että useimpien tosimaailman simulaatioiden suorituskykyä hallitsevat lataus/tallennusohjeet, jotka puuttuvat L3-välimuistista ja siirtyvät DRAM-muistiin. Tässä artikkelissa on vain yksi testitapaus, joka on benchmark ja se on pieni 32-bittinen siirtosaannin. Jos luet tätä blogia ja olet kiinnostunut tekemään perusteellisempaa vertailua, kerro minulle – jos Chronos pystyy todella skaalautumaan hyvin tosimaailman simulaatioissa, sillä olisi valtava kaupallinen arvo!

Raúlin näkemys

Tämän paperin tärkein panos on Tilallisesti sijoitettu järjestetyt tehtävät (SLOT) -suoritusmalli joka on tehokas laitteistokiihdyttimille, jotka hyödyntävät rinnakkaisuutta ja spekulaatiota, sekä sovelluksille, jotka luovat tehtäviä dynaamisesti ajon aikana. Dynaamisen rinnakkaisuuden tuki on väistämätöntä simuloinnissa, ja spekulatiivinen synkronointi on houkutteleva vaihtoehto, mutta koherenssi on liian korkea.

SLOT välttää johdonmukaisuuden tarpeen rajoittamalla jokaisen tehtävän toimimaan (kirjoittamaan) yhdelle objektille ja tukee järjestettyjä tehtäviä mahdollistaakseen usean kohteen atomisuuden. SLOT-sovellukset ovat järjestettyjä, dynaamisesti luotuja tehtäviä, joille on ominaista aikaleima ja objektitunnus. Aikaleimat määrittelevät tilausrajoitukset; objektitunnukset määrittelevät datariippuvuudet, eli tehtävät ovat tiedoista riippuvaisia, jos ja vain jos niillä on sama objektitunnus. (jos on lukuriippuvuus, tehtävä voidaan suorittaa spekulatiivisesti). Ristiriitojen havaitsemisesta tulee paikallinen (ilman monimutkaisia seurantarakenteita) yhdistämällä objektien tunnukset ytimiin tai ruutuihin ja lähettämällä jokainen tehtävä sinne, missä sen objektitunnus on kartoitettu.

- Chronos järjestelmä toteutettiin AWS FPGA -kehyksessä järjestelmänä, jossa on 16 ruutua, joista jokaisessa on 4 sovelluskohtaista käsittelyelementtiä (PE), jotka toimivat 125 MHz:llä. Tätä järjestelmää verrataan 20-ytimen/40-säikeisen 2.4 GHz Intel Xeon E5-2676v3:n perusjärjestelmään, joka on valittu nimenomaan, koska sen hinta on verrattavissa FPGA-järjestelmään (noin 2 dollaria/tunti). Chronos on 2.45 kertaa nopeampi kuin perusviiva, kun se suorittaa yhden tehtävän yhdellä PE:llä. Kun samanaikaisten tehtävien määrä kasvaa, Chronos-toteutus skaalautuu 44.9-kertaiseen itsesuhteelliseen nopeuteen 8 ruudulla, mikä vastaa 15.3-kertaista nopeutta CPU-toteutukseen verrattuna. He myös vertasivat yleiskäyttöiseen RISC-V:hen perustuvaa toteutusta sovelluskohtaisten PE:iden sijaan; PE:t olivat viisi kertaa nopeampia kuin RISC-V.

Minusta artikkeli oli vaikuttava, koska se kattaa kaiken konseptista SLOT-suoritusmallin määrittelyyn laitteiston toteuttamiseen ja yksityiskohtaiseen vertailuun perinteiseen Xeon-suorittimeen 4 sovellukselle. Työ on huomattavaa, Chronosilla on yli 20,000 5.4 SystemVerilog-riviä. Tuloksena on 4-kertainen keskimääräinen nopeus (neljästä sovelluksesta) verrattuna ohjelmiston rinnakkaisiin versioihin, mikä johtuu suuremmasta rinnakkaisuudesta ja spekulatiivisen suorituskyvyn lisääntymisestä. Paperi on myös lukemisen arvoinen, jotta sitä voidaan soveltaa ei-simulointitehtäviin; paperi sisältää kolme esimerkkiä.

Jaa tämä viesti: