Evoluzione dei Sistemi Embedded: Verso architetture multi-core

Evoluzione dei Sistemi Embedded:
Verso architetture multi-core
PhD Patrick Bellasi

CEFRIEL
Politecnico di Milano
bellasi@elet.polimi.it
http://home.dei.polimi.it/bellasi

Multi-Core in Ambito Embedded
A che punto siamo?

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


La scelta di una archiettura è fondamentale
influenza direttamente le prestazioni del sistema
oltre che la sue funzionalità, e.g. componenti, I/O, consumi energetici...


Esistono diverse sfumature possibili
Multi-core asimmetrici
ogni core esegue indipendentemente
interazione di applicationi real-time e non
Multi-core simmetrico
multipli threads gestiti da un singolo SO che alloca le risorse condivise
Virtualizzazione
un “ipervisore” isola ed alloca le risorse a diversi run-time
consente l'integrazione di real-time, general purpose e software legacy

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

Cosa Sono i Multi-Cores Asimmetrici (AMP)?


Ogni core ha un suo OS
ogni core esegue indipendentemente
integrazione di applicazioni legacy
mix Real-Time e General-purpose
comunicazione IPC fra cores


Svantaggi
Time-to-market
Impattato dalla gestione delle risorse condivise
che aumenta la complessità del codice
Scalabilità Gestione “manuale”
limitata dall'aumento di complessità delle risorse condivise

Prestazioni
probabile sotto-utilizzazione dei core
intense comunicazioni fra cores


Cosa Sono i Multi-Cores Simmetrici (SMP)?


Unico OS che gestisce tutti i cores
Scalabilità
è possibile migliorare le prestazioni
“semplicemente” aumentando i cores
Prestazioni
Il bilanciamento del carico consente di sfruttare
al massimo i cores
semplici privitive di gestione dei threads
Time-to-market
gestione delle risorse condivise a carico dell'OS
conseguente riduzione di complessità
Le risorse condivise vengono gestite in
sia di design che di codice modo trasparente dal Sistema Operativo

Svantaggi
le applicazioni debbono essere scritte
“bene” per sfruttare il parallelismo


Lightway vs Full-Virtualization


A volte serve sia AMP che SMP
coesistenza di OS diversi
e.g. RTOS e General-Purpose OS
parallelizzaione spinta delle applicazioni

La virtualizzzazion garantisce la flessibilità
dell'SMP e il controllo dell'AMP

Lightway virtualization
sfrutta servizi dell'OS per creare “containers”
isolamento applicazioni, assegnamento risorse

Full virtualization
Le risorse condivise vengono partizionate
richiede un monitor hardware (dinamicamente) fra le diverse
supporta molteplici OS indipendenti applicazioni
ciascuno vede solo parte delle risorse


Quali 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)


Dentro un OMAP5 (Texas Instuments)

Samsung Galaxy S3


Abbiamo 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 emergendo
come richieste di mercato


Quali Nuove Applicazioni Possiamo Aspettarci ?


Diffusione della Computer Vision Businness
Intelligence

Assistenza alla
guida

Monitorazzio Controllo
& Sicurezza di Accessi


Quali Caratteristiche Hanno Queste Applicazioni?

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

Framerate

Risoluzione

Qualità

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




Diverse fasi di elaborazione
ciascuna con diverso grado di
parallelismo e requisiti di risore
computazionali
si prestano ad essere eseguite in
concorrenza fra loro

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

Stream-Processing


Quali Scenari Computazionali?


Sistemi multi-core
molteplici unità di elaborazione
sia simmetriche che asimmetriche


Applicazioni complesse
significativi carichi computazionali
variabilità dei requisiti in termini di risorse
anche a run-time, i.e. cambiano durante l'esecuzione
composte da sequenze di attività parallelizzabili


Sistemi polifunzionali
diversi 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!


Evoluzioni Architetturali Future
Come si Presentano Queste Nuove Architetture?


Da HW ad-hoc ad HW generico Accelleratore Programmabile

Accelleratori Specializzati

Computation
Fabric

Multi-Core
Computation
Cluster


Come Possiamo Sfruttarle?


Esempio: Software Defined Radio (SDR)
Approccio
“ri-programmabile”

Approccio
“classico”


