AbstractPrior research demonstrates that temporal

memory streaming and related address-correlatingprefetchers improve performance of commercial serverworkloads though increased memory level parallelism.Unfortunately, these prefetchers require large on-chipmeta-data storage, making previously-proposeddesigns impractical. Hence, to improve practicality,researchers have sought ways to enable timely prefetchwhile locating meta-data entirely off-chip. Unfortu-nately, current solutions for off-chip meta-dataincrease memory traffic by over a factor of three.

We observe three requirements to store meta-dataoff chip: minimal off-chip lookup latency, bandwidth-efficient meta-data updates, and off-chip lookup amor-tized over many prefetches. In this work, we show:(1) minimal off-chip meta-data lookup latency can beachieved through a hardware-managed main memoryhash table, (2) bandwidth-efficient updates can beperformed through probabilistic sampling of meta-dataupdates, and (3) off-chip lookup costs can be amortizedby organizing meta-data to allow a single lookup toyield long prefetch sequences. Using these techniques,we develop Sampled Temporal Memory Streaming(STMS), a practical address-correlating prefetcher thatkeeps predictor meta-data in main memory whileachieving 90% of the performance potential of ideal-ized on-chip meta-data storage.

1. IntroductionMemory access latency continues to pose a crucial

performance bottleneck for commercial server work-loads [11]. System designers employ a variety ofstrategies to bridge the processor-memory performancegap. On the software side, efforts are under way torestructure server workloads to increase on-chip datasharing and reuse [15,19]. Although these effortsreduce off-chip accesses, application working sets con-tinue to exceed available cache capacity. On thehardware side, multi-threading is effective in improv-ing throughput when abundant software threads areavailable, but does not improve response time [11,20].

Prefetching improves both throughput andresponse time by increasing memory level parallelism[6,7,24,27] and remains an essential strategy to address

the processor-memory performance gap. Today’s sys-tems employ spatial/stride based prefetchers [22,29]because they are practical to implement. Theseprefetchers require simple hardware additions and min-imal on-chip area [17]. However, the effectiveness ofthese prefetchers is limited in commercial workloads(e.g., online transaction processing), which are domi-nated by pointer-chasing access patterns [1,25,27].

In contrast to stride-based approaches, address-correlating prefetchers [3,5,6,9,10,13,16,18,21,23,27]are effective for repetitive, yet arbitrarily-irregularaccess patterns, such as the pointer-chasing access pat-terns of commercial workloads [5,6,26,27]. Address-correlating prefetchers associate a miss address with aset of possible successor misses, or, in Temporal Mem-ory Streaming (TMS) [10,26,27] and similar recentproposals [6,9,21,23], a sequence of successors. Formodern commercial workloads, early address-correlat-ing prefetcher designs are impractical because the on-chip meta-data size required to capture correlations isproportional to an application’s data set and requiresmegabytes of storage [13,16,18].

To improve practicality, recent address-correlatingprefetchers store meta-data off chip in main memory[6,9,23,27]. Shifting correlation tables to main memoryeliminates on-chip storage costs, but creates two newchallenges. First, correlation table lookups incur one ormore main memory access latencies, which delayprefetches. The correlation algorithm must be designedto tolerate this long lookup latency by targetingprefetches several misses ahead in the anticipatedfuture miss sequence [6,27]. Second, the extra memorytraffic used to lookup and maintain meta-data increasesmemory bandwidth pressure. Existing designs requirecorrelation table lookups and updates on nearly everycache miss, incurring overhead traffic three timeslarger than the base system’s read traffic.

We observe three key requirements to make off-chip meta-data practical: (1) minimal off-chip meta-data lookup latency, (2) bandwidth-efficient meta-dataupdates, and (3) off-chip lookup amortized over manyaccurate prefetches. We propose hash-based lookup toachieve the first requirement. In hash-based lookup, weuse a hardware-managed hash table to index previ-

Practical Off-chip Meta-data for Temporal Memory StreamingThomas F. Wenisch*, Michael Ferdman‡, Anastasia Ailamaki‡, Babak Falsafi‡ and Andreas Moshovos†

http://www.ece.cmu.edu/~stems*University of Michigan †University of Toronto

‡Ecole Polytechnique Fédérale de Lausanne and Carnegie Mellon University

ously-recorded miss-address sequences within a log ofprior misses. Hash-based lookup enables retrieval ofthe corresponding miss addresses with only two main-memory round-trips (one for the hashed index tablelookup, and the second for the address sequence). Wepropose probabilistic update to achieve the secondrequirement. Probabilistic update applies only a ran-domly-selected subset of updates to the hashed indextable, reducing index table maintenance bandwidth topractical levels. Because recurring miss-addresssequences either tend to be long or repeat frequently,stale or missing index table entries do not sacrifice sig-nificant coverage. We address the third requirement byapplying these two mechanisms to a previously-pro-posed prefetch meta-data organization where missesare logged continuously in a circular buffer [21,27]. Byseparating indexing and logging, this prefetcher organi-zation allows a single lookup to predict long miss-address sequences of up to hundreds of misses [26,27].We evaluate our practical design, Sampled TemporalMemory Streaming (STMS), through cycle-accuratefull-system simulation of scientific and commercialmultiprocessor workloads, to demonstrate:• Performance potential. Ideal on-chip lookup

would enable TMS to eliminate 19-99% of off-chip misses (40-60% in online transaction process-ing and web workloads), improving performanceby up to 80% (5-18% for OLTP and Web).

• Storage efficiency. Because meta-data is locatedoff chip, STMS requires only 2KB of on-chipprefetch buffers per core. For maximum effective-ness, STMS needs 64MB of meta-data in mainmemory, a small fraction of memory in servers.

• Latency efficiency. By using hash-based lookupto prefetch sequences of tens of misses, STMSmitigates main-memory meta-data access latency.A practical lookup mechanism achieves 90% ofthe performance potential of idealized lookup.

• Bandwidth efficiency. We show that probabilisticupdate reduces the memory traffic overhead ofmeta-data updates by a geometric mean factor of3.4 with a maximum coverage loss of 6%.

2. BackgroundAn address-correlating prefetcher learns temporal

relationships between accesses to specific addresses.For instance, if address B tends to be accessed shortlyafter address A, an address-correlating prefetcher canlearn this relationship and use the occurrence of A totrigger a prefetch of B. Address-correlating prefetcherssuccinctly capture pointer-chasing relationships, andthus substantially improve the performance of pointer-intensive commercial workloads [5,6,27].

