Modeling Performance and Energy Efficiency of Applica5on - - PowerPoint PPT Presentation

Modeling ¡Performance ¡and ¡Energy ¡ Efficiency ¡of ¡Applica5on ¡Codes ¡

Shirley ¡Moore ¡ University ¡of ¡Texas ¡at ¡El ¡Paso ¡ svmoore@utep.edu ¡ ¡

10/27/12 ¡ 1 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Introduc5on ¡

• Current trends in HPC put great focus on constraining

power consumption without decreasing performance.

• Multicore systems are hierarchical and can include

heterogeneous components.

• Understanding the mapping of scientific applications
• nto multicore and heterogeneous systems is

necessary to optimize performance and power consumption.

• Goal: Efficient use of multicore and heterogeneous

systems by scientific applications in terms of runtime and power consumption.

10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡ 2 ¡

Performance-­‑Power ¡Co-­‑Modeling ¡

• Goals ¡ ¡

– Understand ¡and ¡predict ¡execu5on ¡5me ¡and ¡energy ¡ consump5on ¡of ¡a ¡given ¡code ¡or ¡kernel ¡ – Devise ¡DVFS ¡strategies ¡that ¡reduce ¡energy ¡ consump5on ¡with ¡minimal ¡effect ¡on ¡performance ¡

• Models ¡vary ¡from ¡purely ¡analy5cal ¡to ¡empirically ¡

based ¡sta5s5cal ¡models ¡based ¡on ¡regression ¡

• analysis. ¡ ¡
• Different ¡models ¡may ¡be ¡required ¡for ¡different ¡

classes ¡of ¡applica5ons ¡and ¡even ¡different ¡phases ¡

• f ¡the ¡same ¡applica5on. ¡

10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡ 3 ¡

What ¡is ¡DVFS? ¡

• Dynamic ¡Voltage ¡Frequency ¡Scaling ¡
• Changing ¡the ¡frequency ¡and ¡opera5ng ¡voltage ¡of ¡a ¡

processor ¡based ¡on ¡performance ¡requirements ¡in ¡

• rder ¡to ¡reduce ¡energy ¡consump5on ¡
• Power ¡ ¡= ¡cV2F ¡

– Linear ¡reduc5on ¡in ¡voltage ¡and ¡frequency ¡yields ¡cubic ¡ reduc5on ¡in ¡power ¡ ¡

• Energy ¡consump5on ¡is ¡power ¡integrated ¡over ¡5me. ¡
• Voltage ¡transi5ons ¡on ¡order ¡of ¡tens ¡of ¡nanoseconds ¡

with ¡on-­‑chip ¡voltage ¡regulators. ¡

• A ¡DVFS ¡strategy ¡is ¡a ¡schedule ¡for ¡changing ¡voltage ¡

levels ¡during ¡applica5on ¡execu5on. ¡

10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡ 4 ¡

CPU ¡vs. ¡Memory ¡Bound ¡Applica5ons ¡

• For ¡a ¡totally ¡CPU-­‑bound ¡computa5on ¡(no ¡main ¡

memory ¡accesses): ¡

Given ¡execu5on ¡5me ¡t0 ¡at ¡CPU ¡frequency ¡f0 ¡and ¡a ¡target ¡CPU ¡ frequency ¡fnew, ¡the ¡execu5on ¡5me ¡tnew ¡is ¡given ¡by ¡

tnew ¡= ¡t0 ¡* ¡ ¡

• A ¡totally ¡memory-­‑bound ¡computa5on ¡(all ¡execu5on ¡

5me ¡is ¡spent ¡accessing ¡memory) ¡experiences ¡no ¡ slowdown ¡at ¡a ¡slower ¡CPU ¡clock ¡frequency. ¡

• Most ¡applica5ons ¡are ¡somewhere ¡in ¡between: ¡

tnew ¡= ¡memory ¡access ¡5me ¡ ¡+ ¡ ¡ ¡ ¡ ¡* ¡(compute ¡5me ¡at ¡f0) ¡

