TESTS CON ARCHITETTURA ARM E SOFTWARE HEP Tommaso

TESTS CON ARCHITETTURA ARM E SOFTWARE HEP Tommaso Boccali – INFN Pisa

Outline • Cosa e’ / cosa ha di speciale l’architettura ARM • ARM per noi • Alcuni studi di porting in CMS • Una simulazione (a grandi linee) di usabilita’ • Nota bene: io sono marginalmente coinvolto in queste attivita’. Puntatori utili sono • P. Elmer (ACAT 13): qui • D. Abdurachmanovic (Concurrency Forum): qui

Processori ARM • Linea di processori RISC sviluppata dall’inglese ARM (per i piu’ vecchi, la CPU dell’Acorn Archimedes, che rivaleggiava con l’Amiga), a partire dal 1987 • Il primo disegno ARM risale al 1987, e fin dalle origini e’ sempre stato a 32 bit • E era il vanto dell’archimedes contro il povero mk 68000 dell’amiga • ARM non possiede foundries, ma concede il disegno delle varie versioni su licenza • Produttori su licenza Advanced Micro Devices, Inc. , Alcatel-Lucent, Altera, Apple Inc. , Applied. Micro, Atmel, Broadcom, Cirrus Logic, CSR plc, Cypress Semiconductor, Digital Equipment Corporation, Ember, Energy Micro, Freescale, Fujitsu, Fuzhou Rockchip, Huawei, Intel (through DEC), LG, Marvell Technology Group, Microsemi, Microsoft, NEC, Nintendo, Nuvoton, Nvidia, NXP (formerly Philips Semiconductor), Oki, ON Semiconductor, Panasonic, Qualcomm, Renesas, Black. Berry (formerly Research In Motion), Samsung, Sharp, Silicon Labs, Sony, ST-Ericsson, STMicroelectronics, Symbios Logic, Texas Instruments, Toshiba, Yamaha, Xilinx, and Zii. LABS.

… in un packaging semplice • La maggior parte degli ARM viene ormai venduta in formato System on a Chip (So. C), un unico chip che include • CPU (up to 8 cores) • GPU (Mali, Power. VR, …) • MMU • Equivalenti di NB e SB • RAM • Anche questa compattezza permette di mantenere il consumo inferiore ai 10 W totali, utilizzando tecnologia fino a 28 nm

Ok, ma per noi? • L’interesse per questi processori per il nostro ambiente scaturisce soprattutto dal basso consumo, in un momento in cui siamo strozzati da costi elettrici (per HW e raffreddamento) dei nostri centri di calcolo. • Fino a poco fa la potenza di questi chip non era assolutamente in grado di soddisfare i nostri bisogni, ma le cose stanno cambiando velocemente

La famiglia ARM Rpi Praticamente tutti gli smartphones recenti 64 bit! (fine 2013 inizio 2014)

Altri drivers (meno tecnologici, piu’ sociali) • Il mercato x 86 e’ ormai nelle mani di Intel • Sugli ARM invece la lotta e’ feroce fra almeno 3 grossi produttori (Apple, Samsung, Nvidia) • Il confronto fra i numeri di processori x 86 vs ARM e’ impietoso Worldwide PC shipments totaled 76. 3 million units in the first quarter of 2013 (1 Q 13), down -13. 9% compared to the same quarter in 2012 and worse than the forecast decline of -7. 7%

Tests di ARM in ambiente HEP • Non in produzione nel breve periodo, ma non e’ folle pensare che nel giro di qualche anno saremo felici (o costretti? ) a passare a architettura ARM • I principali esperimenti stanno cominciando dei test per valutare la fattibilita’ di girare il loro SW su ARM • In attesa di avere fra le mani un ARMv 8 a 64 bit • Qui riporto tests di CMS; altri esperimenti stanno facendo prove ma non mi risulta che nessun altro abbia uno stack SW completo funzionante su ARM • Cosa possiamo usare OGGI come piattaforme di development? • Singoli So. C abbastanza potenti per il nostro SW • Sistemi “cluster”, in un box