Pair-wise–correlating prefetchers. The Markovprefetcher [16] is the simplest prefetcher design forpredicting pair-wise correlation between an addressand its successor (i.e., two addresses that tend to causeconsecutive cache misses). The Markov prefetcherhardware is organized as a set-associative table thatmaps an address to several recently-observed possibili-ties for the succeeding miss. On each miss, the table issearched for the miss address, and if an entry is found,the likely successors are prefetched. Several pair-wise–correlating prefetchers build upon this simple design tooptimize correlation table storage [13], or triggerprefetchers earlier to improve lookahead [12,18].

The key limitation of pairwise-correlatingprefetchers is that they attempt to predict correctly onlya single miss per prediction, limiting memory level par-allelism and prefetch lookahead. More recent address-correlating prefetchers use a single correlation to pre-dict a sequence of successor misses [6,9,10,21,23,27].We adopt the terminology of [26] and refer to thesesuccessor sequences as temporal streams—extendedsequences of memory accesses that recur over thecourse of program execution.

Temporal streaming. The observation that mem-ory access sequences recur was first quantified inmemory trace analysis by Chilimbi and Hirzel [4]. Toexploit this observation, researchers initially proposedcorrelation tables that store a temporal stream (i.e., ashort sequence of successors) rather than only a singlefuture access in each set-associative correlation tableentry [6,23]. The primary shortcoming of this set-asso-ciative organization is that temporal stream length isfixed to the size of the table entry, typically three to sixsuccessor addresses. However, offline analyses of missrepetition [4,9,26] have shown that temporal streamsvary drastically in length, from two to hundreds ofmisses. Fixing stream length in the prefetcher designleads either to inefficient use of correlation table stor-age (if the entries are too large) or sacrifices lookaheadand prefetch coverage (if entries are too small).

To support variable length temporal streams whilemaintaining storage efficiency, several designs separatethe storage of address sequences and correlation data[10,21,27]. A history buffer records the application’srecent miss-address sequence, typically in a circularbuffer. An index table correlates a particular missaddress (or other lookup criteria) to a location in thehistory buffer. The split-table approach allows a singleindex-table entry to point to a stream of arbitrarylength, allowing maximal lookahead and prefetch cov-erage without substantial storage overheads.

In this study, our goal is not to improve the predic-tion accuracy of state-of-the-art address-correlating

prefetchers. Instead, we seek to identify and solve thekey implementation barriers that make these prefetch-ers unattractive for practical deployment.

3. Practicality ChallengesMore than a decade of research has repeatedly

shown that address-correlating prefetchers can elimi-nate about half of all off-chip misses in pointer-intensive commercial server workloads, whereas strideprefetchers provide only minimal benefit [4,6,26,27].Nevertheless, stride prefetchers are widely imple-mented, while, to date, no commercial design hasimplemented an address-correlating prefetcher. In thissection, we enumerate the major practicality challengesof prior address-correlating prefetcher designs.

On-chip storage requirements. Initial address-correlating prefetcher designs located correlation tablesentirely on-chip [13,16,18,21]. However, correlationtable storage requirements are proportional to the appli-cation’s working set. Hence, for commercialworkloads, even the most storage-efficient design [13]requires megabytes of correlation table storage to beeffective [6,27]. Figure 1 (left) shows the number ofcorrelation table entries required for a given averagecoverage across commercial workloads for the ideal-ized address-correlating prefetcher we analyze in detailin Section 5.2. Our result corroborates prior work [6]:to achieve maximum coverage in commercial work-loads, correlation tables must store more than onemillion entries, which can require as much as 64MB ofstorage. High storage requirements make on-chip cor-relation tables impractical.

More recent prefetchers locate correlation meta-data in main memory [6,9,23,27], where multi-mega-byte tables can easily be accommodated. However, off-chip tables lead to two new challenges: high lookuplatency and increased memory bandwidth pressure.

High lookup latency. When correlation tables areoff chip, each lookup requires at least one main mem-ory access before prefetching can proceed. Unlikeother predictors that can make use of the on-chip cachehierarchy to provide “virtual” on-chip lookup [2],address correlation tables are substantially larger thanthe on-chip caches and correlation entries exhibit mini-mal temporal locality. A correlation table entry is notreused until the address it corresponds to is evictedfrom on-chip caches. By that time, the correlation entryis also likely to be evicted.

Instead, the prefetching mechanism must bedesigned to account for long correlation table lookuplatency. Epoch-based correlation prefetching (EBCP)[6] explicitly accounts for off-chip lookup latency andthe memory level parallelism already obtained by out-of-order processing in choosing prefetch addresses.Rather than correlate an address to its immediate suc-cessors, EBCP skips over successor addresses that willbe requested while the correlation table lookup is inprogress. However, EBCP employs a set-associativecorrelation table, which, as noted in Section 2, boundsmaximum stream length, limiting memory level paral-lelism, lookahead, and bandwidth efficiency.

With STMS, we instead mitigate lookup latency byfollowing arbitrarily long streams to maximize thenumber of prefetches per lookup operation—a singlelookup may lead to tens or hundreds of prefetches. Thesplit-table meta-data organization and hash-basedlookup mechanism are key to this strategy.

Memory bandwidth requirements. Address-cor-relating prefetchers with off-chip meta datasubstantially increase pressure on memory bandwidth.First, as with any prefetching mechanism, erroneousprefetches (cache blocks that are prefetched but neveraccessed) consume memory bandwidth, as prefetchersinherently trade increased memory bandwidth require-ments to reduce effective access latency. However, off-

0%

20%

40%

60%

80%

100%%�Coverage

0%

Correlation�Table�Entries

00.5

11.5

22.5

33.5

44.5

5

EBCP ULMT TSE

Ove

rhea

d Tr

affic

(ove

rhea

d ac

cess

es p

er

base

line

read

acc

ess)

Erroneous PrefetchesMeta-data LookupMeta-data Update

FIGURE 1: Practicality challenges. The left graph shows the number of correlation table entries required for a given coverage in commercial server workloads. One million correlation table entries can require up to 64MB of storage [6].

The right graph shows the memory traffic overheads of existing designs based on their published results [6,23,27]

104 105 106 107

chip correlation tables make matters worse: both look-ups and updates require off-chip memory accesses.

