DOC PREVIEW
Berkeley COMPSCI 61C - Lecture 17 - Caches, Part I

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS61C L17 Cache1 © UC Regents1CS61C - Machine StructuresLecture 17 - Caches, Part IOctober 25, 2000David Pattersonhttp://www-inst.eecs.berkeley.edu/~cs61c/CS61C L17 Cache1 © UC Regents2Things to Remember°Magnetic Disks continue rapid advance:60%/yr capacity, 40%/yr bandwidth, slowon seek, rotation improvements, MB/$improving 100%/yr?•Designs to fit high volume form factor•Quoted seek times too conservative,data rates too optimistic for use in system°RAID•Higher performance with more disk arms per $•Adds availability option for small number ofextra disksCS61C L17 Cache1 © UC Regents3Outline°Memory Hierarchy°Direct-Mapped Cache°Types of Cache Misses°A (long) detailed example°Peer - to - peer education example°Block Size (if time permits)CS61C L17 Cache1 © UC Regents4Memory Hierarchy (1/4)°Processor•executes programs•runs on order of nanoseconds topicoseconds•needs to access code and data forprograms: where are these?°Disk•HUGE capacity (virtually limitless)•VERY slow: runs on order of milliseconds•so how do we account for this gap?CS61C L17 Cache1 © UC Regents5Memory Hierarchy (2/4)°Memory (DRAM)•smaller than disk (not limitless capacity)•contains subset of data on disk: basicallyportions of programs that are currentlybeing run•much faster than disk: memory accessesdon’t slow down processor quite as much•Problem: memory is still too slow(hundreds of nanoseconds)•Solution: add more layers (caches)CS61C L17 Cache1 © UC Regents6Memory Hierarchy (3/4)ProcessorSize of memory at each levelIncreasingDistancefrom Proc.,Decreasingcost / MBLevel 1Level 2Level nLevel 3. . .HigherLowerLevels inmemoryhierarchyCS61C L17 Cache1 © UC Regents7Memory Hierarchy (4/4)°If level is closer to Processor, it mustbe:•smaller•faster•subset of all higher levels (contains mostrecently used data)•contain at least all the data in all lowerlevels°Lowest Level (usually disk) containsall available dataCS61C L17 Cache1 © UC Regents8Memory Hierarchy°Purpose:• Faster access to large memory fromprocessor Processor (active)ComputerControl(“brain”)Datapath(“brawn”)Memory(passive)(where programs, data live whenrunning)DevicesInputOutputKeyboard, MouseDisplay, PrinterDisk,NetworkCS61C L17 Cache1 © UC Regents9Memory Hierarchy Analogy: Library (1/2)°You’re writing a term paper(Processor) at a table in Doe°Doe Library is equivalent to disk•essentially limitless capacity•very slow to retrieve a book°Table is memory•smaller capacity: means you must returnbook when table fills up•easier and faster to find a book thereonce you’ve already retrieved itCS61C L17 Cache1 © UC Regents10Memory Hierarchy Analogy: Library (2/2)°Open books on table are cache•smaller capacity: can have very few openbooks fit on table; again, when table fillsup, you must close a book•much, much faster to retrieve data°Illusion created: whole library open onthe tabletop•Keep as many recently used books openon table as possible since likely to useagain•Also keep as many books on table aspossible, since faster than going to libraryCS61C L17 Cache1 © UC Regents11Memory Hierarchy Basis°Disk contains everything.°When Processor needs something,bring it into to all lower levels ofmemory.°Cache contains copies of data inmemory that are being used.°Memory contains copies of data ondisk that are being used.°Entire idea is based on TemporalLocality: if we use it now, we’ll want touse it again soon (a Big Idea)CS61C L17 Cache1 © UC Regents12Cache Design°How do we organize cache?°Where does each memory addressmap to? (Remember that cache issubset of memory, so multiplememory addresses map to the samecache location.)°How do we know which elements arein cache?°How do we quickly locate them?CS61C L17 Cache1 © UC Regents13Direct-Mapped Cache (1/2)°In a direct-mapped cache, eachmemory address is associated withone possible block within the cache•Therefore, we only need to look in asingle location in the cache for the data ifit exists in the cache•Block is the unit of transfer betweencache and memoryCS61C L17 Cache1 © UC Regents14Direct-Mapped Cache (2/2)° Cache Location 0 can beoccupied by data from:• Memory location 0, 4, 8, ...• In general: any memorylocation that is multiple of 4MemoryMemory Address0123456789ABCDEF4 Byte Direct Mapped CacheCache Index0123CS61C L17 Cache1 © UC Regents15Issues with Direct-Mapped°Since multiple memory addresses mapto same cache index, how do we tellwhich one is in there?°What if we have a block size > 1 byte?°Result: divide memory address intothree fieldsttttttttttttttttt iiiiiiiiii oooo tag index byteto check to offsetif have select withincorrect block block blockCS61C L17 Cache1 © UC Regents16Direct-Mapped Cache Terminology°All fields are read as unsigned integers.°Index: specifies the cache index (which“row” of the cache we should look in)°Offset: once we’ve found correct block,specifies which byte within the blockwe want°Tag: the remaining bits after offset andindex are determined; these are used todistinguish between all the memoryaddresses that map to the samelocationCS61C L17 Cache1 © UC Regents17Direct-Mapped Cache Example (1/3)°Suppose we have a 16KB direct-mapped cache with 4 word blocks.°Determine the size of the tag, index andoffset fields if we’re using a 32-bitarchitecture.°Offset•need to specify correct byte within a block•block contains 4 words16 bytes24 bytes•need 4 bits to specify correct byteCS61C L17 Cache1 © UC Regents18Direct-Mapped Cache Example (2/3)°Index•need to specify correct row in cache•cache contains 16 KB = 214 bytes•block contains 24 bytes (4 words)•# rows/cache = # blocks/cache (sincethere’s one block/row) = bytes/cachebytes/row = 214 bytes/cache 24 bytes/row = 210 rows/cache•need 10 bits to specify this many rowsCS61C L17 Cache1 © UC Regents19Direct-Mapped Cache Example (3/3)°Tag•used remaining bits as tag•tag length = mem addr length- offset- index = 32 - 4 - 10 bits = 18 bits•so tag is leftmost 18 bits of memoryaddressCS61C L17 Cache1 © UC Regents20Administrivia°Midterms returned in lab°See T.A.s in office hours if have questions°Reading: 7.1 to 7.3°Homework 7 due MondayCS61C L17 Cache1 © UC Regents21Computers in the News: Sony Playstation 210/26 "Scuffles GreetPlayStation 2's Launch"•"If you're a gamer, youhave to have one,'' onewho pre-ordered the $299console in February•Japan: 1 Million on 1st


View Full Document

Berkeley COMPSCI 61C - Lecture 17 - Caches, Part I

Documents in this Course
SIMD II

SIMD II

8 pages

Midterm

Midterm

7 pages

Lecture 7

Lecture 7

31 pages

Caches

Caches

7 pages

Lecture 9

Lecture 9

24 pages

Lecture 1

Lecture 1

28 pages

Lecture 2

Lecture 2

25 pages

VM II

VM II

4 pages

Midterm

Midterm

10 pages

Load more
Download Lecture 17 - Caches, Part I
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 17 - Caches, Part I and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 17 - Caches, Part I 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?