Odroid U 2 In pratica un Samsung Galaxy SIII senza schermo • Exynos 4412 4 -core a 1. 7 GHz (ARMv 7) • 2 GB RAM • GPU Mali 400 4 -core • Memoria e. MMC (64 GB) • 5 W idle, < 7 W a pieno carico • Abbiamo misurato a Pisa con pinza amperometrica • 89$ + memoria, alimentatore, importazione etc -> 150 Euro Boston Viridis In 2 U: • 48 So. C ARMv 7(1. 4 GHz) 4 core, ciascuno con 4 GB RAM • backplane di connessione fra le schede 8 x 10 Gbe; con l’esterno a 20 Gbit/s • 24 x SATA slots (ogni So. C 4 x. SATA) • Consumo TOTALE a pieno carico minore di 300 W • Prezzo: per grossi acquisti ~10 k. Euro (? )

Sistema operativo / ambiente operativo • L’ambiente software e’ assolutamente friendly per le nostre esigenze • Policy sul SW di CMS (CMSSW) 1. • Ubuntu 13. 11 (o Linaro) con APT • Fedora 18 (indistinguibile da un RHEL e quindi da un SLC) con YUM • Gcc 4. 8. 0 • Kernel 3. 0. 65+ per inserire un software nel nostro stack, pretendiamo di averne i sorgenti • ci ha proibito di usare pacchetti di NN ~commerciali, ma in questo caso ne vediamo il vantaggio 2. Usiamo da sistema operativo “host” in pratica solo il kernel e le glibc. Ricompiliamo anche il compilatore.

Quali difficolta’ aspettarci • Stesso compilatore: dovrebbe assorbire la maggior parte dei problemi (non siamo costretti come con il Phi a andare a icc) • 32 bit vs 64 bit: ormai siamo passati da tanto tempo, il nostro codice assume di girare a 64 bit. Possibile un po’ di sporcizia con l’aritmetica dei puntatori e/o i tipi • Ottimizzazioni Intel specifiche (SSE 4, AVX): nella maggior parte dei casi lasciamo fare al compilatore, dovrebbe bastare rimuovere –msse 4 • Ma c’e’ NEON (SIMD), e gcc lo sa autovettorizzare • Per il resto … bisogna provare!

Altri problemi trovati • Banalmente, la parte online del SW non compila perche’ Oracle su ARM non esiste • Poco importante, l’offline di CMS non dipende da Oracle • “char” e’ un po’ inaspettatamente signed su Intel, unsigned su ARM • Poco male: -funsigned-char / -fsigned-char come opzioni di compilazione • Alcuni. cc (principalmente dizionari di ROOT) non compilano con 2 GB di RAM • Splitting di classi in piu’ files • Cintex (parte della reflection di ROOT) ha dei problemi di allineamento in memoria – patch sottomessa a ROOT

• In architetture a 32 bit uint 64_t e’ un long. • Ma allora: • Non e’ ok, serve • (stavamo quindi assumendo di essere a 64 bit)

Il timing e’ non banale • Serve un timer diverso (disponibile su ARM: Performance Measurement Unit – PMU), ma non ancora integrato • Comunque il timing e’ utile per i benchmarking, ma non vitale per I test di funzionalita’

Cosa contiene una nostra release • Base set di dipendenze CMS (gcc e poco piu’) • Compila (~ 4 ore) • Dipendenze in senso proprio (ROOT, Geant 4, Boost, Qt, …) • Compila (~12 ore) tranne I packages con dipendenza diretta da Oracle • CMSSW (~3. 5 MSloc) vero e proprio • 99% dei packages compilano (~25 ore); ancora, mancano solo quelli Online con dipendenza diretta da Oracle • fc 18_arm 7 hl_gcc 480 e’ diventata una architettura standard di CMS, al pari di slc 6_amd 64_gcc 472, e ha integration builds automatiche giornaliere

