• No results found

Erik Hagersten

N/A
N/A
Protected

Academic year: 2022

Share "Erik Hagersten"

Copied!
103
0
0

Loading.... (view fulltext now)

Full text

(1)

Memory Technology

Erik Hagersten

Uppsala University, Sweden

eh@it.uu.se

(2)

AVDARK

Main memory characteristics

DRAM:

 Main memory is built from DRAM: Dynamic RAM

 1 transistor/bit ==> more error prone and slow

 Refresh and precharge crazy stuff

 ¨

SRAM

 Cache memory is built from SRAM: Static RAM

 about 4-6 transistors/bit  fast but less capacity

(3)

Mem, VM and SW optimizations3 AVDARK

2012

DRAM organization

4Mbit memory array One bit memory cell

Bit line Word line

Capacitance

R o w d ec o d er

RAS

Address

11

(4) Data

out

Column decoder CAS Column latch

20482048 cell matrix

 The address is multiplexed Row/Address Strobe (RAS/CAS)

 “Thin” organizations (between x16 and x1) to decrease pin load

 Refresh of memory cells decreases bandwidth

 Bit-error rate creates a need for error-correction (ECC)

(4)

AVDARK

SRAM organization

Ro w d e co d er

Column decoder 5125124

cell matrix In buffer

D iff. -a m p lif ye r

A

1

A

2

A

3

A

4

A

5

A

6

A

7

A

8

A

9

A

0

A

10

A

11

A

12

A

13

A

14

A

15

A

16

A

17

I/O

3

I/O

2

I/O

1

I/O

0

CE WE O E

 Address is typically not multiplexed

 Each cell consists of about 4-6 transistors

 Wider organization (x18 or x36), typically few chips

Often parity protected (ECC becoming more common)

(5)

Mem, VM and SW optimizations5 AVDARK

2012

Error Detection and Correction

Error-correction and detection

 E.g., 64 bit data protected by 8 bits of ECC

 Protects DRAM and high-availability SRAM applications

 Double bit error detection (”crash and burn” )

 Chip kill detection (all bits of one chip stuck at all-1 or all-0)

 Single bit correction

 Need “memory scrubbing” in order to get good coverage

Parity

 E.g., 8 bit data protected by 1 bit parity

 Protects SRAM and data paths

 Single-bit ”crash and burn” detection

 Not sufficient for large SRAMs today!!

(6)

AVDARK

Correcting the Error

 Correction on the fly by hardware

 no performance-glitch

 great for cycle-level redundancy

 fixes the problem for now…

 Trap to software

 correct the data value and write back to memory

 Memory scrubber

 kernel process that periodically touches all of memory

(7)

Mem, VM and SW optimizations7 AVDARK

2012

Improving main memory performance

 Page-mode => faster access within a small distance

 Improves bandwidth per pin -- not time to critical word

 Single wide bank improves access time to the complete CL

 Multiple banks improves bandwidth

(8)

AVDARK

Newer kind of DRAM...

 SDRAM (5-1-1-1 @100 MHz)

 Mem controller provides strobe for next seq. access

 DDRx-DRAM (e.g., 5-½-½-½)

 Transfer data on both edges of the clock

Research:

 CPU and DRAM on the same chip?? (IMEM)...

(9)

Mem, VM and SW optimizations9 AVDARK

2012

Newer DRAMs …

(Several DRAM arrays on a die)

Name Clock rate

(MHz) BW

(GB/s per DIMM)

DDR-260 133 2,1

DDR-300 150 2,4

DDR2-533 266 4,3

DDR2-800 400 6,4

DDR3-1066 533 8,5

DDR3-1600 800 12,8

(10)

AVDARK

Modern

DRAM (1)

(11)

Mem, VM and SW optimizations11 AVDARK

2012

Timing ”page hit”

Figure 6. Page-hit timing (with precharge and subsequent bank access) From AnandTech:

Everything You Always Wanted to Know About SDRAM: But Were Afraid to Ask

http://www.anandtech.com/show/3851/everything-you-always-wanted-to-know-about-sdram-memory-but-were-afraid-to-ask

(12)

AVDARK

Figure 8. Page-miss timing From AnandTech:

Timing ”page miss”

(13)

Mem, VM and SW optimizations13 AVDARK

2012

The Endian Mess

Big Endian

Little Endian

00 00 00 5f

lsb msb

0

64MB

00 00 00 5f

lsb msb

0

64MB

Store the value 0x5F

o H e l l

lsb msb

0

64MB

l l e H o

lsb msb

0

64MB

Store the string Hello

4 5 6 7 0 1 2 3

lsb msb

0

64MB

7 6 5 4 3 2 1 0

lsb msb

0

64MB

Numbering the bytes

Word

(14)

Virtual Memory System

Erik Hagersten

Uppsala University, Sweden

eh@it.uu.se

(15)

Mem, VM and SW optimizations15 AVDARK

2012

Physical Memory

Physical Memory

Disk

0

64MB

PROGRAM

(16)

AVDARK

Virtual and Physical Memory

0

4GB text heap

data stack

Context A 0

4GB text heap

data stack

Context B

Physical Memory

Disk

0

64MB

Segments

PROGRAM

$1 $2

(Caches)

(17)

Mem, VM and SW optimizations17 AVDARK