Figure 1 (right) shows the average memory trafficoverheads for three existing address-correlatingprefetchers that store meta-data in main memory, theUser Level Memory Thread (ULMT [23]), the Epoch-Based Correlation Prefetcher (EBCP [6]), and the Tem-poral Streaming Engine (TSE [27]), based on theirpublished results. Overhead traffic is normalized to thenumber of memory reads without a prefetcher. “Erro-neous Prefetches” are calculated directly frompublished accuracy and coverage. ULMT and TSEincur “Meta-data Lookup” traffic on each off-chip readmiss (i.e., the remaining misses after prefetching),requiring one and three memory accesses per lookup,respectively. EBCP performs a single memory accessto lookup its meta-data at the start of each off-chip missepoch—that is, when the number of outstanding (non-prefetch) off-chip misses transitions from zero to one.ULMT and EBCP perform “Meta-data Update” follow-ing each lookup, both requiring three memory accessesper update. TSE updates its correlation tables on bothoff-chip misses and prefetcher hits, requiring slightlyover one memory access per update on average.

As the figure shows, overhead traffic is triple thebaseline read traffic without a prefetcher. Several fac-tors mitigate the performance impact of massive trafficoverheads in the existing designs. All three designsissue correlation table lookups and updates as low-pri-ority traffic, prioritizing processor-initiated requests.ULMT collocates its prefetcher with an off-chip mem-ory controller, and, hence, its meta-data traffic does notcross the processor’s pins. TSE’s meta-data lookups areembedded in existing cache coherence traffic. Whenunused memory bandwidth is abundant, overhead traf-fic can be absorbed by the memory system withminimal performance impact. However, as availablememory bandwidth must be shared among cores in amulti-core system, memory bandwidth utilization isgrowing rapidly with chip multiprocessor scaling.Hence, the high traffic overhead of current main-mem-ory correlation table designs limits their applicability.

If it were possible to store correlation tables onchip, lookup and update traffic would be of little con-cern—though large relative to off-chip traffic, requiredbandwidth can be easily sustained in dedicated on-chipstructures. However, storage requirements preclude on-chip meta-data, requiring new solutions to improvebandwidth-efficiency for off-chip meta-data storage.

4. STMS DesignWe leverage prior work in temporal streaming to

reuse mechanisms and terminology whenever possible.

We begin by enumerating the three key requirementsfor effective temporal streaming in Section 4.1. Wethen provide an overview of STMS in Section 4.2, con-structing a generalized temporal streaming prefetcherthat draws heavily from the stream-following mecha-nisms of the Temporal Streaming Engine (TSE) [27]and the predictor organization of the Global HistoryBuffer (GHB) [21]. After we describe the basic hard-ware operation, the following sections provide detailsof how the proposed STMS mechanisms meet therequirements for efficient temporal streaming.

4.1. Requirements for Effective Temporal Streaming

Minimize Lookup Latency. Temporal-streamingprefetchers initiate predictor lookup on a trigger event(typically a cache miss). However, prefetches cannot beissued until an address sequence is located andretrieved. Cache misses incurred during this time resultin lost prefetch opportunity, even if they comprise apredictable temporal stream [6]. Prior prefetchers tar-geting desktop/engineering applications rely on longtemporal streams to overcome the startup cost [9].However, unlike those applications, prior research [27]and our results (see Section 5.4) indicate that half of thetemporal streams in commercial workloads are shorterthan ten cache blocks. Therefore, effective streamingfor commercial workloads requires minimal lookuplatency to ensure timely prefetch.

Bandwidth-efficient Index Table Updates.Maintaining predictor meta-data in off-chip storageinduces additional traffic across the memory interface.Spatial locality allows amortization of history bufferupdates by storing multiple consecutive addresses withone off-chip write. Conversely, any index table updatesare directed to randomized addresses and exhibit nei-ther spatial nor temporal locality. Furthermore, eachindex table update incurs both a read and a write opera-tion. Performing all updates on an un-optimized main-memory index table will therefore triple memory band-width consumption over a base system. Efficientbandwidth utilization is growing even more importantin chip multiprocessor, where scaling in the number ofcores per die will continue increasing strain on off-chipbandwidth [14].

Amortized Lookups. Another key requirementfor effective temporal streaming is to amortize off-chiplookups over many successful prefetches, therebykeeping off-chip bandwidth low by reducing the num-ber of index table lookups and history buffer reads. Thestatic stream lengths imposed in previous single-tableprefetcher designs fragment long temporal streams intoshort prefetch sequences (see Section 3), limitingprefetcher effectiveness, as half of the temporal streams

found in commercial workloads are long (in excess of10 misses). Furthermore, the bandwidth and congestionoverhead of accessing the history structures for eachshort sub-sequence can match or exceed the bandwidthrequired to retrieve data. Widening correlation tableentries to target long streams in a single-tableprefetcher is also bandwidth-inefficient. Large correla-tion table entries that can contain many miss addressesresult in considerable bandwidth overhead when use-less addresses or empty space is retrieved from thehistory structures in the case of shorter streams.

4.2. Design Overview

Figure 2 shows a block diagram of a four-core sin-gle-chip processor equipped with STMS. STMScomprises on-chip prefetch buffers and queues and off-chip index table [21] and history buffers [21]1. Theprefetch buffers and queues, located along side the L1victim caches [17], orchestrate the streaming processand act as temporary holding space for a small numberof blocks that have been prefetched, but not yetaccessed by the core. The off-chip structures are allo-cated in a private region of main memory, each corereceives its own history buffer but all cores share a uni-fied index table. The index table contains a mappingfrom physical addresses to pointers within the historybuffer, facilitating lookup.

Recording temporal streams. STMS records cor-rect-path off-chip misses and prefetched hits in thecorresponding core’s history buffer. To avoid pollutingthe history buffer with wrong-path accesses, instruc-tions observing prefetched hits and off-chip loads aremarked in the load-store queue [17]. Later, when amarked instruction retires, the effective physicaladdress is appended to the history buffer. To minimizepin-bandwidth overhead, a cache-block-sized bufferaccumulates entries which are then written to main

memory as a group as proposed in [9]. As history buf-fer entries are created, the index table entry for thecorresponding address may be updated to point to thenew history buffer entry. As we discuss in Section 4.4,the majority of index table updates are skipped byprobabilistic update to conserve memory bandwidth.

Each core’s miss-address sequence is logged in aseparate history buffer. Whereas each core’s missesindividually form temporal streams, when accessesfrom multiple cores are interleaved, repetitivesequences are obscured. In the case of multi-threadedcores, each thread requires its own history buffer. Theindex table is shared by all cores.

