Hogeschool van Amsterdam

Kenniscentrum Techniek

Case: Super (efficiënte) computing

Is sneller altijd groener?

18 sep 2015 00:00 | Faculteit Techniek

Supercomputers zijn grote systemen waarmee we complexe rekenproblemen kunnen oplossen, zoals weers- en vloeistofsimulaties. Een van de grootste supercomputers is Titan, van Oak Ridge in de VS. De Nederlandse nationale supercomputer, Cartesius, is kleiner maar haalt nog altijd 1,1 petaflop/s met zijn 40.960 CPU-kernen en 132 GPU-acceleratoren.

Stroomverbruik

Computers worden elk jaar weer efficiënter, maar het stroomverbruik van supercomputers blijft een groot probleem: het maximale opgenomen vermogen van Titan bedraagt 8,2 megawatt (± 40.000 zonnepanelen), terwijl Cartesius iets minder dan 1 megawatt verbruikt. Ongeveer 28 procent van het totale budget van een supercomputer (inclusief hardware en personeel) wordt uitgegeven aan de elektriciteitsrekening. Het is dan ook niet verwonderlijk dat energie-efficiëntie hoog op de agenda staat op tal van terreinen, variërend van processorarchitectuur tot besturingssystemen en stroomvoorzieningen. Maar kunnen ontwikkelaars van HPC-software (High-Performance Computing-software) ook helpen om het energieverbruik te verminderen?

Is sneller altijd groener?

De totale hoeveelheid energie ‘E’ in joule of kWh die een softwareprogramma verbruikt is gelijk aan het product van het vermogen ‘P’ in watt en de tijd ‘t’ in seconden: E = P x t. Als we dus snellere software ontwikkelen (met een lagere waarde voor ‘t’), verbruiken we minder energie (lagere ‘E’), toch?

nvt

Het blijkt dat deze conclusie weliswaar voor de meeste gevallen geldt, maar niet altijd: ‘P’ kan in zekere mate worden beïnvloed door het ontwerp van de software. Daarnaast kan de energie ‘E’ worden verminderd door frequentieschaling van de hardware, zoals is aangetoond in het onderzoek van J. Aliaga et al. getiteld ‘Are our dense linear algebra libraries energy-friendly?’. In dit onderzoek wordt het vermogen ‘P’ verkleind door minder CPU-kernen of een lagere klokfrequentie te gebruiken. Dit gaat weliswaar gepaard met mindere prestaties (een hogere ‘t’), maar leidt wel tot een lager totaal energieverbruik. Uit het onderzoek blijkt dat de snelste configuratie niet altijd de ‘groenste’ is, met name bij applicaties waarbij geheugen de bottleneck is zoals niveau 1 en 2 BLAS-routines (zie afbeelding 3 voor een voorbeeld).

nvt

Hoe kunnen programmeurs het energieverbruik meten?

HPC-programmeurs optimaliseren momenteel hun code met het oog op de snelheid. Dit is niet alleen omdat snelheid de belangrijkste maatstaf is; het is ook de maatstaf die het eenvoudigst kan worden verkregen. Zelfs als dit vanuit een programmeerperspectief een probleem zou zijn (wat het niet is), dan zouden programmeurs hun software nog handmatig met een stopwatch kunnen timen. Maar hoe kun je stroomverbruik meten als je geen fysieke toegang hebt tot het systeem? (Let erop dat de energie kan worden berekend zodra het vermogen en de tijd bekend zijn.)

Momenteel zijn er twee hoofdmethoden om het vermogen te meten. De eerste is RAPL, wat staat voor ‘Running Average Power Limit’. RAPL is een softwaremodel waarmee het stroomverbruik wordt geschat op basis van verschillende performance-indicatoren in de CPU. Dergelijke indicatoren zijn bijvoorbeeld het aantal integer-optellingen, de prestatiegegevens van de cache en de hoeveelheid genomen branches. Uit verificatie met een externe wattmeter blijkt dat met dit model het werkelijke stroomverbruik behoorlijk nauwkeurig kan worden geschat. Voordelen van RAPL zijn de hoge samplefrequentie (1 kHz) en de onderverdeling in componenten (bv. geheugen, CPU). Het model houdt echter alleen rekening met de kerncomponenten: er wordt geen schatting gemaakt van het vermogen van het moederbord van een node in een cluster of de add-onkaarten (zoals GPU-acceleratoren).

De tweede methode om het vermogen te meten is de Baseboard Management Controller, of BMC. Dit betreft een daadwerkelijke meting van de gehele node (waarmee het nadeel van RAPL wordt ondervangen). BMC heeft echter wel een veel lagere samplefrequentie (ongeveer 4 Hz) en maakt geen onderverdeling in afzonderlijke componenten.

Gedetailleerde energiemetingen

RAPL en BMC kunnen dus beide worden gebruikt voor metingen van vermogen en energie. Ze hebben echter allebei hun nadelen. Om gedetailleerde vermogensmetingen mogelijk te maken heeft het SEFLab (Software Energy Footprint Lab) van de Hogeschool van Amsterdam verschillende sensoren in een systeem van SURFsara geïnstalleerd. Deze sensoren hebben een hoge samplesnelheid van ongeveer 30 kHz en worden zo geplaatst dat ze verschillende componenten afzonderlijk kunnen meten (zie afbeelding 4).

nvt

Ter verificatie werden de RAPL- en BMC-metingen vergeleken met de betrouwbare hardwaremetingen van de speciaal ontwikkelde sensoren van het SEFLab. De resultaten staan in afbeelding 5: de meetsensoren staan links, RAPL en BMC staan rechts. De resultaten zijn zoals verwacht: de resultaten van RAPL (paarse lijnen) kunnen de hoge samplesnelheid van de meetsensoren bijhouden met een constant verschil. Dit verschil wordt gemeten door de BMC (geel), maar die kan door de lage samplesnelheid de snelle frequentieveranderingen niet volgen. De rode en blauwe lijnen komen goed overeen: RAPL en BMC zijn bijgevolg gevalideerd en kunnen voor metingen worden gebruikt.

nvt

De volgende stappen

Met behulp van de sensoren van het SEFLab en de RAPL- en BMC-metingen kunnen we de vermogens- en energiekenmerken van HPC-software onderzoeken. Programmeurs gebruiken al profilingsoftware zoals Scalasca en Vampir om hun applicaties te evalueren en te timen. Op dit moment kunnen ze de gegevens van de RAPL-vermogensmetingen al in hun profilingsoftware opnemen. In de toekomst worden er nog gedetailleerdere energiemetingen mogelijk, als de zeer gedetailleerde sensoren van het SEFLab ook in profilingsoftware zijn geïntegreerd. Houd deze website in de gaten voor info over energiezuinigere software! Klik hier voor de website.