2012

Translation & Protection

0

4GB text heap

data

Context A

0

4GB text heap

data

Context B

Physical Memory

Disk

0

64MB R R RW

RW

stack stack

Virtual Memory

(18)

AVDARK

Virtual memory — parameters

Compared to first-level cache parameters

Parameter First-level cache Virtual memory Block (page) size 16-128 bytes 4K-64K bytes Hit time 1-2 clock cycles 40-100 clock cycles

Miss penalty (Access time) (Transfer time)

8-100 clock cycles (6-60 clock cycles) (2-40 clock cycles)

700K-6000K clock cycles (500K-4000K clock cycles) (200K-2000K clock cycles)

Miss rate 0.5%-10% 0.00001%-0.001%

Data memory size 16 Kbyte - 1 Mbyte 16 Mbyte - 8 Gbyte

 Replacement in cache handled by HW. Replacement in VM handled by SW

 VM hit latency very low (often zero cycles)

 VM miss latency huge (several kinds of misses)

 Allocation size is one ”page” 4kB and up)

(19)

Mem, VM and SW optimizations19 AVDARK

2012

VM: Block placement

Where can a block (page) be placed in main memory?

What is the organization of the VM?

 The high miss penalty makes SW solutions to implement a fully associative address mapping feasible at page faults

 A page from disk may occupy any pageframe in PA

 Some restriction can be helpful (page coloring)

(20)

AVDARK

VM: Block identification

Use a page table stored in main

memory:  Suppose 8 Kbyte pages, 48 bit virtual address

 Page table occupies

2 48 /2 13 * 4B = 2 37 = 128GB!!!

Solutions:

 Only one entry per

physical page is needed

 Multi-level page table (dynamic)

 Inverted page table

(~hashing)

(21)

Mem, VM and SW optimizations21 AVDARK

2012

kseg

Address translation

