collaborative research center 912: haec highly adaptive ...ua1/talks/2014/2014-11-03-assmann... ·...

Collaborative Research Center 912: HAEC − Highly Adaptive Energy-Efficient Computing

Fakultät Informatik Institut Software- und Multimediatechnik, Lehrstuhl Softwaretechnologie

Generalized Autotuning

Uwe Aßmann Sebastian Götz, Julia Schroeter, Claas Wilke, Somayeh Malakuti Technische Universität Dresden So!ware Engineering Group http://st.inf.tu-dresden.de Nov 03, 2014 IFIP WG 2.4 Stellenbosch Meeting

Collaborative Research Center 912: HAEC − Highly Adaptive Energy-Efficient Computing

CRC 912 Highly Adaptive Energy-Efficient Computing

1.  The vision of the HAEC server box 1.  The adaptive so!ware architecture of the HAEC applications

2.  First Idea: Autotuning apps have a self-adaptive architecture

3.  Cost-Utility Functions and Energy-Utility Functions 4.  How to generalize performance autotuning to other

qualities? 1.  Quality and energy autotuning in HAEC applications

5.  Generalized Autotuning for all applications 1.  “Quality variant families”

3

Content

1. The HAEC Server Vision

And energy-adaptive applications


How to Get Energy-Efficient Servers? 5


http://en.wikipedia.org/wiki/Server_(computing)#mediaviewer/File:Rack001.jpg


Goal: Energy- Minimization By Multi-Layer SW/HW Adaptivity

Energy Proportionality 6

Zentrum für Informationsdienste & Hochleistungsrechnen Dresden Measurement: June 20, 2008

Slides courtesy to G. Fettweis


HAEC – Project Groups 7

Highly Adaptive Energy-efficient Computing

Energy-adaptive computing

management

Energy-adaptive high-speed computing platform

Energycontrol loop

ServerLevel

BoardLevel

wireless optical

HAEC Box

Mon

itorin

g M

onito

ring C

ontrol


HAEC – Project Group A Energy-adaptive High-Speed Computing Platform (HAEC Box)

Slide 8

8

1 Mio cores in a liter



Adaptive Energy-Efficient Inter-Chip Communication

9



Energy-Adaptive Software

Architecture •  Global QoS Optimization with “Energy-

Utility Functions” •  Cross-Layer Adaptation:

Application - System - Hardware

Mon

itorin

g M

onito

ring Control

HAEC – Project Group B Energy-adaptive Computing Management

10


End-User Perspective of HAEC Energy-Utility Adaptiveness

¨  The HAEC box shall be energy-utlity adaptive, i.e., adapt its energy consumption to user demands and the availability of resources.

¨  Adaptive „Quality of Service“ of video conferencing: ¤  Low utility – audio ¤  Middle utility – low video quality ¤  Upper utility – high video quality ¤  High utility – 3D holographic images ¤  Excellent utility – 3D holographic video

¨  Every application needs a QoS specification ¤  A „utility potentiometer“ ¤  An „energy consumption potentiometer“

Slide 11

Energy Consumption

Utility

Quality Equalizer

Medium

Low

High

Full

Middle

Low

Good

Excellent


Deliver Utility When it is Needed (User profiles)

Slide 12

Energy Adaptive Web Conferencing System

Energy Consumption

Utility

Quality Equalizer

Medium

Low

High

Full

Middle

Low

Good

Excellent

Participants

Chat User 1: Can you hear me? User 2: Yes. User 1: Ok, then let start our discussion.

Speaker: User 1

User 2

User 3

User 4


Technical Innovation of HAEC Applications: Architectural Energy-Autotuning

Slide 13

Energy Contract Checking

•  Does the system deliver its energy/utility promises?

Energy Contract

Negotiation

•  Which variant of the system delivers the energy/utility promises?

Energy Autotuning

•  Tailor to cost and utility

•  Based on constrained optimization

Architectural Energy

Autotuning

•  On the right grain size


You can’t save a Joule except you save it in the so!ware architecture

tailoring it to cost and utility switching off large parts of the hardware architecture

and reconfiguring the so!ware architecture appropriately

2. First Idea: Autotuning Apps are Self-Adaptive Architectures

HA

EC Autotuning for all

applications

Autotuning for other qualities

Autotuning uses SAS technology


•  Problem: Diverging Qualites of multi-variant codes for scientific kernels •  Vuduc: OSKI, F!w •  Parlab: work on stencils •  Parlab book with design pattern language

•  Static autotuning: Precompilation of multi-variant code •  Static or Load-time dispatching

•  Dynamic autotuning: Dynamic compilation of multi-variant code •  Dynamic dispatching •  Very similar to “Open Implementation” and “Self-adaptive systems”