5 ¡ f0 fnew f0 fnew 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

How ¡to ¡Measure ¡Memory ¡Access ¡and ¡ ¡ Compute ¡Times? ¡

• Cycle ¡breakdown ¡model: ¡

Total ¡cycles ¡= ¡Re2red ¡cycles ¡+ ¡Non-­‑re2red ¡cycles ¡+ ¡Stall ¡cycles ¡

• Stall ¡cycles ¡can ¡be ¡approximately ¡decomposed ¡into ¡a ¡

sum ¡of ¡counts ¡of ¡events ¡causing ¡stalls ¡(Ni) ¡weighted ¡by ¡ their ¡penal5es ¡(Pi): ¡

Counted_Stall_Cycles ¡= ¡Σ ¡Pi ¡* ¡Ni ¡ ¡

• Errors ¡range ¡from ¡5-­‑30% ¡

– ¡Some ¡needed ¡counters ¡are ¡not ¡available ¡(varies ¡by ¡ pladorm). ¡ – ¡Penal5es ¡are ¡es5mates ¡and ¡aren’t ¡really ¡constants. ¡ ¡ ¡ ¡ ¡ ¡ ¡

6 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

PerfExpert ¡LCPI ¡Metric ¡

• M. ¡Burtscher, ¡B. ¡Kim, ¡J. ¡Diamond, ¡J. ¡McCalpin, ¡
• L. ¡Koesterke, ¡and ¡J. ¡Browne. ¡“PerfExpert: ¡An ¡

Easy-­‑to-­‑Use ¡Performance ¡Diagnosis ¡Tool ¡for ¡ HPC ¡Applica5ons”, ¡SC10, ¡November ¡2010 ¡(to ¡ appear) ¡

• Combines ¡performance ¡counter ¡

measurements ¡with ¡architectural ¡parameters ¡ to ¡compute ¡upper ¡bounds ¡on ¡local ¡cycle-­‑per-­‑ instruc5on ¡(LCPI) ¡contribu5ons ¡

10/27/12 ¡ 7 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Six ¡LCPI ¡Categories ¡

• Data ¡memory ¡accesses: ¡

¡ ¡ ¡L1_DCA*L1_lat+L2_DCA*L2_lat+L2_DCM*Mem_lat)/TOT_INS ¡

• Branching ¡contribu5on: ¡

¡ ¡ ¡ ¡(BR_INS*BR_lat+BR_MSP*BR_miss_lat)/TOT_INS ¡

• Other ¡categories: ¡

– Instruc5on ¡accesses ¡ – Floa5ng ¡point ¡instruc5ons ¡ – Instruc5on ¡TLB ¡accesses ¡ – Data ¡TLB ¡accesses ¡

10/27/12 ¡ 8 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Hardware ¡Counters ¡

Hardware ¡performance ¡counters ¡available ¡on ¡most ¡ modern ¡ ¡microprocessors ¡can ¡provide ¡insight ¡into: ¡ ¡

• 1. Whole ¡program ¡5ming ¡
• 2. Cache ¡behaviors ¡
• 3. Branch ¡behaviors ¡
• 4. Memory ¡and ¡resource ¡access ¡pamerns ¡
• 5. Pipeline ¡stalls ¡
• 6. Floa5ng ¡point ¡efficiency ¡
• 7. Instruc5ons ¡per ¡cycle ¡

Hardware ¡counter ¡informa5on ¡can ¡be ¡obtained ¡with: ¡

– Subrou5ne ¡or ¡basic ¡block ¡resolu5on ¡ – Process ¡or ¡thread ¡amribu5on ¡

9 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

PAPI ¡Background ¡

• Performance ¡API ¡-­‑ ¡hmp://icl.utk.edu/papi/ ¡ ¡
• Middleware ¡to ¡provide ¡a ¡consistent ¡programming ¡

interface ¡for ¡the ¡performance ¡counter ¡hardware ¡found ¡ in ¡most ¡major ¡micro-­‑processors ¡

