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 (ACAT13): quiqui D.Abdurachmanovic (Concurrency Forum): quiqui

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 mk68000 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., AppliedMicro, 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, BlackBerry (formerly Research In Motion), Samsung, Sharp, Silicon Labs, Sony, ST-Ericsson, STMicroelectronics, Symbios Logic, Texas Instruments, Toshiba, Yamaha, Xilinx, and ZiiLABS.

… in un packaging semplice La maggior parte degli ARM viene ormai venduta in formato System on a Chip (SoC), un unico chip che include CPU (up to 8 cores) GPU (Mali, PowerVR, …) MMU Equivalenti di NB e SB RAM Anche questa compattezza permette di mantenere il consumo inferiore ai 10W 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 inizio 2014)

Altri drivers (meno tecnologici, piu’ sociali) Il mercato x86 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 x86 vs ARM e’ impietoso Worldwide PC shipments totaled 76.3 million units in the first quarter of 2013 (1Q13), 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 ARMv8 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 SoC abbastanza potenti per il nostro SW Sistemi “cluster”, in un box

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

Sistema operativo / ambiente operativo L’ambiente software e’ assolutamente friendly per le nostre esigenze Ubuntu (o Linaro) con APT Fedora 18 (indistinguibile da un RHEL e quindi da un SLC) con YUM Gcc Kernel Policy sul SW di CMS (CMSSW) 1. 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 (SSE4, AVX): nella maggior parte dei casi lasciamo fare al compilatore, dovrebbe bastare rimuovere –msse4 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 uint64_t e’ un long 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’

Dopo tutto questo, molte prove e fix banali Tutti gli externals di CMS compilano (tranne quelli direttamente legati a Oracle) Tutti i packages di CMSSW compilano (di nuovo, tranne quelli legati all’Online e a Oracle) Tempo di compilazione (per quello che puo’ valere) ~ 40 ore (dominato da gcc, Geant4 e CMSSW) Per Intel e’ + vicina alle 8 ore, per cu isipena di passare a breve a x-compilation

Cosa contiene una nostra release Base set di dipendenze CMS (gcc e poco piu’) Compila (~ 4 ore) Dipendenze in senso proprio (ROOT, Geant4, Boost, Qt, …) Compila (~12 ore) tranne I packages con dipendenza diretta da Oracle CMSSW (~3.5MSloc) vero e proprio 99% dei packages compilano (~25 ore); ancora, mancano solo quelli Online con dipendenza diretta da Oracle fc18_arm7hl_gcc480 e’ diventata una architettura standard di CMS, al pari di slc6_amd64_gcc472, 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 quiqui 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 T0/T1/T2/T3

Una volta che hai in mano un sistema funzionante …. Benchmarks! Rootmarks (singolo core) HepSpec06 (macchina completa) CPURoot marks Rispetto a ARM ARMv7 1.7 GHz3051 Intel Core i7 2.8 GHz 2720QM Intel Xeon 2.00GHz Intel Core i5 2.7 GHz 2500S Intel Xeon 2.20GHz MacchinaHS06fattore Olidata AQ 2013 (2x8 core AMD 2.8 GHz) Odroid (4 core ARMv7 1.7 GHz) 131 … fra e 3 e 6 volte piu’ lento sul singolo core …

Software di CMS Test solo sulla parte Simulazione Geant4+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 etc) Confrontare ARM vs Intel le posizioni degli HIT … senza farla lunga … tutto identico: ecco i primi 2 hit per entrambi Intel ARM

Un confronto un po’ scorretto … MacchinaPrezzo (EUR) Numero cores HS0 6/cor e HS06/2URAM (GB) Potenza dissipata Boston Viridis (2U) (?) W Olidata come da AQ (2U, 4 schede madri) kW (?) Se le consideriamo equivalenti come prestazioni, i 3kEuro di costo maggiore sono riassorbiti in 2 anni dal risparmio elettrico. (1W = 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 ARMv8, sarebbe interessante se qualche centro (T1, T2, T3, …) 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.25x per core, ma circa 4x se scalate anche per il consumo Avremo questi in futuro? 1 rack (42U): 1000 CPUs, 4000 cores 4 TB RAM ~5 kW