Lookup. Upon an off-chip read miss, STMSsearches for a previously-recorded temporal stream thatbegins with the miss address. STMS performs a pointerlookup in the index table. If a pointer is found, theaddress sequence is read from the history buffer, start-ing at the pointer location. It is important to note thatthe STMS shared index table can locate a temporalstream from another core’s history buffer.

Streaming cache blocks. Miss addresses readfrom the history buffer are held in a FIFO addressqueue. STMS prefetches addresses from the queue inorder. Prefetched data are stored in the small, fully-associative prefetch buffer, avoiding cache pollution onerroneous prefetches. On correct prefetches, L1 missesare satisfied directly from the prefetch buffer whileSTMS continues to populate the address queue withaddresses from the off-chip history buffer.

4.3. Latency-Efficient Hash-based Index Lookup

Any associative lookup structure can be used toimplement an index table. We examined many possiblestructures (e.g., red-black trees, open address hashtables, direct-mapped tables), however these structureshave unacceptable latency, bandwidth, or storage char-acteristics. To achieve low lookup latency, we elect toimplement the index table as a bucketized probabilistichash table [8] pictured in Figure 2 (right).

1. Although prior work in uniprocessors calls these structures globalhistory buffers, we avoid the word global because history buffersin the CMP design are per-core.

Main Memory

MemController

StridePrefetcher

...

...

Index Table

addr addrHistory ptr Hist. ptr...

addr addrHistory ptr Hist. ptr...

addr addrHistory ptr Hist. ptr...

hash

miss address

bucket

History Buffers

circular buffers

addr addr addr

addr addr addr

addr addr addr

addr addr addr

L1Core

StreamEngine

PrefetchBuffer

L1Core

StreamEngine

PrefetchBuffer

L1 Core

StreamEngine

PrefetchBuffer

L1 Core

StreamEngine

PrefetchBuffer

L2 ...

...

...

...

FIGURE 2: STMS block diagram.

Physical addresses are hashed to select a bucket.Each bucket contains n {physical address, history buf-fer pointer} pairs, with n sized to the memory systeminterface width (i.e., one cache line). On lookup, theentire bucket is retrieved with one memory access, andsearched linearly (linear search is negligible relative tothe off-chip read latency). On update, the bucket is sim-ilarly retrieved and searched. If the trigger address isfound in the bucket, the entry’s history buffer pointer isupdated. If the trigger address is missing, the leastrecently used entry of the bucket is replaced. Beforebeing written back to memory, the elements are reshuf-fled to maintain LRU order. We find that assigning alow priority to predictor memory traffic is essential tominimize queueing-related stalls. To facilitate indextable updates and to delay writeback until memorybandwidth is available, STMS employs a small (8 KB)bucket buffer.

The key advantage of our hash table design is low-latency index table lookup. In addition, the designresults in high storage density (i.e., it can be fullyloaded) and supports an arbitrary number of parallelreads and updates without synchronization, enablingindependent parallel access from multiple cores.

4.4. Bandwidth-Efficient Probabilistic Index Update

Although only a small fraction of index tableentries yields the vast majority of prefetch coverage, todate, no known property allows a priori distinction ofuseful index table entries at the time they are recorded.Rather than filtering index table updates, we proposeprobabilistic update. For every potential index tableupdate, a coin flip, biased to a predetermined samplingprobability, determines whether the update will or willnot be performed. Index table update bandwidth isdirectly proportional to the sampling probability. Forexample, a 50% sampling probability halves bandwidthrequirements. Probabilistic update is highly effective inreducing index table update bandwidth, while leadingto only a small coverage loss.

Intuitively, sampling does not significantly reducecoverage for most cases: long temporal streams andshort frequent temporal streams. Figure 3 illustratesboth cases. For long temporal streams, probabilisticupdate likely skips several addresses before creating anindex table entry pointing into the body of the stream.However, coverage loss on the first few blocks is negli-gible relative to the stream’s length. For a samplingprobability of one eighth, the probability of inserting atleast one address into the index table reaches 50%within the first five blocks. For frequent temporalstreams, the probability of inserting the first addressinto the index table grows with the number of streamrecurrences. For short temporal streams, the index tablemay remain without a pointer for the first few occur-rences, however a high appearance frequency results inan index update within a small number of occurrences.

4.5. Variable-Length Streams via Split Tables

The drawbacks of statically pre-determined streamlength motivate our desire to support variable-lengthtemporal streams. Variable-length temporal streams aremade possible by splitting the history buffer and indextable into separate structures, as outlined in Section 2.Short streams are accommodated with minimal storageoverhead, while longer streams are accommodated byreading consecutive sections of the history buffer. Akey result of this design is that long streams requireonly a single index lookup. We quantitatively contrastthe latency- and bandwidth-efficiency of single-tableand split-table organizations in Section 5.4.

To avoid streaming erroneous blocks past the endof a temporal stream within the history buffer, STMSannotates the history buffer entry following the lastcontiguous successfully-prefetched address. WheneverSTMS encounters a marked entry, it pauses streaming,continuing only if the annotated address is explicitlyrequested by the core. In contrast to TSE [27], theSTMS stream-end detection is highly bandwidth-effi-cient, requiring to read only one location from thehistory buffer to determine the end of stream.

Long temporal streams

Short, frequent temporal streams

History Buffer

Index Table

A B C D E F G H An index table entry will be created near thefirst miss in a temporal stream with highprobability. Coverage lost on the first fewblocks is negligible relative to stream length

D

History Buffer

Index Table

A B C A AB BC CAfter several stream occurrences, theprobability of adding A to the index table ishigh. Because temporal streams are stable,old occurrences are still valid.A

FIGURE 3: Cases where probabilistic update is effective.

5. EvaluationThe goal of our evaluation is to demonstrate that

STMS (1) matches the coverage and performance ofidealized temporal memory streaming while storingmeta-data in off-chip memory, and (2) that it does notreduce performance of workloads that derive no benefitfrom temporal streaming.

5.1. Methodology

We evaluate STMS using a combination of trace-based and cycle-accurate full-system simulation usingthe FLEXUS infrastructure. FLEXUS builds on the Vir-tutech Simics functional simulator. We include fourworkload classes in our study: online transaction pro-cessing (OLTP), decision support (DSS), web server(Web), and scientific (Sci) applications. Table 1 (left)details our workload suite.