Multi-level table: The Alpha 21064 (

seg1

seg0 seg1

seg0 seg1

seg0

Kernel segment Used by OS.

Does not use virtual memory.

User segment 1 Used for stack.

User segment 0 Used for instr. &

static data &

heap Segment is selected

by bit 62 & 63 in addr.

PTE

Page Table Entry:

(translation & protection)

(22)

AVDARK

Protection mechanisms

The address translation mechanism can be used to provide memory protection:

Use protection attribute bits for each page

Stored in the page table entry (PTE) (and TLB…)

Each physical page gets its own per process protection

Violations detected during the address

translation cause exceptions (i.e., SW trap)

Supervisor/user modes necessary to prevent

user processes from changing e.g. PTEs

(23)

Mem, VM and SW optimizations23 AVDARK

2012

Fast address translation

How can we avoid three extra memory references for each original memory reference?

 Store the most commonly used address translations in a cache—Translation Look-aside Buffer (TLB)

==> The caches rears their ugly faces again!

P TLB

lookup

Cache Main

memory

VA PA

Transl.

in mem

Data

Addr

(24)

AVDARK

Do we need a fast TLB?

 Why do a TLB lookup for every L1 access?

 Why not cache virtual addresses instead?

 Move the TLB on the other side of the cache

 It is only needed for finding stuff in Memory anyhow

 The TLB can be made larger and slower – or can it?

P TLB

lookup

Cache Main

memory

VA PA

Transl.

in mem

(25)

Mem, VM and SW optimizations25 AVDARK

2012

Aliasing Problem

The same physical page may be accessed using different virtual addresses

 A virtual cache will cause confusion -- a write by one process may not be observed

 Flushing the cache on each process switch is slow (and may only help partly)

 =>VIPT (VirtuallyIndexedPhysicallyTagged) is the answer

 Direct-mapped cache no larger than a page

 No more sets than there are cache lines on a page + logic

 Page coloring can be used to guarantee correspondence

between more PA and VA bits (e.g., Sun Microsystems)

(26)

AVDARK

Virtually Indexed Physically Tagged

=VIPT

 Have to guarantee that all aliases have the same index

 L1_cache_size < (page-size * associativity)

 Page coloring can help further

P TLB

lookup Cache

Main memory

VA

PA

Transl.

in mem Data

Index PA Addr tag =

Hit

(27)

Mem, VM and SW optimizations27 AVDARK

2012

Putting it all together: VIPT

Cache: 8kB, 2-way, CL=32B, word=4B, page =4kB TLB: 32 entries, 2-way

(4B)

1

Data 01001100001010010100110101000110

128

(7)

0101001

0010011100101

Identifies a byte within a word

Multiplexer (16:1 mux) Identifies the word within a cache line

(32B) (32B)

1 0101001

0010011100101

msb lsb

0101001 PTE

1 1

0101001 PTE

16

2:1 mux

=

&

=

&

logic

=

&

=

&

logic

(1)

same for PA & VA

(16) (4) TLB

Cache

TLB hit Cache hit

PA-TAG (20)

PA addr bit [31-12] (20) VA-TAG (16)

VA-address:

PA-Page frame (20)

(3)

(20)

(28)

AVDARK

What is the capacity of the TLB

Typical TLB size = 0.5 - 2kB

Each translation entry 4 - 8B ==> 32 - 500 entries

Typical page size = 4kB - 16kB TLB-reach = 0.1MB - 8MB

FIX:

Multiple page sizes, e.g., 8kB and 8 MB

TSB -- A direct-mapped translation in

memory as a “second-level TLB”

(29)

Mem, VM and SW optimizations29 AVDARK

2012

VM: Page replacement

Most important: minimize number of page faults

Page replacement strategies:

 FIFO—First-In-First-Out

 LRU—Least Recently Used

 Approximation to LRU

 Each page has a reference bit that is set on a reference

 The OS periodically resets the reference bits

 When a page is replaced, a page with a reference bit that is not

set is chosen

(30)

AVDARK

So far…

Data L1$

Unified L2$

CPU

Memory

D D D D

D D D

I

D D D

D D

I I I I TLB miss TLB

(transl$) TLB

fill

PT PT PT PT

PT PT TLB fill

PF handler

I Page

fault

D

Disk

(31)

Mem, VM and SW optimizations31 AVDARK

2012

Adding TSB (software TLB cache)

TLBD Atrans$

TLB fill

PF handler

PT PT PT PT

PT PT

D D D D

D D D

I

D D D

D D

I I I I I

Data Page L1$

fault

TLB miss

Unified L2$

D

CPU

Memory Disk

TSB

TLB fill

(32)

AVDARK

VM: Write strategy

Write back!

 Write through is impossible to use:

 Too long access time to disk

The write buffer would need to be prohibitively large

 The I/O system would need an extremely high bandwidth

Write back or Write through?

(33)

Mem, VM and SW optimizations33 AVDARK

2012

VM dictionary

Virtual Memory System The “cache” languge Virtual address ~Cache address

Physical address ~Cache location

Page ~Huge cache block

Page fault ~Extremely painfull $miss Page-fault handler ~The software filling the $

Page-out Write-back if dirty

(34)

AVDARK

Caches Everywhere…

 D cache

 I cache

 L2 cache

 L3 cache

 ITLB

 DTLB

 TSB

 Virtual memory system

 Branch predictors

 Directory cache

(35)

Exploring the Memory of a Computer System

Erik Hagersten

Uppsala University, Sweden

eh@it.uu.se

(36)

AVDARK

Micro Benchmark Signature

for (times = 0; times < Max; times++) /* many times*/

for (i=0; i < ArraySize; i = i + Stride)

dummy = A[i]; /* touch an item in the array */

Measuring the averge access time to memory, while varying ArraySize and Stride, will allow us to reverse-engineer the memory system.

(need to turn off HW prefetching...)

(37)

Mem, VM and SW optimizations37 AVDARK

2012

Micro Benchmark Signature

for (times = 0; times < Max; times++) /* many times*/

for (i=0; i < ArraySize; i = i + Stride)

dummy = A[i]; /* touch an item in the array */

  

 

 

 

Time (ns)

Stride (bytes)

   

   

  

   

  

 

   

 

    

      

 

          

4 16 64 256 1 K 4 K 16 K 64 K 256 K 1 M 4 M

0 100 200 300 400 500 600 700

 

 

  

  

 

 

   

  

 

 

 

 

 

 

 

 



 8 M

 4 M

 2 M

 1 M

 512 K 256 K

 128 K

 64 K 32 K 16 K

Stride(bytes)

Av g t im e (n s)

(38)

AVDARK

Stepping through the array

for (times = 0; times < Max; times++) /* many times*/

for (i=0; i < ArraySize; i = i + Stride)

dummy = A[i]; /* touch an item in the array */

0 Array Size = 16, Stride=4

0 Array Size = 32, Stride=4…

0 Array Size = 16, Stride=8…

(39)

Mem, VM and SW optimizations39 AVDARK

2012

Micro Benchmark Signature

for (times = 0; times < Max; time++) /* many times*/

for (i=0; i < ArraySize; i = i + Stride)

dummy = A[i]; /* touch an item in the array */

  

 

 

 

 

 

Time (ns)

Stride (bytes)

   

   

  

   

  

 

   

 

    

      

 

          

4 16 64 256 1 K 4 K 16 K 64 K 256 K 1 M 4 M

0 100 200 300 400 500 600 700

 

 

  

  

 

 

   

  

 

 

 

 

 

 

 

 



 8 M

 4 M

 2 M

 1 M

 512 K 256 K

 128 K

 64 K 32 K 16 K

ArraySize=8MB

ArraySize=512kB

ArraySize=32-256kB ArraySize=16kB

Stride(bytes)

Av g t im e (n s)

(40)

AVDARK

Micro Benchmark Signature

for (times = 0; times < Max; time++) /* many times*/

for (i=0; i < ArraySize; i = i + Stride)

dummy = A[i]; /* touch an item in the array */

  

 

 

 

 

 

Time (ns)

Stride (bytes)

   

   

  

   

  

 

   

 

    

      

 

          

4 16 64 256 1 K 4 K 16 K 64 K 256 K 1 M 4 M

0 100 200 300 400 500 600 700

 

 

  

  

 

 

   

  

 

 

 

 

 

 

 

 



 8 M

 4 M

 2 M

 1 M

 512 K 256 K

 128 K

 64 K 32 K 16 K

ArraySize=8MB

ArraySize=512kB

ArraySize=32kB-256kB ArraySize=16kB

L1$ hit

L2$hit=40ns Mem=300ns

Mem+TLBmiss

L2$ block Page L1$ block

L2$+TLBmiss

(41)

Mem, VM and SW optimizations41 AVDARK

2012

Twice as large L2 cache ???

for (times = 0; times < Max; time++) /* many times*/

for (i=0; i < ArraySize; i = i + Stride)

dummy = A[i]; /* touch an item in the array */

  

 

 

 

 

 

Time (ns)

Stride (bytes)

   

   

  

   

  

 

   

 

    

      

 

          

4 16 64 256 1 K 4 K 16 K 64 K 256 K 1 M 4 M

0 100 200 300 400 500 600 700

 

 

  

  

 

 

   

  

 

 

 

 

 

 

 

 



 8 M

 4 M

 2 M

 1 M

 512 K 256 K

 128 K

 64 K 32 K 16 K

ArraySize=8MB

ArraySize=512kB

ArraySize=32-256kB ArraySize=16kB

Stride(bytes)

Av g t im e (n s)

ArraySize=1M

(42)

AVDARK

Twice as large TLB…

for (times = 0; times < Max; time++) /* many times*/

for (i=0; i < ArraySize; i = i + Stride)

dummy = A[i]; /* touch an item in the array */

  

 

 

 

 

 

Time (ns)

   

   

  

   

  

 

   

 

    

      

 

          

4 16 64 256 1 K 4 K 16 K 64 K 256 K 1 M 4 M

0 100 200 300 400 500 600 700

 

 

  

  

 

 

   

  

 

 

 

 

 

 

 

 



 8 M

 4 M

 2 M

 1 M

 512 K 256 K

 128 K

 64 K 32 K 16 K

ArraySize=8MB

ArraySize=512kB

ArraySize=32-256kB ArraySize=16kB

Av g t im e (n s)

ArraySize=1MB

(43)

Optimizing for Cache/Memory

Erik Hagersten

Uppsala University, Sweden

eh@it.uu.se

(44)

AVDARK

Optimizing for the memory system:

What is the potential gain?

 Latency difference L1$ and mem: ~50x

 Bandwidth difference L1$ and mem: ~20x

 Execute from L1$ instead from mem ==>

50-150x improvement

 At least a factor 2-4x is within reach

(45)

Mem, VM and SW optimizations45 AVDARK

2012

Optimizing for cache performance

 Keep the active footprint small

 Use the entire cache line once it has been brought into the cache

 Fetch a cache line prior to its usage

 Let the CPU that already has the data in its cache do the job

 ...

(46)

AVDARK

Final cache lingo slide

Miss ratio: What is the likelihood that a memory access will miss in a cache?

Miss rate: D:o per time unit, e.g. per-second, per- 1000-instructions

Fetch ratio/rate*): What is the likelihood that a memory access will cause a fetch to the cache