• De ¡facto ¡standard ¡
• Countable ¡events ¡are ¡defined ¡in ¡two ¡ways: ¡

– Pladorm-­‑neutral ¡preset ¡events ¡ ¡ – Pladorm-­‑dependent ¡na5ve ¡events ¡

• Presets ¡can ¡be ¡derived ¡from ¡mul5ple ¡na2ve ¡events. ¡
• Events ¡can ¡be ¡mul5plexed ¡if ¡physical ¡counters ¡are ¡
• limited. ¡
• Sta5s5cal ¡sampling ¡implemented ¡by: ¡

– Hardware ¡overflow ¡if ¡supported ¡by ¡the ¡pladorm ¡ – Sorware ¡overflow ¡with ¡5mer ¡driven ¡sampling ¡

10 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

PAPI ¡user-­‑defined ¡event ¡mechanism ¡

• Allows ¡users ¡to ¡define ¡their ¡own ¡metrics ¡

– User ¡can ¡combine ¡events ¡and ¡constants ¡in ¡an ¡ expression ¡to ¡define ¡and ¡name ¡a ¡new ¡metric ¡ – Maps ¡the ¡new ¡metric ¡to ¡events ¡available ¡on ¡a ¡ pladorm ¡without ¡the ¡need ¡to ¡re-­‑install ¡PAPI ¡

• User-­‑defined ¡event ¡names ¡can ¡be ¡used ¡in ¡PAPI ¡

library ¡calls ¡the ¡same ¡way ¡as ¡preset ¡and ¡na5ve ¡

• events. ¡
• User-­‑defined ¡events ¡can ¡be ¡used ¡with ¡end-­‑user ¡

performance ¡tools ¡such ¡as ¡TAU ¡and ¡Scalasca ¡ without ¡modifying ¡those ¡tools. ¡ ¡

11 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Specifica5on ¡of ¡user-­‑defined ¡events ¡

• Event ¡specifica5on ¡file ¡

– parsed ¡at ¡PAPI_library_init ¡5me, ¡or ¡ – any5me ¡arerwards ¡with ¡PAPI_set_opt ¡call ¡

• Also ¡allow ¡sta5c ¡defini5on ¡at ¡PAPI ¡compile ¡5me ¡
• File ¡named ¡by ¡

– PAPI_USER_EVENTS_FILE ¡environment ¡variable, ¡or ¡ – op5on ¡to ¡PAPI_set_opt

• Event ¡defined ¡by ¡

¡ ¡ ¡ ¡ ¡ ¡Event, ¡OPERATION_STRING ¡

12 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Example ¡event ¡defini5on ¡file ¡

• ­‑-­‑-­‑-­‑-­‑-­‑ ¡Example ¡events ¡file ¡-­‑-­‑-­‑-­‑-­‑-­‑ ¡

#define ¡BR_lat ¡5 ¡ #define ¡BR_miss_lat ¡45 ¡ #define ¡L1_lat ¡3 ¡ #define ¡L2_lat ¡13 ¡ #define ¡Mem_lat ¡450 ¡ Branch_cat, ¡PAPI_BR_INS|BR_lat|*|PAPI_BR_MSP| BR_miss_lat|*|+|PAPI_TOT_INS|/ ¡ Mem_cat, ¡PAPI_L1_DCA|L1_lat|*|PAPI_L2_DCA|L2_lat| *|+|PAPI_L2_DCM|Mem_lat|*|+ ¡

13 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

System ¡constants ¡

• e.g., ¡Cache ¡and ¡memory ¡latencies ¡used ¡in ¡

event ¡defini5ons ¡

• Not ¡strictly ¡“constant” ¡ ¡upper ¡bounds ¡
• Some ¡obtained ¡from ¡architecture ¡manuals ¡
• We ¡provide ¡a ¡set ¡of ¡benchmarks ¡for ¡measuring ¡

constants ¡on ¡different ¡pladorms ¡and ¡maintain ¡ a ¡database ¡of ¡results. ¡