We model a four-core chip multiprocessor withprivate L1 caches and a shared L2 cache configured torepresent an aggressive near-future high-performanceprocessor. The minimum L2 hit latency is 20 cycles,but accesses may take longer due to bank conflicts orqueueing delays. A total of at most 64 L2 accesses andoff-chip misses may be in flight at any time. Furtherconfiguration details appear in Table 1.

We include a stride-based prefetcher in our basesystem [22,29]. All results report only coverage inexcess of that provided by the stride prefetcher.

We measure performance using the SIMFLEX sam-pling methodology [28]. We report confidence intervalson change in performance using matched-pair samplecomparison. Our samples are drawn over an interval offrom 10s to 30s of simulated time for OLTP and webserver workloads, over the complete query executionfor DSS, and over a single iteration for scientific appli-cations. We launch measurements from checkpoints

with warmed caches, branch predictors, history buffer,and index table state, then warm queue and intercon-nect state for 100,000 cycles prior to measuring200,000 cycles. We use the aggregate number of userinstructions committed per cycle (i.e., committed userinstructions summed over the 4 cores divided by totalelapsed cycles) as our performance metric, which isproportional to overall system throughput [28].

5.2. Performance Potential of Idealized Prefetcher

We begin by demonstrating the performancepotential of an idealized version of TMS with on-chipmeta-data. The idealized prefetcher records a sequenceof cache miss addresses in a “magic” on-chip historybuffer that has impractically large storage capacity andzero-latency infinite lookup bandwidth.

Figure 4 presents the coverage (left) and speedup(right) achieved by the idealized prefetcher over ourbaseline system. Coverage is defined as the fraction ofL2 cache misses eliminated by the prefetcher.

We corroborate prior work, showing that temporalmemory streaming is an effective mechanism for elim-inating cache misses in OLTP, web serving, andscientific computing workloads, and that temporalmemory streaming is ineffective for DSS workloadsbecause they exhibit non-repetitive access sequenceswhere data is visited only once throughout execution.We also observe that, despite achieving high predictorcoverage, minimal speedup opportunity is available inworkloads whose dominant bottlenecks are not mainmemory accesses (in the case of OLTP Oracle, the pri-mary bottlenecks are L1 instruction and data missesthat hit in L2 and on-chip core-to-core coherence traf-fic). However, prefetch coverage indicates that even forsuch workloads, once other (on-chip) bottlenecks in thesystem are eliminated, temporal memory streamingoffers a benefit.

Online Transaction Processing (TPC-C)Oracle Oracle 10g, 100 warehouse (10 GB), 16 clients, 1.4 GB SGADB2 DB2 v8, 100 warehouse (10 GB), 64 clients, 2 GB buffer pool

Decision Support (TPC-H on DB2 v8 ESE)Qry 2 Join-dominated, 480 MB buffer poolQry 17 Balanced scan-join, 480 MB buffer pool

Web Server (SPECweb99)Apache Apache 2.0, 4K connect, FastCGI, worker threading model

Zeus Zeus v4.3, 4K connections, FastCGIScientific

em3d 768K nodes, degree 2, span 5, 15% remoteocean 258x258 grid, 9600s relaxations, 20K res., err tol 1e-07

moldyn 19652 molecules, boxsize 17, 2.56M max interactions

Table 1: Application and system model parameters.

Cores UltraSPARC III ISA4 GHz 8-stage pipeline; out-of-order4-wide dispatch / retirement96-entry ROB, LSQ

L1 D-Cache 64KB 2-way, 2-cycle load-to-use3 ports, 32 MSHRs

Instruction FetchUnit

64KB 2-way L1 I-cache16-entry pre-dispatch queueHybrid 16K gShare/bimodal branch pred.Next line prefetcher

Shared L2 Cache 8MB 16-way, 20-cycle access latency16 banks, 64 MSHRs

Main Memory 3 GB total memory, 45 ns access latency28.4 GB/s peak bandwidth, 64-byte transfers

Stride Prefetcher 32-entry buffer, max 16 distinct strides

Although the potential gains are evident inFigure 4, on-chip storage required to implement TMSis impractical (see Figure 1). We recognize thatadvances in the field will improve the coverage ofstream-based address-correlating prefetchers beyondour idealized implementation of the proposed priortechniques [21,27]. However, improved predictors canleverage the basic mechanisms we propose in this workto facilitate off-chip lookup. Our aim is therefore not toimprove over the idealized prior design that wedescribe, but instead to match the performance of ideal-ized TMS. To this end, our goal is two-fold: (1)maintain performance improvement for the workloadswhere streaming is effective, (2) avoid adverse perfor-mance impact in workloads where streaming isineffective. Accomplishing this goal requires band-width-, latency-, and storage- efficiency.

5.3. Achieving Storage Efficiency

On-chip structures. As demonstrated inSection 3, on-chip correlation meta-data are impracti-cal, and, hence, STMS locates its history buffer andindex table in main memory. On chip, STMS requires aprefetch buffer and address queue collocated with eachcore to track pending prefetch addresses and bufferprefetched data. Storage requirements for the addressqueue are negligible (under 128 bytes), while prefetchbuffers each require 2KB. We do not report sensitivityto prefetch buffer size, as it has been studied exten-sively in prior work [6,27]. In addition, STMS uses ashared 8KB bucket buffer to store index table entriesbetween lookup, update, and write back.

History buffer. The history buffer’s main-mem-ory storage requirements are driven by the prefetcher’smeta-data reuse distance. The history buffer must be atleast large enough to fit all intervening miss addressesbetween a recorded temporal stream and its previousoccurrence. For commercial workloads, the reuse dis-

tance depends on the frequency at which data structuresare revisited, resulting in a spectrum of distances, andgiving rise to a smooth improvement in coverage as thesize of the history buffer is increased. Conversely, sci-entific computing workloads typically exhibit a reusedistance proportional to the length of a single computa-tional iteration and varies only with the size of theapplication’s dataset.

Figure 5 (left) plots predictor coverage as a func-tion of history buffer size. For our commercialworkloads, the history buffer must be on the order of32MB to achieve maximal coverage. For scientificworkloads, coverage is bimodal: if the history buffer issufficiently large to capture an entire iteration, cover-age is nearly perfect; if the history buffer isinsufficiently large, coverage is negligible. For bothclasses of workloads, the history buffer storage require-ments are at least an order of magnitude greater thancan be allocated on chip. However, relative to aserver’s main memory, history buffer footprint is small.

