Evoluzione dei Sistemi Embedded: Verso architetture multi-core

Evoluzione dei Sistemi Embedded:Verso architetture multi-core

PhD Patrick Bellasi

CEFRIELPolitecnico di Milano

[email protected]://home.dei.polimi.it/bellasi

©copyright CEFRIEL 2012| All rights reserved | Milano, Italy 2

Multi-Core in Ambito EmbeddedA che punto siamo?

Soluzioni multi-core si stanno affermando sempre piùprospettiva di maggiori prestazioni grazie al parallelismo

La scelta di una archiettura è fondamentaleinfluenza direttamente le prestazioni del sistema

oltre che la sue funzionalità, e.g. componenti, I/O, consumi energetici...

Esistono diverse sfumature possibiliMulti-core asimmetrici

ogni core esegue indipendentementeinterazione di applicationi real-time e non

Multi-core simmetricomultipli threads gestiti da un singolo SO che alloca le risorse condivise

Virtualizzazioneun “ipervisore” isola ed alloca le risorse a diversi run-timeconsente l'integrazione di real-time, general purpose e software legacy


Multi-Core in Ambito EmbeddedCosa Sono i Multi-Cores Asimmetrici (AMP)?

Gestione “manuale” delle risorse condivise

Ogni core ha un suo OSogni core esegue indipendentementeintegrazione di applicazioni legacymix Real-Time e General-purposecomunicazione IPC fra cores

SvantaggiTime-to-market

Impattato dalla gestione delle risorse condivise che aumenta la complessità del codice

Scalabilitàlimitata dall'aumento di complessità

Prestazioniprobabile sotto-utilizzazione dei coreintense comunicazioni fra cores


Multi-Core in Ambito EmbeddedCosa Sono i Multi-Cores Simmetrici (SMP)?

Unico OS che gestisce tutti i coresScalabilità

è possibile migliorare le prestazioni “semplicemente” aumentando i cores

PrestazioniIl bilanciamento del carico consente di sfruttare al massimo i cores

semplici privitive di gestione dei threads

Time-to-marketgestione delle risorse condivise a carico dell'OSconseguente riduzione di complessità

sia di design che di codice

Svantaggile applicazioni debbono essere scritte “bene” per sfruttare il parallelismo

Le risorse condivise vengono gestite in modo trasparente dal Sistema Operativo


Multi-Core in Ambito EmbeddedLightway vs Full-Virtualization

A volte serve sia AMP che SMPcoesistenza di OS diversi

e.g. RTOS e General-Purpose OSparallelizzaione spinta delle applicazioni

La virtualizzzazion garantisce la flessibilità dell'SMP e il controllo dell'AMP

Lightway virtualizationsfrutta servizi dell'OS per creare “containers”

isolamento applicazioni, assegnamento risorse

Full virtualizationrichiede un monitor hardwaresupporta molteplici OS indipendenti

ciascuno vede solo parte delle risorse

Le risorse condivise vengono partizionate (dinamicamente) fra le diverse

applicazioni


Multi-Core in Ambito EmbeddedQuali Solozioni Vanno per la Maggiore?

Molte piattaforme embedded attuali sono basate su architetture multi-core asimmetriche

diversi processori integrati all'interno dello stesso chip, o sistema

L'avvento dei System-on-Chip (SoC) ha favorito questo tipo di soluzioni

Architetture specializzate vengono impiegate per supportare funzionalità specifiche

elaborazione di dati multimediali (Audio/Video DSP)accellerazione e rendering grafico (GPU)


Multi-Core in Ambito EmbeddedDentro un OMAP5 (Texas Instuments)

Samsung Galaxy S3


Multi-Core in Ambito EmbeddedAbbiamo Davvvero Bisogno di Tante Prestazioni?

La disponibilità di architetture parallele consente lo sviluppo di nuove classi di applicazioni

Le elaborazione multimediali in generale possono beneficiare di queste nuove architetture

grandi quantità di dati da processare (e.g. video in FullHD)stringenti vincoli temporali (e.g. elevati framerates)

I dispositivi portatili sono sempre più poli-funzionali

Nuove classi di applicazioni stanno emergendocome richieste di mercato


Multi-Core in Ambito EmbeddedQuali Nuove Applicazioni Possiamo Aspettarci?

Diffusione della Computer Vision BusinnessIntelligence

Controllodi Accessi

Monitorazzio& Sicurezza

Assistenza allaguida


Multi-Core in Ambito EmbeddedQuali Caratteristiche Hanno Queste Applicazioni?

Esempio: Scalable Video Coding (SVC)singolo stream video in ingressodiverse possibili configurazioni di decodifica

Framerate

Qualità