– LMBench ¡ – STREAM ¡

14 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

PerfExpert ¡example ¡ ¡

Event ¡defini5ons ¡for ¡AMD ¡Opteron ¡8358 ¡SE ¡processor ¡

¡ ¡ ¡ ¡ ¡ ¡Branch ¡category: ¡

¡ ¡ ¡ ¡ ¡(PAPI_BR_INS ¡* ¡BR_lat ¡+ ¡PAPI_BR_MSP ¡* ¡BR_miss_lat)/PAPI_TOT_INS ¡

¡ ¡ ¡ ¡ ¡ ¡Data ¡memory ¡access ¡category: ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡(PAPI_L1_DCA ¡* ¡Data_L1_lat ¡+ ¡PAPI_L2_DCA ¡* ¡L2_lat ¡+ ¡PAPI_L2_DCM ¡* ¡L3_lat ¡+ ¡ L3_CACHE_MISSES:READ_BLOCK_EXCLUSIVE ¡+ ¡Mem_lat)/PAPI_TOT_INS ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Instruc5on ¡memory ¡access ¡category: ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡(PAPI_L1_ICA ¡* ¡Instr_L1_lat ¡+ ¡PAPI_L2_ICA ¡* ¡L2_lat ¡+ ¡PAPI_L2_ICM ¡* ¡L3_lat ¡+ ¡ L3_CACHE_MISSES:READ_BLOCK_SHARED ¡* ¡Mem_lat)/PAPI_TOT_INS ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Data ¡TLB ¡access ¡category: ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡(PAPI_TLB_DM ¡* ¡Data_TLB_lat)/PAPI_TOT_INS ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Instruc5on ¡TLB ¡access ¡category: ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡(PAPI_TLB_IM ¡* ¡Instr_TLB_lat)/PAPI_TOT_INS ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Floa5ng-­‑point ¡instruc5on ¡category: ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡((PAPI_FML_INS ¡+ ¡PAPI_FAD_INS) ¡* ¡FP_add_sub_mul_lat ¡+ ¡(PAPI_FDV_INS ¡+ ¡PAPI_FSQ_INS) ¡* ¡ FP_div_sqrt_lat)/PAPI_TOT_INS ¡

15 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Machine ¡constants ¡for ¡AMD ¡Opteron ¡ 8358 ¡(in ¡cycles) ¡

L1 ¡data ¡cache ¡hit ¡latency ¡ 3 ¡ L1 ¡instruc5on ¡cache ¡hit ¡latency ¡ 2 ¡ L2 ¡cache ¡hit ¡latency ¡ 17 ¡ L3 ¡cache ¡hit ¡latency ¡ 60 ¡ Memory ¡access ¡latency ¡ 540 ¡ Branch ¡latency ¡ 2 ¡ Branch ¡mispredic5on ¡latency ¡ 12 ¡ Floa5ng-­‑point ¡add/sub/mul ¡latency ¡ 4 ¡ Floa5ng-­‑point ¡div/sqrt ¡latency ¡ 38 ¡ Data ¡TLB ¡miss ¡latency ¡ 50 ¡ Instruc5on ¡TLB ¡miss ¡latency ¡ 50 ¡

16 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

CPI ¡contribu5ons ¡of ¡instruc5on ¡categories ¡ for ¡HPCC ¡benchmarks ¡

Results ¡for ¡AMD ¡Opteron ¡8358 ¡8-­‑core ¡processor ¡

17 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Towards ¡Accurate ¡Cycle ¡Breakdown ¡ Models ¡using ¡Hardware ¡Counters ¡

• Need ¡counters ¡that ¡measure ¡memory ¡access ¡
• 5me. ¡
• Memory ¡access ¡5me ¡= ¡% ¡cache ¡hits ¡* ¡cache ¡

access ¡5me ¡+ ¡% ¡cache ¡misses ¡* ¡memory ¡load ¡ latency? ¡