I fallimenti • Su 1119 packages di CMSSW • 13 non compilano per Oracle • 5 non linkano perche’ dipendono da quei 13 • Il resto e’ ok! • Vedere qui Ma come detto, i fallimenti Oracle NON limitano l’utilizzo offline di CMSSW E’ possibile (o sara’ possibile a breve) girare qualunque workflow di quelli che girano via GRID su T 0/T 1/T 2/T 3

Una volta che hai in mano un sistema funzionante …. Benchmarks! • Rootmarks (singolo core) CPU Root marks Rispetto a ARMv 7 1. 7 GHz 305 1 Intel Core i 7 2. 8 GHz 2720 QM 1444 4. 7 Intel Xeon E 5 -2650 @ 2. 00 GHz 1483 4. 8 Intel Core i 5 2. 7 GHz 2500 S 1723 5. 6 Intel Xeon E 5 -4620 @ 2. 20 GHz 1313 4. 3 • Hep. Spec 06 (macchina completa) Macchina HS 06 fattore Olidata AQ 2013 (2 x 8 core AMD 2. 8 GHz) 172 13 Odroid (4 core ARMv 7 1. 7 GHz) 13 1 … fra e 3 e 6 volte piu’ lento sul singolo core …

Software di CMS • Test solo sulla parte Simulazione Geant 4+Digitizzazione dei segnali (… avendo 10 giorni in piu’ … ) Throughput puro ~ 3 per core volte peggio Throughput scalato al consumo ~5 volte meglio

Numericamente? • (PS: ieri non c’ero, mi e’ stato detto che vi e’ interesse nel capire la bit per bit equivalence fra Intel e ARM) • Ieri pomeriggio ho fatto velocemente: • Girare una particle gun di Muoni in CMS (Full Geometry, full material) • Passare via Geant con tutta la fisica accesa (multiple scattering, etc) • Confrontare ARM vs Intel le posizioni degli HIT • … senza farla lunga … tutto identico: ecco i primi 2 hit per entrambi Intel ARM Non si legge, ma sono identici fino all’ultima cifra

Un confronto un po’ scorretto … Macchina Prezzo (EUR) Boston Viridis (2 U) 10000 (? ) 192 Olidata come da 7000 AQ (2 U, 4 schede madri) Numero cores 64 HS 06/2 U RAM /core (GB) Potenza dissipata 3. 25 624 192 300 W 11 690 256 1. 2 k. W (? ) Se le consideriamo equivalenti come prestazioni, i 3 k. Euro di costo maggiore sono riassorbiti in 2 anni dal risparmio elettrico. (1 W = 1 Eur/anno, e c’e’ da considerare consumo del condizionamento) OGGI: probabilmente non competitivo, ma NON siamo assolutamente distanti ordini di grandezza

Next steps… • Avere ricostruzione che gira (lo fa, ma ci sono dei crashes sporadici da capire) • Cosa si puo’ fare con 2 GB di RAM e 4 cores? • In modalita’ single core poco, CMSSW prende ~ 2 GB per girare • Ma si possono fare tests multithreaf/multiprocess: • 1 GB baseline + ~ 300 MB/core, si puo’ provare a usare il sistema globalmente • Lo scopo vero al momento e’ • Validare l’architettura (comprende Physics Validation) • Continuare con le Integration Builds per essere sicuri di mantenere tutto funzionante su ARM • Una volta usciti gli ARMv 8, sarebbe interessante se qualche centro (T 1, T 2, T 3, …) volesse portare in produzione questi oggetti • A livello italiano, pare possibile all’interno di PON, FIRB, PRIN, (Premiali? ) …

Conclusioni • Il porting di uno stack software complesso come quello di CMS su ARM e’ stato in gran parte effettuato • Sono stati trovati problemi piu’ o meno attesi, ma in generale il fatto di avere lo stesso compilatore e’ un grande vantaggio che scherma da quasi tutti i problemi • Primi benchmarks sul sw portato (e altri benchamark HEP) dicono che consistentemente ci si possono aspettare performance pari a 0. 25 x per core, ma circa 4 x se scalate anche per il consumo • Avremo questi in futuro? 1 rack (42 U): • 1000 CPUs, 4000 cores • 4 TB RAM • ~5 k. W