Che Sfide Si Presentano a Livello Software?


Sviluppo di codice parallelizzato

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


Nuovi paradigmi di programmazione
a supporto dello sviluppo di SW parallelizzato
in grado di astrarre dallo specifico target
“write one run anywhere”


Ambienti di sviluppo
descrizione ad alto livello delle applicazioni
simulazione ed ottimizazione per lo specifico target
suppporto a diversi modelli di programmazione parallela

Quali Paradigmi di Programmazione? (1/3)


Proprietari e/o per specifiche piattaforme
Fractal
definito da OW2 Consortium
middleware modulare ed estensibile
agnostico al linguaggio (e.g. C, Java, .NET) http://fractal.ow2.org

Native Programming Model
sviluppato da STMicroelectronics
collezione di primitive di
decomposizione-composizione

Thread Building Blocks (TBB)
proposta di Intel
principalment orientata ad HPC
supporta solo su x86
http://threadingbuildingblocks.org




OpenCL: “lo” standard Industriale



standard aperto per la
programmazione parallela
di sistemi eterogenei
http://www.khronos.org/opencl

OpenCL in pillole
linguaggio (C99-based) per scrivere kernels
i.e. “funzioni” da eseguire su un device OpenCL
Copia dati
parallelismo a livello di dati e task da elaborare configura la
piattaforma

API per controllar la piattaforma Copia dei
risultati
architettura “astratta” di riferimento Esecuzione parallela
su più cores


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-core
molte unità di calcolo, “sostanzialmente” simili
applicazioni complesse, decomposte in moduli parallelizzabili

Le funzionalità di un dispositivo sono polimorfiche
dipendono da come lo si programma Barcelona Supercomputing Centre

possono cambiare a run-time
adattandosi quindi agli scenario d'uso

Tutto ciò è molto simile a quello
che già avviene in ambito HPC
10.240 processors

cambia solo il
“fattore si scala”
stessi benefici
ma “portabili”
Tilera Tile-Gx100
100 cores indipendenti


Grazie per l'attenzione


Backup Slides


Evoluzione Tecnologica

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


Evoluzione tecnologica
Perchè si è arrivati ai multi-core?


Costruire processori più complessi non era difficile
Pentium4: il processore più complesso mai costriuto
Tuttavia è 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...


Pentium4: 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/veloci
1 complessa/veloce

1PF exe, 1FP move unit

Fino a
126 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 core
D. Tullsen, S. Eggers, H. Levy, “Simultaneous multithreading:
maximizing on-chip parallelism”, ISCA, 1995
B) Più “cores” all'interno dello stesso chip
K. Olukotun, B. Nayfeh, L. Hammond, K. Wilson, K. Chang, “The case for
a single-chip multiprocessor”, ASPLOS-VII, 1996




IBM Power4 – Dicembre 2001
180nm, Dual-Core
8-way super-scalar
>200 istruzioni “in flight”


IBM Power5 – Agosto 2003
130nm, Dual-Core + SMT
8-way super-scalar
24% 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 muoveva
una 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 disposizione
fornendo così un supporto hardware all'esecuzione
concorrente di multi threads


Questa soluzione ha generato un altro problema
i 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-core
Dentro un MacBook Pro

Images courtesy of


Ambito Avionico


Ambito Avionico


Rete di processori
standard di
interconnessione
processori simmetrici


Supporto OS avanzato
partizionamento
mandatorio di tempo e
risorse



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


Che Vantaggi Offre?


Non solo miglioramento delle prestazioni...
… diverse ottimizzazioni progettuali
riduzione di componenti e TCO
e.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


Dentro un U9500 (ST-Ericsson)

Nokia Lumia 800


Dalle Board ai SoC... fino a PSoC ed FPGA


Quali Nuove Applicazioni Possiamo Aspettarci ?


Nuove forme di interazione “uomo-macchina”

Augmented Reality

Google Glass Project



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

Tuttavia spesso questi sono solo alcuni passi
di applicazioni complete...


Quali Sono le Prossime Sfide?


Fattori Tecnologici e Produttivi
i “transistor” di nuova generazione hanno
dimensioni in scala “atomica”

