XCHANGE¿PUEDE EL PUESTO DE FRUTA DEL MERCADO

AYUDAR A MI CPU?

José F. Martínez http://csl.cornell.edu/~martinez

Image: Britt Reints @ Wikimedia

XCHANGE

MY VERSION OF MOORE’S LAW

2• Motivation • Prior Art • Markets

Image: Greudin@Wikimedia

Image: Morio@Wikimedia

Moore’s Law

XCHANGE

MODERN PROCESSORS: A SILICON CITY

3

Image: Qualcomm

It’s not just “a processor”

Shared I/O pins

Heterogeneous processing

Shared on-chip power

• Motivation • Prior Art • Markets

Shared caches

Multicore

▪Your chip needs a townhall• And your chip is not a village▪Centralized solutions don’t scale▪Market-based framework very promising• Based on sound, proven theory; but practical• Fast, scalable, amenable to external tuning▪ Implementation: XChange• Self-optimizing, extensible

MANAGING YOUR CHIP’S RESOURCES

4

XCHANGE• Motivation • Prior Art • Markets

ANARCHY DOESN’T WORK

5

Crafty-Ammp-Apsi-Art

IPC

1.5

1.75

2

2.25

2.5

unregulated cache memory power cache_memory cache_power memory_power all

2.86%-0.44%

10.69%

-7.50%

-13.55%

XCHANGE

Wei

ghte

d Sp

eedu

p

• Motivation • Prior Art • Markets

MANAGING RESOURCES: CENTRALIZED DOESN’T SCALE

6

Image: Choi and Yeung, ISCA ‘06

Sampling + hill-climbing

XCHANGE• Motivation • Prior Art • Markets

Search overhead too large: Not scalable

MANAGING RESOURCES: CENTRALIZED DOESN’T SCALE

7

Image: Bitirgen et al., MICRO ‘08

Hardware acceleration

XCHANGE

Search still centralized and sequential

• Motivation • Prior Art • Markets

WHAT “WORKS”? A CUE FROM REAL LIFE

8

▪Compromise global optimality for simplicity• Pursue absolute optimum is very expensive• Optimal outcome is not practical• Simple, distributed mechanisms can be reasonably good

XCHANGE• Prior Art • Markets • Utility

Image:Mariordo@Wikimedia

A CUE FROM REAL LIFE: MARKET-BASED SOCIETIES

9

▪Participants try to maximize their own utilities▪Selfish behavior still benefits social welfare▪ (Largely) distributed solution → scalable

“It is not from the benevolence of the butcher, the brewer, or the baker, that we expect our dinner, but from their regard to their own interest.”

Adam Smith, “The Wealth of Nations”

XCHANGE• Prior Art • Markets • Utility

Image: 663highland@Wikimedia

▪Concept: “Competitive market”• Players have finite budgets• Prices are posted, same to all players• Players are price-takers: no monopolistic behavior• Non-satiation: Can always take more (*)

▪Concept: “Competitive market equilibrium”• Prices are such that supply = demand

A PEEK INTO MARKET THEORY

10

XCHANGE

(*) Strictly speaking this is monotonicity of preferences (stronger)

• Prior Art • Markets • Utility

FIRST WELFARE THEOREM

11

▪Concept: “Pareto optimality”• An allocation is Pareto-optimal if there is no way to

reallocate goods so that someone is made better off without making someone else worse off• Caveat: Pareto-optimal not necessarily perfect• But much faster to reach (see results)

▪ First welfare theorem• Any competitive market equilibrium is Pareto-optimal

XCHANGE• Prior Art • Markets • Utility

▪ 1: Market side• How does one set prices to satisfy demand?

▪Price-taking heuristic (F. Kelly)

XCHANGE: MARKET CHALLENGES

12

XCHANGE• Prior Art • Markets • Utility

pricej =bidi ' ji '∑

total _resourcejresourceij =

bidijpricej

▪ 2: Agent side• How do I maximize my bang-for-buck resource-wise?

▪Utility estimation• Agents concurrently “discover” their own utility• Analytical models• Learning models• Heuristics (see XChange, HPCA’15)• t ∝ f(cpuapp,memapp) ∝ f(freqapp,cacheapp)• Infer t’ for (freqapp’,cacheapp’)

XCHANGE: MARKET CHALLENGES

13

XCHANGE• Prior Art • Markets • Utility

A SIMPLE HEURISTIC UTILITY MODEL

▪Memory phase• Cache: Proportional to memory phase• Combine Miftakhutdinov + UMON

14

XCHANGE

Assume constant across allocations

Miftakhutdinov

• Markets • Utility • Practical Issues

A SIMPLE HEURISTIC UTILITY MODEL

▪Compute phase• Power: Assume compute phase ~linear to f

15

XCHANGE

Measured (perf. counters)

Miftakhutdinov

• • Markets • Utility • Practical Issues

0

▪Convergence• Detected through price fluctuation (<1%)• Price smoothing: Avoid ping-pong by incorporating

memory in pricing mechanism• Fall back to equal-share after 30 iterations▪Bankruptcy• Everything is too expensive• Guarantee one-way cache and 800 MHz operation• Exclude from market for one interval

PRACTICAL ISSUES

16

XCHANGE• Utility • Practical Issues • Results

▪ “Rigging” the market

• Performance-oriented: Give more budget to app with more potential for gain• Internally derived, e.g., calculate for min/max resource

allocation

• Mission-oriented: Give more budget to more critical app • Externally derived, e.g., application feedback

• Fairness-oriented: Give same budget to everyone

XCHANGE: WEALTH REDISTRIBUTION

17

XCHANGE• Utility • Practical Issues • Results

▪Leverage Linux’s APIC timer interrupt• Every 1 ms, for kernel statistics update• Designate “master core” to post prices, collect bids

▪Modest hardware overhead• ~ 4 kB/core (mostly Qureshi & Patt’s UMON)

XCHANGE: IMPLEMENTATION

18

XCHANGE• Utility • Practical Issues • Results

▪Pretty much out of the window• Utility function approximation at best• Based on architecture heuristics

• Bidding search not exhaustive• Predictive: past history = future performance▪Nevertheless, reason for optimism• Plenty of real-life examples that just work• We want something “better”• Perfect is the enemy of Good

• We have reasonable fallback mechanism

WAIT—WHAT ABOUT THEORETICAL GUARANTEES?

19

XCHANGE• Utility • Practical Issues • Results

EXPERIMENTAL SETUP

20

XCHANGE• Practical Issues • Results • Conclusions

XCHANGE: 64-CORE RESULTS (SEE HPCA’15)

21• Practical Issues • Results • Conclusions

XCHANGE

XCHANGE: OVERHEAD (SEE HPCA’15)

22• Practical Issues • Results • Conclusions

5M-cycle intervals

XCHANGE

▪Market-based framework very promising• Based on sound theory; but practical• Fast, scalable, amenable to external tuning▪Ongoing work• Tunable markets (see ReBudget, ASPLOS’16)• Minimalistic hardware solutions• Market ensembles

TAKEAWAYS

23

XCHANGE• Practical Issues • Results • Conclusions