Index table. An ideal index table can locate themost recent occurrence of any miss address in the his-tory buffers. Hence, in the worst case, if all addresses inthe history buffer are distinct, then there must exist oneindex table entry per history buffer entry. In practice,far fewer index table entries are required.

To optimize index-table storage efficiency, we pro-pose hash-based lookup. Hash-based lookup spreadsmiss addresses over buckets, applying the LRUreplacement policy within each bucket. The LRU pol-icy brings useful history buffer pointers to the top,naturally aging out unneeded entries. Figure 5 (right)plots predictor coverage as a function of the hash-tablesize for an ideal (unbounded) history buffer. Hash-based lookup achieves maximum coverage with a16MB main-memory index table, retaining only a frac-tion of the index entries of an idealized prefetcher.

0%

20%

40%

60%

80%

100%%

Cov

erag

e

0%

Apa

che

Zeus

DB

2

Ora

cle

DB

2

em3d

mol

dyn

ocea

n

Web OLTP DSS Sci

FIGURE 4: Prefetching potential. The left graph shows the prefetch coverage achieved by an idealized temporal streaming prefetcher. The right graph shows the corresponding performance impact.

0%5%

10%15%20%

70%75%80%

Apa

che

Zeus

DB

2

Ora

cle

DB

2

em3d

mol

dyn

ocea

n

Web OLTP DSS Sci

% S

peed

up

5.4. Achieving Latency Efficiency

An idealized prefetcher would have instant lookup,experiencing no latency between the cache miss thattriggers a prediction and the predicted prefetch. How-ever, a realistic implementation may lose prefetchopportunity on each lookup because time must be spentto locate and retrieve the miss address sequence [6,27].

We estimate lost prefetch opportunity by examin-ing workload and lookup mechanism characteristics. Alatency-efficient predictor will perform a lookup onceper temporal stream recurrence, losing predictionopportunity only during retrieval of the initialaddresses within the stream. Naturally, longer streamsreduce opportunity loss, however temporal streamlength is workload dependent and cannot be controlled.Figure 6 (left) shows a cumulative distribution ofprefetches arising from streams of various lengths inour commercial workloads. In the scientific applica-tions, the length of the single temporal stream dependson iteration length. For our configurations, this lengthis approximately 400,000 misses in em3d, 21,000 inocean, and 81,000 in moldyn.

Lookup opportunity loss also depends on a work-load’s memory level parallelism (MLP [7]), theaverage number of off-chip loads issued while at least

one such load is outstanding. As discussed in priorwork [6], a predictor that retrieves meta-data from mainmemory loses coverage for each followed temporalstream, proportional to the number of round-trip mem-ory accesses needed for a single lookup, multiplied bythe workload’s MLP (shown in Table 2). Like streamlength, MLP is an inherent property of a workload, andis typically low in pointer-chasing applications such asthe studied commercial workloads [1,27].

As discussed in Section 3, when temporal streamsare stored in a single set-associative correlation table(as in EBCP [6] and ULMT [23]), lookups require onlya single memory access before prefetching can pro-ceed. However, the set-associative table design limitsmaximum prefetch sequence length (referred to as theprefetch depth [21]) based on the size of a table entry.Because storage cost, complexity, and update-band-

0%

20%

40%

60%

80%

100%

0.1 1 10 100

% C

over

age

Aggregate History Buffer Size (MB)

FIGURE 5: Storage requirements. The left graph shows the storage requirements for the history buffer. The right graph shows the storage requirements for the index table.

100%

20%

40%

60%

80%

100%

% C

over

age

Web ApacheWeb ZeusOLTP OracleOLTP DB2DSS DB2Sci em3dSci moldynSci ocean

0%0.1 1 10 100

Index Table Size (MB)

0%

20%

40%

60%

80%

100%

1 10 100 1000 10000

Cum

. % S

trea

med

Blo

cks

Temporal Stream Length (blocks)

40%

50%

ss pth)

Web - ApacheWeb - Zeus

0%

10%

20%

30%

0 5 10 15

% C

over

age

Los