Risoluzione

A diversi profili di decodifica corrispondono diversirapporti qualità vs prestazioni richieste



Diverse fasi di elaborazioneciascuna con diverso grado di parallelismo e requisiti di risore computazionalisi prestano ad essere eseguite in concorrenza fra loro

Si prestano ed essere programmate seguendo “nuovi” paradigmi di programmazione

Stream-Processing


Multi-Core in Ambito EmbeddedQuali Scenari Computazionali?

Sistemi multi-coremolteplici unità di elaborazionesia simmetriche che asimmetriche

Applicazioni complessesignificativi carichi computazionalivariabilità dei requisiti in termini di risorse

anche a run-time, i.e. cambiano durante l'esecuzione

composte da sequenze di attività parallelizzabili

Sistemi polifunzionalidiversi carichi di lavoro (mixed workload)diversi requisiti funzionali...

e.g. tempistiche, qualità

… che possono anche modificarsi a run-time


Evoluzioni Architetturali

Tanti grossi: bene... molti piccoli: meglio!


ComputationFabric

Multi-CoreComputation

Cluster

Evoluzioni Architetturali FutureCome si Presentano Queste Nuove Architetture?

Da HW ad-hoc ad HW genericoAccelleratori Specializzati

Accelleratore Programmabile


Evoluzioni Architetturali FutureCome Possiamo Sfruttarle?

Esempio: Software Defined Radio (SDR)

Approccio“classico”

Approccio“ri-programmabile”


Evoluzioni Architetturali FutureChe Sfide Si Presentano a Livello Software?

Sviluppo di codice parallelizzato

Programmazione a componenti riutilizzabilimoduli SW autonomi e parallelizzabili (filters)con interfaccie ben definite e quindi componibili (pipeline)

Nuovi paradigmi di programmazionea supporto dello sviluppo di SW parallelizzatoin grado di astrarre dallo specifico target

“write one run anywhere”

Ambienti di sviluppodescrizione ad alto livello delle applicazionisimulazione ed ottimizazione per lo specifico targetsuppporto a diversi modelli di programmazione parallela


Evoluzioni Architetturali FutureQuali Paradigmi di Programmazione? (1/3)

Proprietari e/o per specifiche piattaforme

Fractaldefinito da OW2 Consortiummiddleware modulare ed estensibileagnostico al linguaggio (e.g. C, Java, .NET)

Native Programming Modelsviluppato da STMicroelectronicscollezione di primitive di

decomposizione-composizione

Thread Building Blocks (TBB)proposta di Intelprincipalment orientata ad HPC

supporta solo su x86

http://fractal.ow2.org

http://threadingbuildingblocks.org



OpenCL: “lo” standard Industriale



standard aperto per la programmazione parallela

di sistemi eterogenei

OpenCL in pillolelinguaggio (C99-based) per scrivere kernels

i.e. “funzioni” da eseguire su un device OpenCL

parallelismo a livello di dati e taskAPI per controllar la piattaforma

architettura “astratta” di riferimento

http://www.khronos.org/opencl

configura lapiattaforma

Copia datida elaborare

Esecuzione parallelasu più cores

Copia deirisultati


Conclusioni (1/2)Come si Possono Sfruttare i Many-Cores?

Con lo stesso principio dei LEGO

“raccogliere, mettere insieme”

dal Danese “leg godt” = “giocare bene”


Conclusioni (2/2)Un Data-Server in Tasca

L'embedded va verso architetture many-coremolte unità di calcolo, “sostanzialmente” similiapplicazioni complesse, decomposte in moduli parallelizzabili

Le funzionalità di un dispositivo sono polimorfichedipendono da come lo si programmapossono cambiare a run-time

adattandosi quindi agli scenario d'uso

Tutto ciò è molto simile a quelloche già avviene in ambito HPC

Barcelona Supercomputing Centre

10.240 processors

Tilera Tile-Gx100100 cores indipendenti

Barcelona Supercomputing Centre

cambia solo il “fattore si scala”

stessi beneficima “portabili”


Grazie per l'attenzione


Backup Slides


Evoluzione Tecnologica

L'hardware cambia faccia... ed il software si deve adattare!


Evoluzione tecnologicaPerchè si è arrivati ai multi-core?

Costruire processori più complessi non era difficilePentium4: il processore più complesso mai costriutoTuttavia è puntualmente uscito come prodotto sul mercato

L'aumento del numero di transistors consente di fornire più funzionalità

Perchè non si sono sviluppati processori più sofisticati?

Proprio il caso del Pentium4 ci può dare qualche indicazione...


Evoluzione tecnologicaPentium4: Super-Pipelined, Super-Scalar