– Not ¡necessarily ¡since ¡memory ¡latency ¡can ¡be ¡ hidden ¡in ¡out-­‑of-­‑order ¡superscalar ¡processors ¡ ¡

10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡ 18 ¡

Proposed ¡Effec5ve ¡Load ¡Latency ¡Counter ¡

• Define ¡a ¡load ¡as ¡a ¡read ¡that ¡results ¡in ¡a ¡last-­‑level ¡cache ¡
• miss. ¡
• Most ¡processors ¡use ¡write ¡buffers ¡so ¡write ¡miss ¡latency ¡is ¡

effec5vely ¡zero. ¡

• Load ¡begins ¡on ¡the ¡cycle ¡when ¡it ¡is ¡issued ¡and ¡completes ¡
• n ¡the ¡cycle ¡when ¡the ¡cache ¡line ¡has ¡been ¡transferred ¡from ¡
• memory. ¡ ¡

– Some ¡processors ¡already ¡implement ¡a ¡load ¡latency ¡counter. ¡ – But ¡we ¡only ¡want ¡to ¡count ¡load ¡latency ¡cycles ¡if ¡they ¡impact ¡ downstream ¡instruc5ons. ¡ – Count ¡cycles ¡while ¡instruc5ons ¡that ¡depend ¡on ¡load ¡instruc5on ¡ are ¡queued. ¡

10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡ 19 ¡

Regression-­‑based ¡Predic5on ¡using ¡ ¡ Hardware ¡Counters ¡

• Basic ¡regression ¡equa5on: ¡
• Procedure: ¡

– Select ¡the ¡set ¡of ¡counters ¡to ¡use ¡(e.g., ¡using ¡principal ¡ component ¡analysis) ¡ – Run ¡benchmarks ¡on ¡training ¡data ¡at ¡both ¡frequencies ¡ to ¡determine ¡regression ¡coefficients ¡ – Run ¡test ¡programs ¡at ¡t0 ¡and ¡use ¡regression ¡equa5on ¡to ¡ predict ¡execu5on ¡5me ¡at ¡tnew ¡

• Predic5on ¡error ¡typically ¡5-­‑15% ¡

– Affected ¡by ¡quality ¡of ¡training ¡data ¡

20 ¡

tnew t0 = ¡α0 ¡+ ¡α1* ¡HWC1 ¡+ ¡α2* ¡HWC2 ¡+ ¡. ¡. ¡. ¡

10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Modeling Methodology

• Application-centric models were used to explore common

and different characteristics of Hybrid (MPI/OpenMP) Scientific Applications

• Training Set: 5 training execution points.

– 1x1, 1x2, 1x3, 1x8, and 2x8

• 16 Larger execution points were predicted.

– 1x4, 1x5,…3x8, 4x8, 5x8, …..16x8

• 40 performance counter events were captured.

– Using PAPI and Perfmon Library

• Performance counter events were normalized per cycle.
• Performance-Tuned Supervised Principal Component

Analysis Method utilized to select combination of performance counters for each application

10/27/12 ¡ 21 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Performance-Tuned Supervised PCA

1. Compute Spearman’s rank correlation for each application and performance component. 2. Eliminate counters with low correlation. 3. Compute regression model based upon performance counter event rates. 4. Eliminate performance counters will negligible regression coefficients. 5. Compute principal components of reduced performance counter event rates. 6. Use the performance counters with highest PCA vectors to build multivariate linear regression model.

10/27/12 ¡ 22 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Applica5on-­‑specific ¡Power-­‑Performance ¡Models ¡

23 ¡ Lively, ¡Wu, ¡Taylor, ¡Moore, ¡Chang, ¡Su ¡and ¡Cameron, ¡Power-­‑Aware ¡Predic5ve ¡Models ¡of ¡Hybrid ¡(MPI/OpenMP) ¡ ¡ Scien5fic ¡Applica5ons ¡on ¡Mul5core ¡Systems, ¡EnA-­‑HPC2011, ¡Hamburg, ¡Germany, ¡Sept ¡2011. ¡ ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Predic5on ¡Accuracy ¡