(vs.

unb

ound

ed d

ep OLTP - DB2OLTP - OracleDSS - DB2Sci

Fixed Prefetch Depth

FIGURE 6: Amortizing lookup. The left graph shows the fraction of coverage arising from streams of a particular length (commercial workloads only). The right graph shows the prefetch coverage loss of restricted prefetch depth.

Table 2: Memory-level parallelism of off-chip reads (without STMS).

Benchmark MLP Benchmark MLPWeb Apache 1.5 DSS DB2 1.6

Zeus 1.5 Sci em3d 1.7OLTP DB2 1.3 moldyn 1.0

Oracle 1.3 ocean 1.2

width requirements grow with prefetch depth, it mustremain small (three to six addresses [6,21,23]). AsFigure 6 (left) shows, a small fixed depth falls far shortof temporal stream lengths inherent in commercialworkload. Restricted prefetch depth fragments longstreams, forcing multiple lookups and sacrificingopportunity with each lookup. Figure 6 (right) showsthe lost opportunity as a function of prefetch depth.

STMS instead employs a split-table meta-dataorganization, with separate history buffer and indextable, allowing it to follow temporal streams for tens orhundreds of misses. However, the split-table approachimplies a minimum of two round-trip memory accessesper lookup (one to each table). The expected coverageloss STMS incurs due to the additional memory roundtrip (equal to MLP reported in Table 2) is less than thefragmentation losses incurred by single-table designs.

We propose an efficient organization for indextable entries by packing a hash bucket into a singlememory block (64 bytes). Our organization limits themaximum number of index entries per bucket (to 12 inour design), but ensures that the index table can besearched with a single access. We performed an exten-sive analysis of alternative organizations for the indextable (e.g., open address hashing, larger hash bucketchains, tree structures), and found that these organiza-tions were either less storage efficient or sacrificedadditional coverage due to increased lookup latency.

5.5. Achieving Bandwidth Efficiency

Placing predictor meta-data off chip introducesseveral sources of pin-bandwidth overheads: recordingmiss addresses in the history buffer, index tableupdates, lookup operations (index table and historybuffer accesses), and prefetch of erroneously-predictedaddresses. Figure 7 shows the relative importance ofeach overhead source normalized to the base systemoff-chip traffic (which includes demand-triggeredcache block fetches and writebacks).

The largest bandwidth overhead in an un-opti-mized system arises due to index table maintenance(see the bars labelled 100%). Each index table updatecalls for a read and write operations on the correspond-ing index table entry, resulting in bandwidth utilizationthat exceeds the base system traffic for many work-loads. The second largest contributor is index tablelookups, performed on each demand-read-miss fromthe L2, searching for a temporal stream to follow.Although lookup traffic is substantial, it decreases asthe system makes more correct predictions and elimi-nates demand misses. Accurate detection of the end-of-stream curtails the bandwidth consumed by erroneousprefetches. Finally, the bandwidth utilized for record-ing off-chip sequences is negligible (not visible in thegraphs), as a single densely-packed history buffer writeis performed for every twelve off-chip read misses.

The high traffic overheads shown in Figure 7 dem-onstrate the need for probabilistic update. We comparean un-optimized system (100% sampling probability)to one with a probabilistic update sampling probabilityof 1/8th (12.5%). Probabilistic update drasticallyreduces the off-chip traffic required for index updates.

Probabilistic update reduces traffic of index-tablemaintenance at the cost of predictor coverage. Figure 8shows the traffic overhead of streaming (left) and pre-dictor coverage (right) as function of the samplingprobability. Index update traffic is proportional to sam-pling probability. Hence, Figure 7 shows that reducingsampling probability from 100% to 12.5% reduces totaltraffic. Below 12.5%, other sources of overhead (par-ticularly lookup traffic) dominate.

Whereas traffic overhead decreases rapidly, pre-dictor coverage decreases logarithmically withsampling probability. Omitting index table updates hasonly a small effect on coverage because temporalstreams either tend to be long (in which case, a lateraddress in the stream can be used to locate it) or torecur frequently (in which case an index entry from a

0

0.5

1

1.5

2

100%

12.5

%

100%

12.5

%

100%

12.5

%

100%

12.5

%

100%

12.5

%

100%

12.5

%

100%

12.5

%

100%

12.5

%

Apache Zeus DB2 Oracle DB2 em3d moldyn ocean

Web OLTP DSS Sci

Ove

rhea

d Tr

affic

(ove

rhea

d by

tes

/ use

ful d

ata

byte

)

Record Streams Update Index Lookup Streams Incorrect Prefetches

FIGURE 7: Overhead traffic. The left bar in each pair shows memory traffic overheads of off-chip index lookup without probabilistic update (sampling probability = 100%). The right bar shows overheads with a 12.5% probability.

prior occurrence likely exists). Hence, probabilisticupdate is highly effective at reducing off-chip trafficfor index table management.

5.6. Performance Impact of Practical Streaming

We conclude our evaluation by comparing the per-formance impact of STMS to idealized TMS. Weemploy a 12.5% update sampling probability, as itoffers the best balance between bandwidth-efficiencyand coverage for our workloads. Our mechanismsallow STMS to obtain on average 90% of idealizedTMS coverage. Figure 9 (left) compares coverage ofSTMS and idealized TMS. For STMS, we subdividecoverage into fully-covered misses (off-chip latency isfully-hidden) and partially-covered misses (a corerequested the block before the prefetch completed).

Because STMS maintains high coverage, itachieves 90% of the performance improvement possi-ble with idealized lookup. Figure 9 (right) comparesthe performance improvement of STMS and idealizedTMS. We conclude that our proposed mechanisms—hash-based lookup and probabilistic update—enable abandwidth-, latency-, and storage-efficient design,meeting our stated goals of (1) matching the coverageand performance of an idealized prefetcher while stor-

ing meta-data in off-chip memory, and doing so (2)without penalizing the performance of workloads thatderive no benefit from temporal streaming.

6. ConclusionsAddress-correlating prefetchers are known to

improve performance of commercial server workloads.To be effective, these prefetchers must maintain meta-data that cannot fit on chip. In this work, we identifiedthe key requirements for implementing address-corre-lating prefetchers with off-chip meta-data storage. Tosatisfy these requirements, we proposed two tech-niques: hash-based lookup and probabilistic samplingof meta-data updates, and applied these techniques toan address-correlating prefetcher design with split his-tory and index tables. Hash-based lookup achieves lowoff-chip meta-data lookup latency. Probabilistic sam-pling achieves bandwidth-efficient meta-data updates.Split index and history tables amortize each meta-datalookup over multiple prefetches. Our evaluation dem-onstrates that these techniques yield a bandwidth-,latency-, and storage- efficient temporal memorystreaming design that keeps predictor meta-data inmain memory while achieving 90% of the performancepotential of idealized on-chip meta-data storage.

0%

20%

40%

60%

80%

100%

1% 10% 100%

% C

over

age

Sampling ProbabilityFIGURE 8: Probabilistic update sampling sensitivity. The left graph shows the traffic overhead impact of

probabilistic update, while the right graph shows its coverage impact.

0.5

1.0

1.5

2.0O

verh

ead

traf

fic

ead

byte

s / d

ata

byte

)

OLTP OracleOLTP DB2Web ApacheWeb ZeusDSS DB2Sci em3dSci moldyn

0.01% 10% 100%