le variazioni in fase di produzione
divengono sempre più significative
22nm 4nm
non è più possibile differenziare i prodotti
in funzione del lotto di produzione far-lotti in-lotto

differenze di misurano addirittura
all'interno del singolo chip
Imoatto su prestazioni e consumi energetici fra-chip in-chip


Richiesta di maggiore flessibilità...


Come Supportare La Flessibiltià?


Progettare e produrre HW custom è costoso
oltre certi livelli di integrazione non è più conveniente

Spinta verso “architetture programmabili”
Esempio: produzione
di dispositivi multistandard
da SW ad-hoc su HW ad-hoc...
… a SW ad-hoc su HW generico


Vantaggi
Manutenibilità post-produzione
Supporto per applicazioni diverse [Ramacher09]

sia presenti che future
Riduzione di costi e tempi di produzione


Come si Confrontano Con le Soluzioni Attuali?


Rappresentano una nuova classe di dispositivi

Gops/mm^2 @ 32nm

Architetture
programmabili


Che Sfide Si Presentano a Sistema Operativo?


Gestione Dinamica delle Risorse

Identificare un compromesso ottimale fra
esigenze prestazionali (QoS) delle applicazioni e
disponibilità delle risorse


Risorse HW condivise, diverse classi di applicazioni
sofisticati dispositivi many-core di nuova generazione
variabilità di processo ed a run-time
risorse condivise fra applicazioni in competizione


Necessità di efficaci ma semplici supporti SW
in grado di adattarsi a diversi modi d'uso, a run-time
adeguati al supporto di applicazioni sia best-effort che critiche


Che Supporto Ci Si Aspetta dalla GDR?


Astrazione dalle risorse
Assegnare opportunamente le risorse
al fine di ottimizzare l'uso della piattaforma
Google Glass Project
Assistenza alla
guida


Considerando fenomeni di
Workloads Critici
variazione di processo
hot-spots e rotture Workloads Best-Effort
Assegnazione Risorse

variazioni del carico Richiesta Risorse

Run-Time
Resources

Possibili strategia? Manager

1. assegnamento di “risorse virtuali”
2. mapping su risorse fisiche a run-time
gestendo opportunamente i fenomeni di variabilità


Aspetti Industriali

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


Aspetti Industriali
Quali Iniziative Esistono?


Multicore Association
associazioni di industrie interessate alla
tecnologia multi-core
partner industriali ed accademici http://www.multicore-association.org/

Roadmap

Definizione di APIs
comunicazione
gestione delle risorse
scheduling dei task
monitoraggio e debugging

Funzionalità avanzata
bilanciamento di carico
gestione ed ottimizzazione
di QoS e potenza
affidabilità


Aspetti Industriali
Quali API Sono Già Disponibili?


MCAPI: supporto a comunicazione e sincronizzazione
basata su scambio di messaggi
per sistemi embedded “distribuiti”
sia in- che off-chip

Insieme di chiamate minimale
sufficienti a coprire le principali esegenze
semplici per supportare implementazioni efficienti

Orientatoall'embedded
soluzioni alternative puntano
piu all'HPC

v2.0 in lavorazione
shared memory,
zero copy message, …

Alternative proprietarie
e.g. RingIO by TI (con supporto Linux mainline)

Aspetti Industriali
Quali API Sono Già Disponibili?


MRAPI: suppporto a gestione delle risorse
coordinamento dell'accesso concorrente
sia in ambito SMP che AMP

Diverse classi di risorse gestibili
unità di elaborazione, sia omogenee che non
accelleratori HW
regioni di memoria
periferiche di I/O

Monitoraggio risorse
sia statico che dinamico

Meccanismi di notifica
stati delle risose (e.g. consumi) Codeplay Software, Freescale, IBM,
errori e faults IMEC, LSI Corporation, Mentor
cambiamenti di disponibilità Graphics, PolyCore Software,
Samsung, Texas Instruments, Tilera


Conclusioni

Tutto cambia... per rimanere simile!


Evoluzione dei Sistemi Embedded: Verso architetture multi-core

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie Evoluzione dei Sistemi Embedded: Verso architetture multi-core

Ähnlich wie Evoluzione dei Sistemi Embedded: Verso architetture multi-core (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

Evoluzione dei Sistemi Embedded: Verso architetture multi-core