Pipeline a 20 stadi, branch-prediction e recovery 5 operazioni per ciclo di clock 1 load, 1 store unit ALU per interi

2 semplici/veloci1 complessa/veloce

1PF exe, 1FP move unit

Fino a126 istruzioni “in flight”

48 loads, 24 stores




Il parallelismo a livello di istruzione disponibile nei programmi ha un limite intrinseco

specialmente nel caso di codice in cui è difficile prevedere correttamente i “salati”

E' nata la necessità di seguire un nuovo approccio

sfruttare al meglio le risorse computazionali per supporotare il parallelismo a livello di threads



Due “diverse” possibili strategie

A) Più “threads” all'interno dello stesso coreD. Tullsen, S. Eggers, H. Levy, “Simultaneous multithreading: maximizing on-chip parallelism”, ISCA, 1995

B) Più “cores” all'interno dello stesso chipK. Olukotun, B. Nayfeh, L. Hammond, K. Wilson, K. Chang, “The case for a single-chip multiprocessor”, ASPLOS-VII, 1996



IBM Power4 – Dicembre 2001180nm, Dual-Core8-way super-scalar>200 istruzioni “in flight”

IBM Power5 – Agosto 2003130nm, Dual-Core + SMT8-way super-scalar24% area in più rispetto al Power4



Intel fa “outing”dichiara pubblicamente di avere raggiunto un “thermal wall”

“Intel's decision to change course and embrace a ''dual core'' processor structure shows the challenge of overcoming the effects of heat generated by the constant on-off movement of tiny switches in modern computers … some analysts and former Intel designers said that Intel was coming to terms with escalating heat problems so severe they threatened to cause its chips to fracture at extreme temperatures…”

New York Times, 17 Maggio 2004



Nel frattempo anche il competitor AMD si muovevauna dimostrazione dell'Opteron, la prima CPU x86 dual core, era già pronta ed in programma da li a pochi giorni

“The shift to multiple processing units, or cores, embedded in the same chip has recently become a significant technological approach for I.B.M., Sun Microsystems and Intel as well as Advanced Micro, as computer designers hunt for new ways to increase processing power...”

New York Times, 31 Agosto 2004



Sun Microsystems adotta la stessa strategia per la sua linea di processori dedicati ai server

L'Ultrasparc T1 (Niagara) spinge il concetto di multi-core

“The UltraSparc T1, following a trend in the semiconductor industry, adds new features that conserve energy significantly… The UltraSparc T1 has eight processing cores, each able to execute four instruction sequences, called threads...”

New York Times, 15 Novembre 2005




Il parallelismo a livello di istruzione disponibile nei programmi ha un limite intrinseco

specialmente nel caso di codice in cui è difficile prevedere correttamente i “salati”

Aumentare le prestazioni di un singolo processore rispettando un certo budget energetico rappresenta un altro fattore vincolante



I produttori iniziano ad aumentare il numero di “core”per sfruttare lo spazio ed i transistor a disposizionefornendo così un supporto hardware all'esecuzione concorrente di multi threads

Questa soluzione ha generato un altro problemai programmatori devo capire come sfruttare al meglio le potenzialità di queste nuove architetture

Si tratta di un “problema”...

…o piuttosto di un'opportunità?


Archietetture multi-coreDentro un MacBook Pro

Images courtesy of


Archietetture multi-coreAmbito Avionico


Archietetture multi-coreAmbito Avionico

Rete di processoristandard di interconnessioneprocessori simmetrici

Supporto OS avanzatopartizionamento mandatorio di tempo e risorse


Multi-Core in Ambito Embedded

Ci stanno già andando... non perdiamo la corsa!


Multi-Core in Ambito EmbeddedChe Vantaggi Offre?

Non solo miglioramento delle prestazioni...… diverse ottimizzazioni progettuali

riduzione di componenti e TCOe.g. disponibilità di GPU integrate con processori general-purpose

=> no display processor esterno, migliori prestazioni

integrazione di più funzionalitàe.g. sfruttando alcuni cores interni per funzionalità specifiche

=> eliminazione di DPS o FPGA esterni

riduzione di “form-factor” e dei consumi=> riduzione o eliminazione di dissipatori

=> in ambito mobile: batterie e packaging più piccoli


Multi-Core in Ambito EmbeddedDentro un U9500 (ST-Ericsson)

Nokia Lumia 800


Multi-Core in Ambito EmbeddedDalle Board ai SoC... fino a PSoC ed FPGA


Multi-Core in Ambito EmbeddedQuali Nuove Applicazioni Possiamo Aspettarci?

Nuove forme di interazione “uomo-macchina”

Google Glass Project

Augmented Reality