24 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Recent ¡Publica5ons ¡

• Charles ¡Lively, ¡Xingfu ¡Wu, ¡Valerie ¡Taylor, ¡Shirley ¡Moore, ¡Hung-­‑Ching ¡Chang, ¡and ¡

Kirk ¡Cameron, ¡Energy ¡and ¡Performance ¡Characteris5cs ¡of ¡Different ¡Parallel ¡ Implementa5ons ¡of ¡Scien5fic ¡Applica5ons ¡on ¡Mul5core ¡Systems, ¡Interna2onal ¡ Journal ¡of ¡High ¡Performance ¡Compu2ng ¡Applica2ons ¡(IJHPCA), ¡Volume ¡25 ¡Issue ¡3, ¡ August ¡2011, ¡pp. ¡342 ¡-­‑ ¡350. ¡ ¡

• Charles ¡Lively, ¡Xingfu ¡Wu, ¡Valerie ¡Taylor, ¡Shirley ¡Moore, ¡Hung-­‑Ching ¡Chang, ¡Chun-­‑Yi ¡

Su ¡and ¡Kirk ¡Cameron, ¡Power-­‑Aware ¡Predic5ve ¡Models ¡of ¡Hybrid ¡(MPI/OpenMP) ¡ Scien5fic ¡Applica5ons ¡on ¡Mul5core ¡Systems, ¡Interna2onal ¡Conference ¡on ¡Energy-­‑ Aware ¡High ¡Performance ¡Compu2ng(EnA-­‑HPC2011), ¡Hamburg, ¡Germany, ¡ September ¡7-­‑9, ¡2011. ¡ ¡

• Kiran ¡Kasichayanula, ¡Daniel ¡Terpstra, ¡Piotr ¡Luszczek, ¡Stan ¡Tomov, ¡Shirley ¡Moore, ¡

and ¡Greg ¡Peterson. ¡Power ¡aware ¡compu5ng ¡on ¡GPUs. ¡Symposium ¡on ¡Applica2on ¡ Accelerators ¡in ¡High ¡Performance ¡Compu2ng ¡(SAAHPC ¡2012), ¡Argonne ¡Na5onal ¡ Laboratory, ¡July ¡10-­‑11, ¡2012. ¡ ¡

• Vince ¡Weaver, ¡Mamhew ¡Johnson, ¡Kiran ¡Kasichayanula, ¡James ¡Ralph, ¡Piotr ¡Luszczek, ¡

Daniel ¡Terpstra, ¡and ¡Shirley ¡Moore. ¡ ¡Measuring ¡energy ¡and ¡power ¡with ¡PAPI. ¡ ¡ Interna2onal ¡Workshop ¡on ¡Power-­‑Aware ¡Systems ¡and ¡Architectures ¡(PASA ¡2012), ¡ Pimsburgh, ¡PA, ¡September ¡10, ¡2012. ¡ ¡

• Shirley ¡Moore ¡and ¡James ¡Ralph. ¡User-­‑defined ¡events ¡for ¡hardware ¡performance ¡
• monitoring. ¡Interna2onal ¡Conference ¡on ¡Computa2onal ¡Science ¡(ICCS), ¡Singapore, ¡

June ¡2011. ¡

25 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

Future ¡Work ¡

• Explore use of microbenchmarks and application

classes to derive application-centric models

• Finer-granularity analysis of large-scale hybrid

scientific applications

– Do set of hardware counters and coefficients vary with application region?

• Modeling and prediction across different

application input sizes and frequency settings

– Can hardware counter measurements drive a dynamic frequency scaling strategy?

• More accurate cycle breakdown models

– Advantage: model doesn’t depend on training data – Potentially most accurate – May require counters that currently don’t exist

26 ¡ 10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡

10/27/12 ¡ 12th ¡UTEP/NMSU ¡Workshop ¡ 27 ¡

Ques5ons? ¡