16

Classic Performance Autotuning is not Related to Self-Adaptive Systems


Component/Subsystem

Component/Subsystem

Goal Manager Goal Management Layer (Strategic Layer)

Reconfiguration Planner

Architectural layer

Planning/reconfig layer

Implementation layer

Kramer/Magee SAS Architecture (2010) can be used for Autotuning

Component/Subsystem


The Dagstuhl M@RT Architecture for SAS (2012)

18

System

Capability Models

Context Models

Plan Models

E.g., quality-‐specific

Synchronization Problem

More abstract Model

More abstract Model

More abstract Model

Reasoner Analyzer

Evaluate Alternatives (key benefit)

Produces decidable properties

Environment

Goal / Adaptation Model

(Machine)Learner (keep models up-‐2-‐date)

Configuration Models

Goal Mgmt

Conf. Mgmt

Base Layer

monitor

analyze plan

act

[Götz,Aßmann,Trapp,Morin,Jezequel]

3. An Example for Diverging Qualities

For energy autotuning


¨  NineSky worse for small sites ¤  NineSky better for large images (loading times)

¨  Advertisement in EasyBrowser, DroidSurfing negative for long loading times only ¤  EasyBrowser better

→  Different browsers are optimal for different use cases

20

Comparing Web Browsers [Wilke]


Evaluating Mobile Applications‘ Energy Consumption

21


¨  MailDroid worst for all use cases ¤  Due to advertisement ¤  Effect increases for longer use cases

¨  MailDroidPro & K9 Mail rather similarly →  Different email clients differ in energy

consumption →  Users should avoid

advertisement banners (buy the app)

22

Comparing Email Clients


03.11.14 Evaluating Mobile Applications‘ Energy Consumption

23

4. How to Generalize Autotuning to Other Qualities? Cost-utility functions characterize quality-of-service

HA


applications




•  A quality-adaptive application self-adapts its cost-utility ratio to the context •  Changes its cost-utility function according to a context by changing

its code variant

•  An energy-adaptive application self-adapts its energy-utility ratio to the context •  Changes its energy-utility function according to a context

25

Quality-Adaptive Applications are Autotuning Applications for Qualities


Energy Contracts based on Cost- and Energy-Utility Functions (EUF)

¨  Cost-Utility Functions represent the economic principle „What do I get for a price“? ¤  like Time-Utility Functions ¤  Energy-Utility Functions are Cost-Utility Functions

¨  Utility-Cost Functions „What does the service cost?“ ¤  Utility-energy functions are Utility-Cost Functions

¨  Many different functions exist, integrating configuration parameters such as input size, algorithm variants, ...

26

Energy

Utility

Energy-QoS = Utility / Energy

Time

Utility

Time-QoS = Utility / Time


Energy- Consumption

Load size

15 MB 15MB 25MB 35MB

Tradeoff

EasyBrowsing

NineSky

NineSky saves energy after a tradeoff point Because it loads pages faster..

Input-to-Energy Function of Browsers

if(page.size < 19MB) NineSky.load(page); else EasyBrowsing.load(page);

Energy [J] = Power [W] * Time [s]


Utility (e.g., response

time)