Esempio: Scalable Video Coding (SVC)Elevata complessità computazionale...… ma anche elevato livello di parallelismo

Tuttavia spesso questi sono solo alcuni passidi applicazioni complete...


far-lotti in-lotto

fra-chip in-chip

22nm 4nm

Evoluzioni Architetturali FutureQuali Sono le Prossime Sfide?

Fattori Tecnologici e Produttivii “transistor” di nuova generazione hannodimensioni in scala “atomica”

le variazioni in fase di produzionedivengono sempre più significative

non è più possibile differenziare i prodottiin funzione del lotto di produzione

differenze di misurano addiritturaall'interno del singolo chip

Imoatto su prestazioni e consumi energetici

Richiesta di maggiore flessibilità...


[Ramacher09]

Esempio: produzionedi dispositivi multistandard

Evoluzioni Architetturali FutureCome Supportare La Flessibiltià?

Progettare e produrre HW custom è costosooltre certi livelli di integrazione non è più conveniente

Spinta verso “architetture programmabili”

VantaggiManutenibilità post-produzioneSupporto per applicazioni diverse

sia presenti che future

Riduzione di costi e tempi di produzione

da SW ad-hoc su HW ad-hoc...… a SW ad-hoc su HW generico


Evoluzioni Architetturali FutureCome si Confrontano Con le Soluzioni Attuali?

Rappresentano una nuova classe di dispositivi

Architettureprogrammabili

Gops/mm^2 @ 32nm


Evoluzioni Architetturali FutureChe Sfide Si Presentano a Sistema Operativo?

Gestione Dinamica delle Risorse

Identificare un compromesso ottimale fraesigenze prestazionali (QoS) delle applicazioni e

disponibilità delle risorse

Risorse HW condivise, diverse classi di applicazionisofisticati dispositivi many-core di nuova generazionevariabilità di processo ed a run-timerisorse condivise fra applicazioni in competizione

Necessità di efficaci ma semplici supporti SWin grado di adattarsi a diversi modi d'uso, a run-timeadeguati al supporto di applicazioni sia best-effort che critiche


Evoluzioni Architetturali FutureChe Supporto Ci Si Aspetta dalla GDR?

Astrazione dalle risorseAssegnare opportunamente le risorse

al fine di ottimizzare l'uso della piattaforma

Considerando fenomeni divariazione di processohot-spots e rotturevariazioni del carico

Possibili strategia?1. assegnamento di “risorse virtuali”2. mapping su risorse fisiche a run-time

gestendo opportunamente i fenomeni di variabilità

Assistenza allaguida

Workloads Critici

Google Glass Project

Workloads Best-Effort

Run-Time ResourcesManager

Richiesta Risorse

Assegnazione Risorse


Aspetti Industriali

Come affrontare la sfida... supportando gli standard industriali!


Aspetti IndustrialiQuali Iniziative Esistono?

Multicore Associationassociazioni di industrie interessate allatecnologia multi-core

partner industriali ed accademici

Roadmaphttp://www.multicore-association.org/

Definizione di APIscomunicazionegestione delle risorsescheduling dei taskmonitoraggio e debugging

Funzionalità avanzatabilanciamento di caricogestione ed ottimizzazione

di QoS e potenzaaffidabilità


Aspetti IndustrialiQuali API Sono Già Disponibili?

MCAPI: supporto a comunicazione e sincronizzazionebasata su scambio di messaggiper sistemi embedded “distribuiti”

sia in- che off-chip

Insieme di chiamate minimalesufficienti a coprire le principali esegenzesemplici per supportare implementazioni efficienti

Orientatoall'embeddedsoluzioni alternative puntanopiu all'HPC

v2.0 in lavorazioneshared memory,zero copy message, …

Alternative proprietariee.g. RingIO by TI (con supporto Linux mainline)


Aspetti IndustrialiQuali API Sono Già Disponibili?

MRAPI: suppporto a gestione delle risorsecoordinamento dell'accesso concorrentesia in ambito SMP che AMP

Diverse classi di risorse gestibiliunità di elaborazione, sia omogenee che nonaccelleratori HWregioni di memoriaperiferiche di I/O

Monitoraggio risorsesia statico che dinamico

Meccanismi di notificastati delle risose (e.g. consumi)errori e faultscambiamenti di disponibilità

Codeplay Software, Freescale, IBM, IMEC, LSI Corporation, Mentor Graphics, PolyCore Software,

Samsung, Texas Instruments, Tilera


Tutto cambia... per rimanere simile!

Conclusioni

Evoluzione dei Sistemi Embedded: Verso architetture multi-core

Technology

Transcript of Evoluzione dei Sistemi Embedded: Verso architetture multi-core