[including HW prefetching]

Fetch utilization*): What fraction of a cacheline was used before it got evicted

Writeback utilization*): What fraction of a

cacheline written back to memory contains dirty data

Communication utilization*): What fraction of a communicated cacheline is ever used?

*) This is Acumem-ish language

(47)

Mem, VM and SW optimizations47 AVDARK

2012

What can go Wrong?

A Simple Example…

N

N

Perform a diagonal copy 10 times

(48)

AVDARK

Example: Loop order

//Optimized Example A for (i=1; i<N; i++) {

for (j=1; j<N; j++) { A[i][j]= A[i-1][j-1];

} }

//Unoptimized Example A for (j=1; j<N; j++) {

for (i=1; i<N; i++) { A[i][j] = A[i-1][j-1];

} }

?

(49)

Mem, VM and SW optimizations49 AVDARK

2012

0 2 4 6 8 10 12 14 16 18 20

16 32 64 128 256 512 102 4

20 48

409 6 Array side

S p e e dup v s U n Opt

Athlon64 x2 Pentium D Core 2 Duo

Performance Difference:

Loop order

Demo Time!

ThreadSpotter

(50)

AVDARK

0 1 2 3 4

1 2 3 4

2.7x

App: LBM

Performance

Example 1: The Same Application Optimized

Optimization can be rewarding, but costly…

 Require expert knowledge about MC and architecture

 Weeks of wading through performance data

#cores

Demo Time!

LBM:

Original code

(51)

Mem, VM and SW optimizations51 AVDARK

2012

Example: Sparse data usage

//Optimized Example A for (i=1; i<N; i++) {

for (j=1; j<N; j++) {

A_d[i][j]= A_d[i-1][j-1];

} }

//Unoptimized Example A for (i=1; i<N; i++) {

for (j=1; j<N; j++) { A[i][j].d = A[i-1][j-1].d;

} }

d d d d d d d d

struct vec_type {

char a;

char b;

char c;

char d;

};

(52)

AVDARK

Performance Difference:

Sparse Data

0 2 4 6 8 10 12 14 16

16 32 64 128 256 512 102 4

204 8 409 6 Array side

S p e e dup v s U n O P T Athlon64 x2

Pentium D

Core 2 Duo

(53)

Mem, VM and SW optimizations53 AVDARK

2012

0 5 10 15 20 25 30

1 2 3 4

Original Optimized

#Cores

7.3x

App: Cigar

Performance

Example 2: The Same Application Optimized

Looks like a perfect scalable application!

Are we done?

 Duplicate one data structure

