CSE 326 Data Structures The Memory Hierarchy Investigates

CSE 326 Data Structures The Memory Hierarchy Investigates Sorting Zasha Weinberg, in lieu of Steve Wolfman* Winter 2000 * with many ideas stolen from Richard Ladner’s Winter 1999 CSE 326

A victim of the Memory Hierarchy, headed by the mysterious entity known only as “CPU”

Memory Hierarchy Stats (made up) Name L 1 (on chip) cache L 2 cache Extra CPU cycles Size used to access 0 32 KB 8 512 KB RAM 35 256 MB Hard Drive 500, 000 8 GB

The Memory Hierarchy Exploits Locality of Reference • Idea: small amount of fast memory • Keep frequently used data in the fast memory • LRU replacement policy – Keep recently used data in cache – To free space, remove Least Recently Used data

So what? • Optimizing use of cache can make programs way faster • One TA made Radix. Sort 2 x faster, rewriting to use cache better • Not just for sorting

Cache Details (simplified) Main Memory Cache line size (4 adjacent memory cells)

Selection Sort – Sucky Sort Cache Size Already sorted Sweep to find next minimum

Selection Sort Cache Misses • Cache miss read line get hits for rest of cache line • Then another miss • # misses = (N 2/2)/(cache line size)

Quick. Sort Bows to Memory Hierarchy • Partition kind of like Selection Sort • BUT, subproblems more quickly fit in cache • Selection Sort only fits in cache right at the end

Iterative Merge. Sort – not so good Cache Size

Iterative Merge. Sort – cont’d Cache Size

Tiled Merge. Sort – better Cache Size

Tiled Merge. Sort – cont’d Cache Size

Radix Sort – Very Naughty • On each Bin. Sort – Sweep through input list – cache misses along the way (sucky!) – Append to output list – indexed by pseudorandom digit (ouch!) • Truly evil for large Radix (e. g. 216), which reduces # of passes

Not enough RAM – External Sorting • e. g. Sort 10 billion numbers with 1 MB of RAM. • Databases need to be very good at this • Winter 2000 326’ers won’t need to be