Xler8

Speculazione per la simulazione. Innovazione nella verifica

Questa è un'idea interessante, che utilizza il parallelismo speculativo supportato dall'hardware per accelerare la simulazione, con una svolta che richiede hardware personalizzato. Paul Cunningham (Senior VP/GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, imprenditore, ex Synopsys CTO e ora Silvaco CTO) e io continuiamo la nostra serie sulle idee di ricerca. Come sempre, feedback ben accetti.

Speculazione per la simulazione

L'innovazione

La scelta di questo mese è Chronos: parallelismo speculativo efficiente per gli acceleratori. Gli autori hanno presentato il documento alla Conferenza 2020 sul supporto architettonico per linguaggi di programmazione e sistemi operativi e provengono dal MIT.

Lo sfruttamento del parallelismo utilizzando processori multicore è un'opzione per le applicazioni in cui il parallelismo è evidente. Altri algoritmi potrebbero non essere così facilmente partizionati ma potrebbero trarre vantaggio dall'esecuzione speculativa sfruttando il parallelismo intrinseco. Di solito, l'esecuzione speculativa dipende dalla coerenza della cache, un sovraccarico elevato soprattutto per la simulazione. Questo metodo ignora la necessità di coerenza, localizzando fisicamente l'esecuzione dell'attività per calcolare i riquadri in base all'oggetto di lettura-scrittura di destinazione, assicurando che il rilevamento dei conflitti possa essere rilevato localmente, senza la necessità di una gestione della coerenza globale. Le attività possono essere eseguite speculativamente in parallelo; qualsiasi conflitto rilevato può essere srotolato da un'attività tramite le sue attività figlio, quindi rieseguito senza la necessità di bloccare altri thread.

Un altro punto di nota qui. Questo metodo supporta la simulazione basata sul ritardo, a differenza della maggior parte delle tecniche di accelerazione hardware.

Il punto di vista di Paolo

Wow, che meravigliosa carta ad alto numero di ottani del MIT! Quando mi viene chiesto del calcolo parallelo, penso immediatamente a thread, mutex e coerenza della memoria. Questo è ovviamente il modo in cui sono progettate le moderne CPU multi-core. Ma non è l'unico modo per supportare la parallelizzazione nell'hardware.

Questo documento propone un'architettura alternativa per la parallelizzazione chiamata Chronos che si basa su una coda ordinata di attività. In fase di esecuzione, le attività vengono eseguite in ordine di timestamp e ogni attività può creare nuove attività secondarie che vengono aggiunte dinamicamente alla coda. L'esecuzione inizia mettendo in coda alcune attività iniziali e termina quando non ci sono più attività in coda.

Le attività in coda vengono assegnate a più elementi di elaborazione (PE) in parallelo, il che significa che Chronos sta eseguendo speculativamente attività future prima che l'attività corrente sia stata completata. Se l'attività corrente invalida eventuali attività future eseguite speculativamente, le azioni di tali attività future vengono "annullate" e vengono rimesse in coda. Implementare correttamente questo concetto nell'hardware non è facile, ma per l'utente esterno è bello: devi solo codificare il tuo algoritmo come se la coda delle attività fosse eseguita in serie su un singolo PE. Non è necessario codificare alcun mutex o preoccuparsi del deadlock.

Gli autori implementano Chronos in SystemVerilog e lo compilano in un FPGA. Gran parte del documento è dedicato a spiegare come hanno implementato la coda delle attività e qualsiasi srotolamento necessario nell'hardware per la massima efficienza. Chronos è confrontato su quattro algoritmi adatti a un'architettura basata su code di attività. Ogni algoritmo viene implementato in due modi: in primo luogo utilizzando un PE specifico dell'algoritmo dedicato e in secondo luogo utilizzando una CPU RISC-V embedded open source standard a 32 bit come PE. Le prestazioni di Chronos vengono quindi confrontate con le implementazioni software multi-thread degli algoritmi in esecuzione su un server Intel Xeon con un prezzo simile all'FPGA utilizzato per Chronos. I risultati sono impressionanti: Chronos scala da 3 a 15 volte meglio rispetto all'utilizzo del server Xeon. Tuttavia, il confronto tra la Tabella 3 e la Figura 14 mi fa un po' preoccupare che la maggior parte di questi guadagni provenga dai PE specifici dell'algoritmo piuttosto che dall'architettura Chronos stessa.