Demo Time!

Cigar

Original code

(54)

AVDARK

Example: Sparse data allocation

d d d d struct sparse_rec

{

// size 80B char a;

double f1;

char b;

double f2;

char c;

double f3;

char d;

double f4;

char e;

double f5;

};

sparse_rec sparse [HUGE];

for (int j = 0; j < HUGE; j++) {

sparse[j].a = 'a'; sparse[j].b = 'b'; sparse[j].c = 'c'; sparse[j].d = 'd'; sparse[j].e = 'e';

sparse[j].f1 = 1.0; sparse[j].f2 = 1.0; sparse[j].f3 = 1.0; sparse[j].f4 = 1.0; sparse[j].f5 = 1.0;

}

struct dense_rec {

//size 48B double f1;

double f2;

double f3;

double f4;

double f5;

char a;

char b;

char c;

char d;

char e;

};

(55)

Mem, VM and SW optimizations55 AVDARK

2012

Loop Merging

/* Unoptimized */

for (i = 0; i < N; i = i + 1) for (j = 0; j < N; j = j + 1)

a[i][j] = 2 * b[i][j];

for (i = 0; i < N; i = i + 1) for (j = 0; j < N; j = j + 1)

c[i][j] = K * b[i][j] + d[i][j]/2

/* Optimized */

for (i = 0; i < N; i = i + 1) for (j = 0; j < N; j = j + 1)

a[i][j] = 2 * b[i][j];

c[i][j] = K * b[i][j] + d[i][j]/2;

(56)

AVDARK

Padding of data structures

j

i

256

256

?

A

A+256*8 A+256*2*8 Cacheline:

Generic Cache:

Addr [63..0]

MSB LSB

=

...

= = = = =

= =

mux Sel way ”6” Hit

index

SRAM:

(57)

Mem, VM and SW optimizations57 AVDARK

2012

Padding of data structures

j

i

256+padding

256

?

j

A

A+256*8+padding A+256*2*8+2*padding

allocate more memory than needed Cacheline:

Generic Cache:

Addr [63..0]

MSB LSB

=

...

= = = = =

= = Sel way ”6” Hit

index

SRAM:

(58)

AVDARK

Blocking

/* Unoptimized ARRAY: x = y * z */

for (i = 0; i < N; i = i + 1) for (j = 0; j < N; j = j + 1)

{r = 0;

for (k = 0; k < N; k = k + 1) r = r + y[i][k] * z[k][j];

x[i][j] = r;

};

j

i

X: k

i

Y: j

k

Z:

(59)

Mem, VM and SW optimizations59 AVDARK

2012

Blocking

/* Optimized ARRAY: X = Y * Z */

for (jj = 0; jj < N; jj = jj + B) for (kk = 0; kk < N; kk = kk + B) for (i = 0; i < N; i = i + 1)

for (j = jj; j < min(jj+B,N); j = j + 1) {r = 0;

for (k = kk; k < min(kk+B,N); k = k + 1) r = r + y[i][k] * z[k][j];

x[i][j] += r;

};

j

i

X: k

i

Y: j

k Z:

First block

Second block

Partial solution

(60)

AVDARK

Blocking: the Movie!

/* Optimized ARRAY: X = Y * Z */

for (jj = 0; jj < N; jj = jj + B) /* Loop 5 */

for (kk = 0; kk < N; kk = kk + B) /* Loop 4 */

for (i = 0; i < N; i = i + 1) /* Loop 3 */

for (j = jj; j < min(jj+B,N); j = j + 1) /* Loop 2 */

{r = 0;

for (k = kk; k < min(kk+B,N); k = k + 1) /* Loop 1 */

r = r + y[i][k] * z[k][j];

x[i][j] += r;

};

i X:

i Y:

k Z:

1

1 1

First block

Second block

Partial solution

2

kk+B kk

3 3

kk kk+B

4 5

jj+B 2

jj jj+B

jj

5 4

(61)

Mem, VM and SW optimizations61 AVDARK

2012

SW Prefetching

/* Unoptimized */

for (j = 0; j < N; j++) for (i = 0; i < N; i++)

x[j][i] = 2 * x[j][i];

/* Optimized */

for (j = 0; j < N; j++) for (i = 0; i < N; i++)

PREFETCH x[j+1][i]

x[j][i] = 2 * x[j][i];

(Typically, the HW prefetcher will successfully prefetch sequential

streams)

(62)

AVDARK

Cache Waste

/* Unoptimized */