Input (e.g., list size [#])

1.000.000 2.000.000 3.000.000 4.000.000

Tradeoff

Counting Sort

Radix Sort

Minimization

if(list size < 2.5e6) counting sort; else radix sort;

Depending on the size of the input data (context) a different utility results.

Radix and counting sort have have a tradeoff in terms of execution time.

Input-Utility Functions with Tradeoff Point


Energy- Efficiency = Performance/ Energy- Consumption

Input (e.g., list size [#])

1.000.000 2.000.000 3.000.000 4.000.000

Tradeoff

Counting Sort

Radix Sort

Minimization Radix and counting sort have a fixed power consumption rate (which differs from one another), but have a tradeoff in terms of execution time.

Input-to-Energy-Efficiency Function

if(list size < 2.5e6) counting sort; else radix sort;

Energy [J] = Power [W] * Time [s]


Energy-Effiency over Time (Energy-Efficiency Trace)

Energy-Efficiency = Quality / Energy (e.g., processed MB per Joule)

Configuration #1

Configuration #2

Time 13:00 13:05 13:10 13:15

Remark: If there are tradeoff points, arbitrary many reconfiguration points can result over time.

Reconfiguration Point


¨  Quality-Contract Language (QCL) ¤  If-then rule based language over resources, costs, utilities

n  Frame/s, bandwidth/s, CPU cycles, …

¨  Stepwise specification of Cost-Utility Functions

Prof. U. Aßmann, TU Dresden

31

HAEC: Specification of Cost-Utility Functions


Quality Contracts of a Component with Different Modes (Variants)

03.11.14

32

1 contract VLC implements VideoPlayer { 2 3 mode highQuality { 4 requires component Decoder { 5 min dataRate: 50 KB/s 6 } 7 8 requires resource CPU { 9 max cpuLoad: 50 percent 10 min frequency: 2 GHz 11 } 12 requires resource Net { 13 min bandwidth: 10 MBit/s 14 } 15 16 provides min frameRate: 25 FPS 17 provides min imageWidth: 1024 Pixel 18 provides min imageHeight: 768 Pixel 19 } 20 21 mode lowQuality { 22 /* More requirements and provisions here ... */ 23 } 24 }

Quality Modes

Hardware Dependencies

Software Dependencies

Quality Provision


Quality Contract of a Browser 33

contract Browser implements BrowserInterface { mode NineSky { requires component URL { min dataSize: 500 KB type: jpg } requires resource CPU { max cpuLoad: 50 percent } requires resource Net { min bandwidth: 10 MBit/s } provides min LoadRate: 7 MB/s provides min imageWidth: 1024 Pixel provides min imageHeight: 768 Pixel provides max Energy: 13 Joule } mode EasyBrowser { requires component Advertisement { } requires component URL { max dataSize: 700 KB } provides min LoadRate: 6Mb/s provides max Energy: 3 Joule } mode DroidSurfing { /* Quality Contract here */ } }

Hardware Dependencies

Good for large images

Quality Provision

Energy Consumption


Quality Contract of an Emailer

03.11.14

34

contract EmailGet implements EmailerGetInterface { requires resource CPU { max cpuLoad: 50 percent } requires resource Net { min bandwidth: 10 MBit/s } mode MailDroidGet { requires component Advertisement { } provides max Energy: 10 Joule } mode MailDroidProGet { /* does not require component Advertisement */ provides max Energy: 5 Joule } mode KMailGet { /* does not require component Advertisement */ provides max Energy: 6 Joule } }


Autotuning Apps with Browser and Emailer

¨  Cost minimization and utility maximization of browser and emailer in autotuning applications ¤  Compile the quality contracts

into linear equations (or un-equations)

¤  Specify the optimization goal with an objective function

¤  And solve the constraints

Cost and Utility Function space

Linear equations over cost and benefit

variables

QCL quality

Contracts

Utility Maximization

Cost minimzation

QCL quality

Contracts


•  A quality-adaptive application self-adapts its cost-utility ratio to the context •  Changes its cost-utility function according to a context

•  An energy-adaptive application self-adapts its energy-utility ratio to the context •  Changes its energy-utility function according to a context

36

Energy-Adaptive Applications

Specify the Cost-Utility Functions

• Write Quality Contracts

• Write Energy Contracts

Automatic Derivation

•  Derive cost-utility functions in ILP

•  Solve ILP •  Check constraints •  Select best-fit

quality variant • Generate dispatcher

Run Self-Adaptive

Application

•  Discover Tradeoff-Point

•  Re-solve ILP •  Re-check constraints •  Dispatcher re-selects

best-fit quality code variant

5. How To Generalize Autotuning from Kernels to all Applications?

With product-line technology

HA


applications


Autotuning uses SAS technology Le! out


Goal: Generalized Autotuning Process for All Applications

Specify the Quality-Variant Family • Write Quality Contracts • Model Features and Q-Features

Automatic Derivation •  Derive cost-utility functions in ILP •  Solve ILP •  Check feature constraints •  Select best-fit quality variant

consisting of the best-fit Q-features • Generate dispatcher

Run Self-Adaptive Application over Q-features •  Discover Tradeoff-Point •  Re-solve ILP •  Re-check feature constraints •  Dispatcher re-selects best-fit quality

variant

Works for all applications with multi-variant code


Generalized autotuning

Feature Model with Q-Features

Annotating components and q-features with

quality contracts (Cost-Utility Functions)

Dispatcher

39

Generalized Autotuning

Generalized Autotuning self-tunes the quality of all applications,

based on quality variants of components and q-features


HAEC Applications

¨  Scale in quality and cost ¨  Consist of multi-variant code ¨  Have self-adaptive architectures ¨  Autotune with regard to quality and cost ¨  Switch off hardware appropriately

HA


applications




You can’t save a Joule except you save it in the so#ware architecture

tailoring it to cost and utility switching off large parts of the hardware architecture

and reconfiguring the so!ware architecture appropriately

6. More on HAEC


Vision: IDE for HAEC 43

Functional Requirements

Non-Functional Requirements

Performance Energy Safety

Modelling

Test (JouleUnit)

Verification

Autotuning

Energy Labeling

Energy Autotuning


Phases of HAEC

Phase 1: Year 1-4 •  Basic technologies •  Model-based Validation •  First experiments with cross-layer optim.

Phase 2: Year 5-8 •  Subsystem and Cross-Layer Integration •  Context-sensitive Adaption •  HAEC-Box design

Phase 3: Year 9-12 •  HAEC-Box as server •  Assessment Phase •  Transfer

44

Objective: Energy-adaptive HAEC-Box

Objective: Technology Demonstrators

Objective: Components „in-the-loop“


Info Slide 45

www.resubic.org www.qualitune.org http://st.inf.tu-dresden.de/

Thank You!

Highly-Adaptive Energy-Efficient Computing (HAEC) Collaborative Research Center http://tu-dresden.de/forschung/forschungskompetenz/

sonderforschungsbereiche/sfb912/index_html/document_view?set_language=en


Literature

•  S. Götz, C. Wilke, S. Cech, and U. Aßmann, Runtime variability management for energy-efficient so!ware by contract negotiation,” in Proceedings of the MRT’11 workshop, 2011.

•  Sebastian Götz, Claas Wilke, Sebastian Richly, and Uwe Aßmann. Approximating quality contracts for energy auto-tuning so!ware. In Rick Kazman et al., editors, Proceedings of First International Workshop on Green and Sustainable So!ware (GREENS 2012), pages 8-14. IEEE, 2012.

•  Claas Wilke, Sebastian Götz, Jan Reimann, and Uwe Aßmann. Vision Paper: Towards Model-Based Energy Testing. In: Proceedings of the ACM/IEEE 14th International Conference on Model Driven Engineering Languages and Systems (MODELS2011), Vol. 6981 of LNCS, Springer (2011), pp. 480-489.

•  Sebastian Götz, Claas Wilke, Sebastian Richly, Georg Püschel, and Uwe Aßmann. Model-driven self-optimization using integer linear programming and pseudo-boolean optimization. In Proceedings of The Fi!h International Conference on Adaptive and Self-Adaptive Systems and Applications (ADAPTIVE), 2013.

•  S. Malakuti and C. Wilke, “Energy aspects: Modularizing energy-aware applications,” in Proceedings of the 3rd International Workshop on Green and Sustainable So!ware, ser. GREENS 2014. New York, NY, USA: ACM, 2014, pp. 23–30. [Online]. Available: http://doi.acm.org/10.1145/2593743.2593747

¨  S.Götz, T.Ilsche, J.Cardoso, J.Spillner, U.Aßmann, W.E.Nagel,and A.Schill,“Energy-efficient data processing at sweet spot frequencies,” in Proceedings of the 4th International Symposium on Cloud Computing, Trusted Computing and Secure Virtual Infrastructures, ser. Lecture Notes in Computer Science, vol. 8842. Heidelberg, Germany: Springer, 2014, pp. 154–171.

¨  S. Götz, T. Ilsche, J. Cardoso, J. Spillner, T. Kissinger, U. Aßmann, W. Lehner, W. E. Nagel, and A. Schill, “Energy- efficient databases using sweet spot frequencies,” in Proceedings of the 7th International Conference on Utility and Cloud Computing. New York, NY, USA: IEEE, 2014.

46


PhD Theses, Self-Adaptive Architectures

•  Sebastian Götz. Multi-Quality Auto-Tuning by Contract Negotiation. PhD thesis, Technische Universität Dresden, Fakultät Informatik, July 2013. http://nbn-resolving.de/urn:nbn:de:bsz:14-qucosa-119938

•  Claas Wilke. Energy-Aware Development and Labeling for Mobile Applications. PhD thesis, Technische Universität Dresden, Fakultät Informatik, March 2014. http://nbn-resolving.de/urn:nbn:de:bsz:14-qucosa-139391

¨  Georg Püschel, Sebastian Götz, Claas Wilke, and Uwe Aßmann. Towards systematic model-based testing of self-adaptive systems. In Proceedings of The Fi!h International Conference on Adaptive and Self-Adaptive Systems and Applications (ADAPTIVE), 2013.

¨  S. Malakuti, “Detecting emergent interference in integration of multiple self-adaptive systems,” in Proceedings of the 2nd Workshop on So!ware Engineering for Systems of Systems, ser. ECSAW ’14, New York, NY, USA: ACM, 2014.

¨  U. Aßmann, S. Götz, J.-M. Jézéquel, B. Morin, and M. Trapp, A Reference Architecture and Roadmap for [email protected] Systems, Lecture Notes in Computer Science, N. Bencomo, R. France, B. H. Cheng, and U. Aßmann, Eds. Heidelberg, Germany: Springer, 2014, vol. 8378.

collaborative research center 912: haec highly adaptive ...ua1/talks/2014/2014-11-03-assmann... ·...

Documents