Dato che questo è un blog di verifica, ho naturalmente ingrandito il benchmark di simulazione a livello di gate. Il settore EDA ha investito molto per provare a parallelizzare la simulazione logica e si è rivelato difficile vedere grandi guadagni al di là di alcuni casi d'uso specifici. Ciò è dovuto principalmente al fatto che le prestazioni della maggior parte delle simulazioni del mondo reale sono dominate da istruzioni di caricamento/archiviazione mancanti nella cache L3 e in uscita nella DRAM. C'è solo un caso di test valutato in questo documento ed è un piccolo sommatore di salvataggio del trasporto a 32 bit. Se stai leggendo questo blog e sei interessato a fare un benchmarking più approfondito, fammelo sapere: se Chronos può davvero scalare bene sulle simulazioni del mondo reale, avrebbe un enorme valore commerciale!

Il punto di vista di Raull

Il contributo principale di questo lavoro è il Modello di esecuzione SLOT (Spatially Location Ordered Tasks). che è efficiente per gli acceleratori hardware che sfruttano il parallelismo e la speculazione e per le applicazioni che generano attività dinamicamente in fase di esecuzione. Il supporto del parallelismo dinamico è inevitabile per la simulazione e la sincronizzazione speculativa è un'opzione allettante, ma il sovraccarico di coerenza è troppo elevato.

SLOT evita la necessità di coerenza limitando ogni attività a operare (scrivere) su un singolo oggetto e supporta attività ordinate per abilitare l'atomicità multi-oggetto. Le applicazioni SLOT sono attività ordinate e create dinamicamente caratterizzate da un timestamp e un oggetto id. I timestamp specificano i vincoli dell'ordine; gli ID oggetto specificano le dipendenze dei dati, ovvero le attività dipendono dai dati se e solo se hanno lo stesso ID oggetto. (se esiste una dipendenza di lettura, l'attività può essere eseguita in modo speculativo). Il rilevamento dei conflitti diventa locale (senza strutture di tracciamento complesse) mappando gli ID oggetto ai core o ai riquadri e inviando ogni attività al punto in cui è mappato il relativo ID oggetto.

I Chronos Il sistema è stato implementato nel framework AWS FPGA come un sistema con 16 riquadri, ciascuno con 4 elementi di elaborazione specifici dell'applicazione (PE), in esecuzione a 125 MHz. Questo sistema viene confrontato con una linea di base composta da Intel Xeon E20-40v2.4 a 5 core/2676 thread a 3 GHz, scelto appositamente perché il suo prezzo è paragonabile a quello dell'FPGA (circa $ 2/ora). Eseguendo una singola attività su un PE, Chronos è 2.45 volte più veloce rispetto alla linea di base. All'aumentare del numero di attività simultanee, l'implementazione di Chronos scala fino a un aumento di velocità relativo di 44.9 volte su 8 riquadri, corrispondente a un aumento di velocità di 15.3 volte rispetto all'implementazione della CPU. Hanno anche confrontato un'implementazione basata su RISC-V per scopi generici piuttosto che PE specifici per l'applicazione; I PE erano 5 volte più veloci di RISC-V.

Ho trovato il documento impressionante perché copre tutto, da un concetto alla definizione del modello di esecuzione SLOT all'implementazione dell'hardware e al confronto dettagliato con una CPU Xeon tradizionale per 4 applicazioni. Lo sforzo è notevole, Chronos supera le 20,000 righe di SystemVerilog. Il risultato è una velocità media di 5.4 volte (delle 4 applicazioni) rispetto alle versioni software parallele, a causa di un maggiore parallelismo e di un maggiore utilizzo dell'esecuzione speculativa. Vale la pena leggere il documento anche per l'applicazione a compiti non di simulazione; il documento include tre esempi.

Condividi questo post tramite:

Parla con noi

Ciao! Come posso aiutarla?