O(o

verh

e

Sampling Probability

Sc o dySci ocean

0%20%40%60%80%

100%

Idea

lO

ffch

ip

Idea

lO

ffch

ip

Idea

lO

ffch

ip

Idea

lO

ffch

ip

Idea

lO

ffch

ip

Idea

lO

ffch

ip

Idea

lO

ffch

ip

Idea

lO

ffch

ip

% o

ff-ch

ip re

ad m

isse

s Partially covered Fully covered

O O O O O O O O

Apache Zeus DB2 Oracle DB2 em3d moldyn ocean

Web OLTP DSS Sci

%

FIGURE 9: Performance. The left graph compares the coverage of idealized temporal streaming (ideal) and a practical STMS design with off-chip lookup (off-chip). The right graph compares the performance of the two designs,

relative to a design with stride prefetching only.

5%10%15%20%

70%75%80%

% S

peed

up

Idealized LookupOff-chip Lookup

0%5%

Apac

he

Zeus

DB

2

Ora

cle

DB

2

em3d

mol

dyn

ocea

n

Web OLTP DSS Sci

AcknowledgementsThe authors would like to thank Brian Gold and

the anonymous reviewers for their feedback. This workwas supported by grants from Intel, two Sloan researchfellowships, an NSERC Discovery Grant, an IBM fac-ulty partnership award, and NSF grant CCR-0509356.

References[1] Luiz Andre Barroso, Kourosh Gharachorloo, and Ed-ouard Bugnion. Memory system characterization of commer-cial workloads. In Proc. of the 25th International Symposiumon Computer Architecture, 1998.[2] Ioana Burcea, Stephen Somogyi, Andreas Moshovos,and Babak Falsafi. Predictor virtualization. In Proc. of the13th International Conf. on Architectural Support for Pro-gramming Languages and Operating Systems, 2008.[3] Mark J. Charney and Anthony P. Reeves. Generalizedcorrelation-based hardware prefetching. TR EE-CEG-95-1,School of Electrical Engineering, Cornell University, 1995.[4] Trishul M. Chilimbi. Efficient representations and ab-stractions for quantifying and exploiting data reference local-ity. In Proc. of the SIGPLAN ’01 Conf. on ProgrammingLanguage Design and Implementation, 2001.[5] Trishul M. Chilimbi and Martin Hirzel. Dynamic hotdata stream prefetching for general-purpose programs. InProc. of the ACM SIGPLAN 2002 Conf. on Programming lan-guage design and implementation, 2002.[6] Yuan Chou. Low-cost epoch-based correlation prefetch-ing for commercial applications. In Proc. of the 40th IEEE/ACM International Symposium on Microarchitecture, 2007.[7] Yuan Chou, Brian Fahs, and Santosh Abraham. Micro-architecture optimizations for exploiting memory-level paral-lelism. In Proc. of the 31st International Symposium onComputer Architecture, 2004.[8] Thomas H. Cormen, Charles E. Leiserson, Ronald L.Rivest, and Clifford Stein. Introduction to Algorithms. TheMIT Press, 2001.[9] Michael Ferdman and Babak Falsafi. Last-touch corre-lated data streaming. In IEEE International Symposium onPerformance Analysis of Systems and Software, 2007.[10] Michael Ferdman, Thomas F. Wenisch, Anastasia Aila-maki, Babak Falsafi, and Andreas Moshovos. Temporal in-struction fetch streaming. In Proc. of the 41st IEEE/ACMInternational Symposium on Microarchitecture, 2008.[11] Nikos Hardavellas, Ippokratis Pandis, Ryan Johnson,Naju Mancheril, Anastasia Ailamaki, and Babak Falsafi. Da-tabase servers on Chip Multiprocessors: Limitations and Op-portunities. In Third Biennial Conf. on Innovative DataSystems Research, 2007.[12] Zhigang Hu, Stefanos Kaxiras, and Margaret Martonosi.Timekeeping in the memory system: predicting and optimiz-ing memory behavior. In Proc. of the 29th International Sym-posium on Computer Architecture, 2002.[13] Zhigang Hu, Margaret Martonosi, and Stefanos Kaxiras.Tcp: Tag correlating prefetchers. In Proc. of the 9th IEEE Sym-posium on High-Performance Computer Architecture, 2003.[14] Jaehyuk Huh, Doug Burger, and Stephen W. Keckler.

Exploring the design space of future cmps. In Proc. of the2001 International Conf. on Parallel Architectures and Com-pilation Techniques, 2001. [15] Ryan Johnson, Nikos Hardavellas, Ippokratis Pandis,Naju Mancheril, Stavros Harizopoulos, Kivanc Sabirli, Anas-tassia Ailamaki, and Babak Falsafi. To share or not to share?In 33rd Very Large Data Bases Conference, 2007.[16] Doug Joseph and Dirk Grunwald. Prefetching usingMarkov Predictors. In Proc. of the 24th International Sympo-sium on Computer Architecture, 1997.[17] Norman P. Jouppi. Improving direct-mapped cache per-formance by the addition of a small fully-associative cacheand prefetch buffers. In Proc. of the 17th International Sym-posium on Computer Architecture, 1990.[18] An-Chow Lai and Babak Falsafi. Dead-block prediction& dead-block correlating prefetchers. In Proc. of the 28th In-ternational Symposium on Computer Architecture, 2001.[19] James E. Larus and M. Parkes. Using cohort schedulingto enhance server performance. In Proc. of the USENIX Tech-nical Conference, 2002.[20] Jack L. Lo, Luiz Andre Barroso, Susan J. Eggers,Kourosh Gharachorloo, Henry M. Levy, and Sujay S. Parekh.An analysis of database workload performance on simultane-ous multithreaded processors. In Proc. of the 25th Interna-tional Symposium on Computer Architecture, 1998.[21] Kyle J. Nesbit and James E. Smith. Data cache prefetchingusing a global history buffer. In Proc. of the Tenth IEEE Sympo-sium on High-Performance Computer Architecture, 2004.[22] Timothy Sherwood, Suleyman Sair, and Brad Calder.Predictor-directed stream buffers. In Proc. of the 33rd IEEE/ACM International Symposium on Microarchitecture (MI-CRO 33), 2000.[23] Yan Solihin, Jaejin Lee, and Josep Torrellas. Using a user-level memory thread for correlation prefetching. In Proc. of the29th International Symposium on Computer Architecture, 2002.[24] Stephen Somogyi, Thomas F. Wenisch, Anastassia Aila-maki, Babak Falsafi, and Andreas Moshovos. Spatial memorystreaming. In Proc. of the 33rd International Symposium onComputer Architecture, 2006.[25] Pedro Trancoso, Josep-L. Larriba-Pey, Zheng Zhang,and Josep Torellas. The memory performance of DSS com-mercial workloads in shared-memory multiprocessors. InProc. of the Third IEEE Symposium on High-PerformanceComputer Architecture, 1997.[26] Thomas F. Wenisch, Michael Ferdman, Anastasia Aila-maki, Babak Falsafi, and Andreas Moshovos. Temporalstreams in commercial server applications. In IEEE Interna-tional Symposium on Workload Characterization, 2008.[27] Thomas F. Wenisch, Stephen Somogyi, Nikolaos Hardav-ellas, Jangwoo Kim, Anastassia Ailamaki, and Babak Falsafi.Temporal streaming of shared memory. In Proc. of the 32nd In-ternational Symposium on Computer Architecture, 2005.[28] Thomas F. Wenisch, Roland E. Wunderlich, MichaelFerdman, Anastassia Ailamaki, Babak Falsafi, and James C.Hoe. SimFlex: statistical sampling of computer system simu-lation. IEEE Micro, 26(4):18–31, 2006.[29] Chengqiang Zhang and Sally A. McKee. Hardware-onlystream prefetching and dynamic access ordering. In Proc. ofthe 14th International Conf. on Supercomputing, 2000.