for (s = 0; s < ITERATIONS; s++){

for (j = 0; j < HUGE; j++)

x[j] = x[j+1]; /* will hog the cache but not benefit*/

for (i = 0; i < SMALLER_THAN_CACHE; i++)

y[i] = y[i+1]; /* will be evicted between usages /*

}

/* Optimized */

for (s = 0; s < ITERATIONS; s++){

for (j = 0; j < HUGE; j++) {

PREFETCH_NT x[j+1] /* will be installed in L1, but not L3 (AMD) */

x[j] = x[j+1];

for (i = 0; I < SMALLER_THAN_CACHE; i++)

y[i] = y[i+1]; /* will always hit in the cache*/

}

(63)

Mem, VM and SW optimizations63 AVDARK

2012

Categorize and avoiding cache waste

Miss rate

$-size

∆ benefit Cache

hogging

L2 CPU L1

L1

CPU L1 L2 Mem

No point in caching!

 per-instruction cache avoidence

Hogging

∆ benefit

Don’t care

Slows others Slowed

by others Slows &

slowed

Hogging

∆ benefit

+ + +

+

bzip LBM

LQ

+ + +

+ +

0 0,2 0,4 0,6 0,8 1 1,2

bzip2 Libquantum LBM Geom mean

Individually In mix In mix, patched

25%

P e rf ormance

Andreas Sandberg, David Eklov and Erik Hagersten. Reducing Cache Pollution

Through Detection and Elimination of Non- Temporal Memory Accesses, In Proceedings of Supercomputing (SC), New Orleans, LA, USA, November 2010.

Automatic ”taming” of the hoggers

Application classification

(64)

AVDARK

cache size cache misses

actual actual/4

The larger cache, the better

Example: Hints to avoid cache pollution (non-temporal prefetches)

Hint:

Don’t allocate!

missrate 2x missrate

0 1 2 3

Original Lim=1.7MB

One Instance Four Instances

40% faster

Hint: 

Orig

Thr o ughput

(65)

Mem, VM and SW optimizations65 AVDARK

2012

Some performance tools

Free licenses

 Oprofile

 GNU: gprof

 AMD: code analyst

 Google performance tools

 Virtual Inst: High Productivity Supercomputing (http://www.vi-hps.org/tools/)

Not free

 Intel: Vtune and many more

 ThreadSpotter (of course )

 HP: Multicore toolkit (some free, some not)

(66)

Commercial Break:

ThreadSpotter

Erik Hagersten

Uppsala University, Sweden

eh@it.uu.se

(67)

Mem, VM and SW optimizations67 AVDARK

2012

ThreadSpotter™

/* Unoptimized Array Multiplication: x = y * z N = 1024 */

for (i = 0; i < N; i = i + 1) for (j = 0; j < N; j = j + 1)

{r = 0;

for (k = 0; k < N; k = k + 1) r = r + y[i][k] * z[k][j];

x[i][j] = r;

}

/* Unoptimized Array Multiplication: x = y * z N = 1024 */

for (i = 0; i < N; i = i + 1) for (j = 0; j < N; j = j + 1)

{r = 0;

for (k = 0; k < N; k = k + 1) r = r + y[i][k] * z[k][j];

x[i][j] = r;

}

Any Compiler

Binary

n

Sampler Finger Print

(~4MB)

Host System

Source:

C, C++, Fortran, OpenMP…

Mission:

Find the SlowSpots™

Asses their importance

Enable for non-experts to fix them

Improve the productivity of performance experts

(68)

AVDARK

Mission:

Find the SlowSpots™

Asses their importance

Enable for non-experts to fix them

Improve the productivity of performance experts

/* Unoptimized Array Multiplication: x = y * z N = 1024 */

for (i = 0; i < N; i = i + 1) for (j = 0; j < N; j = j + 1)

{r = 0;

for (k = 0; k < N; k = k + 1) r = r + y[i][k] * z[k][j];

x[i][j] = r;

}

/* Unoptimized Array Multiplication: x = y * z N = 1024 */

for (i = 0; i < N; i = i + 1) for (j = 0; j < N; j = j + 1)

{r = 0;

for (k = 0; k < N; k = k + 1) r = r + y[i][k] * z[k][j];

x[i][j] = r;

}

Any Compiler

Binary

n

Sampler Finger Print

(~4MB)

Source:

C, C++, Fortran...

How?

What?

Where?

n

Analysis

Target System

n

Advice

(69)

Mem, VM and SW optimizations69 AVDARK

2012

A One-Click Report Generation

(Limit, if you like, data gathered here, e.g., start gathering after after 10 sec. and stop after 10 sec.) Input arguments

Application to run

Working dir (where to run the app)

Cache size of the target system for optimization (e.g., L1 or L2 size)

Fill in the following fields:

Click this button

to create a report

(70)

AVDARK

Predicted fetch rate (if utilization  100%)

Cache size

Miss rate

Fetch rate Cache utilization ≈ Fraction of cache data utilized

(71)

Mem, VM and SW optimizations71 AVDARK

2012

Cache size to optimize for

(72)

AVDARK

List of bad loops

Spotting the crime

Explaining what to do

Loop Focus Tab

(73)

Mem, VM and SW optimizations73 AVDARK

2012

List of Bandwidth SlowSpots

Bandwidth Focus Tab

Spotting the crime

Explaining what to do

(74)

AVDARK

Resource Sharing Example

Libquantum

A quantum computer simulation

Widely used in research (download from: http://www.libquantum.de/ ) 4000+ lines of C, fairly complex code.

Runs an experiment in ~30 min

Throughput improvement:

0 0,5 1 1,5 2

1 2 3 4

Re la ti v e T h ro u ghp ut

(75)

Mem, VM and SW optimizations75 AVDARK

2012

Utilization Analysis

SlowSpotter’s First Advice: Improve Utilization

Change one data structure

 Involves ~20 lines of code

 Takes a non-expert 30 min

Libquantum

Predicted fetch rate if utilization = 100%

Fetch rate

Cache utilization ≈ Fraction of cache data utilized

Original Code

data 0 status 0 data 1 status 1 data 2 status 2 data 3 status 3

Cache size

record

Only accessing status data in main loop

Need 32 MB per thread!

1.3%

(76)

AVDARK

Utilization Analysis

Libquantum

Original Code

for (i=0; i++; i<MAX) {

... = huge_data[i].status + ...

}

for (i=0; i++; i<MAX) {

... = huge_data_status[i] + ...

}

Utilization Optimization

Predicted fetch rate if utilization = 100%

Fetch rate

Cache size

Cache utilization ≈ Fraction of cache data utilized

SlowSpotter’s First Advice: Improve Utilization

Change one data structure

 Involves ~20 lines of code

 Takes a non-expert 30 min

(77)

Mem, VM and SW optimizations77 AVDARK

2012

After Utilization Optimization

Original Code Utilization Optimization Libquantum

Predicted fetch rate ≈ New fetch rate

Old fetch rate Cache Utilization ≈ 95%

Cache size

(78)

AVDARK

Utilization Optimization

Original Code Utilization Optimization

Predicted fetch rate ≈ New fetch rate

Old fetch rate Cache Utilization ≈ 95%

Cache size 1

2

Two positive effects from better utilization

1. Each fetch brings in more useful data  lower fetch rate

2. The same amount of useful data can fit in a smaller cache  shift left

(79)

Mem, VM and SW optimizations79 AVDARK

2012

Utilization Optimization

Reuse Analysis

Second-Fifth SlowSpotter Advice: Improve reuse of data

Fuse functions traversing the same data

 Here: four fused functions created

 Takes a non-expert < 2h

Libquantum

Fetch rate

...

toffoli(huge_data, ...) cnot(huge_data, ...

...

...

fused_toffoli_cnot(huge_data,...) ...

Utilization + Fusion Optimization

(80)

AVDARK

Effect: Reuse Optimization

 The miss in the second loop goes away

 Still need the same amount of cache to fit “all data”

SPEC CPU2006-462.libquantum

Old fetch rate

Utilization + Fusion Optimization

New fetch rate

Utilization Optimization

1

(81)

Mem, VM and SW optimizations81 AVDARK

2012

Utilization + Reuse Optimization

 Fetch rate down to 1.3% for 2MB

 Same as a 32 MB cache originally

Libquantum

Old fetch rate

Utilization + Fusion Optimization

New fetch rate

Utilization Optimization

(82)

AVDARK

Summary

Libquantum

0 1 2 3 4 5

1 2 3 4

# Cores Used

Thr oughput

Original

Utilization Optimization Utilization + Fusion

2.7x

(83)

Mem, VM and SW optimizations83 AVDARK

2012

 Uppsala Programming for Multicore Architecture Center

 62 MSEK grant / 10 years [$9M/10y]

+ related additional grants at UU = 130MSEK

 Research areas:

 Performance modeling

 New parallel algorithms

 Scheduling of threads and resources

 Testing & verification

 Language technology

 MC in wireless and sensors

Erik:

(84)

Underneath the

ThreadSpotter Hood

(85)

Mem, VM and SW optimizations85 AVDARK

2012

85

Great but Slow Insight: Simulation

Slowdown: ≈ 10 - 1000x

Code:

set A,%r1 ld [%r1],%r0 st %r0,[%r1+8]

add %r1,1,%r1 ld [%r1+16],%r0 add %r0,%r5,%r5 st %r5,[%r1+8]

[...]

Memory ref:

1:read A 2:write B 3:read C 4:write B [...]

CPU-sim Level-n Memory

Cache Level-1

Cache

Simulated Memory

System Simulated

CPU

(86)

AVDARK

Limited Insight: Hardware Counters

Slowdown: ≈ 0%

CPU Level-n Memory

Cache Level-1

Cache

Ordinary Computer

• No flexibility

• Limited insight

Insight: “Instruction X misses Y% of the time in the cache”

HW ctr HW ctr

HW ctr

(87)

Mem, VM and SW optimizations87 AVDARK

2012

Need Efficiency and Insight:

Our Approach

Machine- independent

runtime information

Efficient modeling

Draw conclusions,

build tools

= ∑ 1 1 )

1. Capture data locality information

Find ”best”:

• Core type

• Cache size

• Thread scheduling

• Frequency

• Code optimizations…

Predict (for many options)

• Cache statistics

• Bandwidth requirement

• Performance

• Power consumption

• Phase behavior ...

2. Measure impact of resource allocations

Solve equations

Gather runtime info Add heuristics

3. Capture code usage

information? Clustering, K-means...

(88)

AVDARK

StatCache: Insight and Efficiency

Slowdown 10% (for long-running applications)

mem

Probabilistic  Cache Model

Address Stream

1:read A 2:read B 3:read C 4:write C 5:read B 6:read D 7:read A 8:read E

Host Computer Target Architecture

Architectural Parameters

Online Sampling Offline “Insight Technology”

core

core

... mem

L1

L1

L2

core

...

core

Modeled behavior Application

Fingerprint 5, 3,…

Reuse

Distance=5

Reuse

Distance=3

Sparse Sampler

Acumem

Advice Randomly select accesses

to monitor

(89)

Mem, VM and SW optimizations89 AVDARK

2012

UART: Efficient sparse sampling

A B D B E B A F D B . .

1 2 3 4 5 6 7 8 9 10 11 12 … N . .

… .

i=0

1.Use HW counter overflow to randomly select accesses to sample (e.g. ~on avergage every 1.000.000th access)

2. Set a watchpoint for the data cacheline they touch

3. Use HW counters to count #memory accesses until watchpoint trap

Sampling Overhead ~17% (10% at Acumem for long-running apps) (Modeling with math < 100ms)

trap trap

(90)

AVDARK

Fingerprint

≈ Sparse reuse distance histogram

Reuse distance

h(d)

(91)

Mem, VM and SW optimizations91 AVDARK

2012

Miss?

p miss =m(#repl)

Modeling random caches with math

(Assumtion: ”Constant” MissRatio)

A B D B E B A F D B . .

1 2 3 4 5 6 7 8 9 10 11 12 … N . .

# repl ≈ 5 * MissRatio

… .

#repl p miss Miss Equation m

rd i =5

(92)

AVDARK The cacheline A is in a cache with

After 1 Replacement

(1 – 1/L) chance

that A survives (1 – 1/L) R chance

A A A

After R Replacements

Assuming a fully associative cache

(93)

Mem, VM and SW optimizations93 AVDARK

2012

Miss?

93

p miss =m(5 * MissRatio)

Modeling random caches with math

(Assumtion: ”Constant” MissRatio)

A B D B E B A F D B . .

1 2 3 4 5 6 7 8 9 10 11 12 … N . .

# repl ≈ 5 * MissRatio p miss =m(3 * MissRatio)

… .

# repl ≈ 3 * MissRate

n samples: MissRatio * n = Σ m (rd(i) * MissRatio)

i=0 n m(repl)=1 – (1 – 1/L) repl

#repl p miss

Can be solved in a ”fraction of a second” for different L

Miss Equation m

rd i =5

(94)

AVDARK

Accuracy: Simulation vs. ”math”

(Random replacement)

Miss r atio (%)

vpr

gzip

ammp

Comparing simulation (w/ slowdown 100x) and math (”fractions of a second”)

(95)

Mem, VM and SW optimizations95 AVDARK

2012

A B A B

. . 1 2 3 4 5 6 7 8 9

B C C D E C … C

Sampled Reuse Pair A-A

Stack Distance: How many unique data objects? Answer: 3

12 ... N

Modeling LRU Caches: Stack distance...

If we know all reuses: How many of the reuses 2-6 go beyond End? Answer: 3

Stack_distance = Σ [d(i) > (End – k + 2)]

k=Start End

Start=2 End=6

rd i =5

Foreach sample: if (Stack_distance > L ) miss++ else hit++

(96)

AVDARK

A B A B

. . 1 2 3 4 5 6 7 8 9

B C C D E C … C

d(1)

12 ... N

But we only know a few reuse distances...

Estimate: How many of the reuses 2-6 go beyond End? Answer: Est_SD

Est_SD = Σ p[d(i) > (End - k)]

End

Assume that the distribution (aka histogram) of sampled reuses is representative for all accesses in that ”time window”

d(2) d(3)

d

h(d)

(97)

Mem, VM and SW optimizations97 AVDARK

2012

All SPEC 2006

(98)

AVDARK

Architecturally independent!

 The fingerprint does not depend on the caches of the host architecture

 Solve the equation for different targer architecture:

 Cache sizes

 Cacheline sizes

 Replacement algorithms {LRU, RND}

 Cache topology

(99)

Mem, VM and SW optimizations99 AVDARK

2012

In a nutshell

1. Sampling: Randomly select windows, and collect sparse reuse histograms from each window

2. Use histogram as input to model behavior of target arch.

xx x x x x xx x x x x x x x xx x x xx x xx xxxx mem ops

time [mem accesses]

d(1) d(2) d(3) ...

h

d

miss ratio

cache-size

Model

histogram behavior

(100)

AVDARK

Shared cache model

Architectural Parameters Offline Modeling

Target Architecture

mem

L1

L1

L2

core

...

core

Modeled Behavior Application

Fingerprint B 5, 3,…

Example2: Modeling Shared Resources

Predict multicore cache sharing

behavior

Application Fingerprint C

5, 3,…

Application Fingerprint A

5, 3,…

Parallel Architecture and

Compilation Techniques, PACT

Sept 2010.

References

Related documents

• Most of the blocks in LLCs are dead and consume precious cache space. • State-of-the-art schemes predict dead-blocks without any semantic information from the

The detection mechanism described above is not directly applicable to a competitive-update protocol because in a competitive-update protocol it is not sufficient to know the number

When some object must be removed from a cache, a remove message is sent to all neighbor caches directly connected to the proxy cache..

Utilization, i.e., fraction cache data used (scale to the right) Possible miss rate if utilization problem was fixed. Running one

Dept of Information Technology| www.it.uu.se 2 © Erik Hagersten| user.it.uu.se/~eh..

Dept of Information Technology| www.it.uu.se 2 © Erik Hagersten| www.docs.uu.se/~eh..

No more sets than there are cache lines on a page + logic Page coloring can be used to guarantee correspondence between more PA and VA bits (e.g., Sun

Dept of Information Technology| www.it.uu.se 2 © Erik Hagersten| http://user.it.uu.se/~eh..