The non-critical buffer Using load latency tolerance to improve data cache efficiency

The Non-Critical Buffer:Using Load Latency Toleranceto Improve Data Cache EfficiencyBrian R.Fisk and R.Iris BaharDivision of Engineering,Brown University,Providence,RI02912Email:brf@,iris@AbstractData cache performance is critical to overall proces-sor performance as the latency gap between CPU core andmain memory increases.Studies have shown that someloads have latency demands that allow them to be servicedfrom slower portions of memory,thus allowing more criticaldata to be kept in higher levels of the cache.We provide astrategy for identifying this latency-tolerant data at runtimeand,using simple heuristics,keep it out of the main cacheand place it instead in a small,parallel,associative buffer.Using such a“Non-Critical Buffer”dramatically improvesthe hit rate for more critical data,and leads to a perfor-mance improvement comparable to or better than other tra-ditional cache improvement schemes.IPC improvements ofover4%are seen for some benchmarks.1.IntroductionThe performance increase of today's high-end micro-processors is due to many factors,among them is the useof speculative,out-of-order execution with highly accu-rate branch prediction.Branch prediction has increasedinstruction-level parallelism(ILP)by allowing programs tospeculatively execute beyond control boundaries,while out-of-order execution has increased ILP by allowing moreflex-ibility in instruction issue and execution.The combinationof these techniques has increased processor performance inpart by hiding the memory latency penalty in the case of acache miss;instructions without data dependencies on thecache miss instruction may execute while the miss is beingserviced,thus sustaining higher processor throughput.Hiding memory latency has become particularly criti-cal in the past few years as CPU performance has beenincreasing faster than memory access technologies havebeen improving.This large and increasing gap betweenthe CPU and memory means that a larger number of in-Similarly,if a data access is initiated far enough in advance, it may be serviced by lower levels of the memory hierarchy without affecting performance.Relegating this“latency-tolerant”data to slower portions of memory mitigates the problem of having a limited sizedfirst-level cache by re-serving precious cache entries for the less tolerant and/or more frequently accessed data.High-speed caches are often direct-mapped,despite the fact that direct-mapped caches often suffer from conflict misses.To alleviate this problem,a small associative buffer may be used in parallel with thefirst-level data cache(such as the victim cache[10]or non-temporal buffer[11]cited earlier).These strategies often use this cache as a“trash buffer”for data that is deemed less useful than some other competing data,but may still be required by the processor at some point.In this work,we propose using this buffer to hold data for non-critical,latency-tolerant loads while leaving the more critical data in the high-speed main cache. The non-critical data is identified during execution,when the data access misses in thefirst-level cache,so that the fill data may be prevented from being written into the main cache.In this study we use a cycle-level simulator of an8-issue, speculative,out-of-order processor to evaluate the effective-ness of our Non-Critical Buffer(NCB)scheme compared to other more traditional caching strategies.We make the fol-lowing contributions:We propose various strategies for detecting non-critical data in real time and develop policies to keep this data out of the mainfirst level data cache.We show that using the Non-Critical Buffer results ina performance improvement that is usually better thanusing traditional caching schemes.We show that when the Non-Critical Buffer is used, overallfirst-level cache miss rates may actually in-crease while overall performance remains the same or improves.This lends support to the idea that the cache is being used more efficiently.2.Background and prior work2.1.Associative cachesAs mentioned in Section1,cache performance may be improved by the use of a buffer alongside thefirst-level caches[10,9,11,14,8,3].The buffer is a small cache(e.g., between8–16entries)located between thefirst level and second level caches.The buffer may be used to hold spe-cific data(e.g.non-temporal or speculative data),or may be used for general data(e.g.“victim”data).One side-effect of the buffer is that it may prevent useful data from being displaced by less useful data,thereby reducing“cache pol-lution”effects.Figure1shows the design of the memory hierarchy when using a buffer alongside thefirst level data cache.Also included in thefigure is a representation of the five main stages found in a speculative out-of-order execu-tion processor.Note that the instruction cache access occurs in the fetch stage while the data cache access occurs in the issue stage for a load operation and the commit stage for a store operation.An instruction may spend more than one cycle in any of thesefive stages depending on the type of instruction,data dependencies,and cache hit outcome.UnifiedL2 cacheL1DataCachedL1 bufferdata accessinstructionaccessfromProcessorL1Inst.Cache(dL1)(iL1)Figure1.Memory hierarchy design using abuffer alongside thefirst-level data cache.In the case of the victim cache[10],on a main cache miss,the victim cache is accessed.If the address hits in the victim cache,then the data is returned to the CPU,and the block is simultaneously swapped with an appropriate block in the main cache.If the address also misses in the victim cache,the data is retrieved from second-level cache (L2)and placed in the mainfirst-level data cache.The dis-placed block in the main cache is then placed in the vic-tim cache;this victim cache block is written back to L2if dirty and then discarded.Jouppi showed that a small vic-tim buffer provided performance comparable to a2-way set-associative cache.However,his analysis did not use a full simulation model to measure impact on processor perfor-mance,nor did it account for the impact of the swap tying up the caches.Other work explores cache bypassing techniques to re-duce pollution,where the L1cache is bypassed on some load misses.In[14],Tyson proposed a method for selec-tively allocating space in thefirst level data cache(DL1) based on the characteristics of individual load instructions. They showed that there was a marked reduction in mem-ory bandwidth requirements due to a reduction in DL1pol-lution.A more rigorous experimental method was used in subsequent papers on bypassing for cache pollution to show overall performance improvement.Johnson[9]used a full system simulator/emulator to measure the system-level ef-fects of bypassing the DL1with the aid of a buffer.The buffer stored data which was deemed“short term”in terms of its temporal characteristics.Johnson showed up to a 10%improvement in overall system performance.Sim-ilarly,Rivers and Davidson implemented a small,fully-associative“non-temporal streaming(NTS)cache”in paral-lel with the DL1[11].This cache was used for blocks with a history of non-temporal behavior,keeping often-reused data in the regular DL1cache.The NTS cache usually pro-vided a2-3%performance improvement.John and Subra-manian[8]used a different strategy to determine locality in their annex cache,putting all newfills(due to load misses) into the annex cache and promoting them to the main cache upon reads.Finally,the work of Bahar et al.proposed us-ing a buffer to hold“speculative data”that was determined to have a high probability of being from a mis-speculated path[3].The main cache was then targeted to hold only those blocks of data determined to be non-speculative,thus reducing pollution in the main cache.An alternative to using an associative cache is to use hashing functions on the index bits.This technique is used in the hash-rehash cache[1],the column-associative cache[2],and the skewed-associative cache[12].2.2.Measuring latency toleranceThe main inspiration for this project comes from the re-search of Srinivasan and Lebeck[13],who showed that a large portion of loads do not need to be serviced immedi-ately,and some may be delayed up to32cycles or more before they are needed by other instructions.They also showed that up to36%of loads miss in the L1cache,even though they have shorter latency requirements than L2ac-cess times.Furthermore,up to37%of loads are serviced in thefirst-level cache,although they have enough latency tolerance to be satisfied by lower levels of the memory hi-erarchy.There is an implication here that,if these latency-tolerant instructions were instead stored in a separate“non-critical”buffer,then more critical instructions will remain in the cache,perhaps providing a solution to each of these problems.To quantify load latency tolerance,Srinivasan and Lebeck equipped their simulated processor with“rollback”capabilities in order to arbitrarily complete loads when they were needed.Loads were allowed to remain outstand-ing until their simulator determined that a load result was needed by another instruction.At this point,the state of the processor was rolled back,the load was allowed to complete at the required time,and execution resumed.This allowed the authors to determine just how long any particular load could be allowed to remain outstanding.A large portion of their research was devoted to deter-mining when a load should be completed.For instance,they discovered that if a branch is(directly or indirectly)depen-dent on the load then this load should be completed as soon as possible.Alternatively,if overall processor performance is degrading(such as the number of functional units used, or the number of new instructions ready for issue per cycle), then there are probably several instructions dependent on an outstanding load,which needs to be completed.Obviously these rollback facilities would be impossible to implement in a real processor.Instead,our experiments attempt to use their observations in implementing a new cache configuration scheme that adapts to load latency tol-erance(or alternatively,to data“criticality”).We do not attempt to determine a load's latency tolerance ahead of time.Instead we try to determine its criticality over the course of any cache miss that occurs.We have two methods of measuring and adapting to load data criticality: 1.Keeping track of the overall performance of the pro-cessor,and2.Counting the number of dependencies added to theload's dependency chain over the course of the miss.In thefirst method,we issue loads as usual,and if they miss in the cache,while the miss is being serviced we mea-sure performance degradation by monitoring issue rate or functional unit usage.If processor performance degrada-tion is determined,the load is marked critical and placed in the main cache when thefill is received from lower level memory(allowing for fast access of this data the next time it's requested).If the load is determined not to be critical,it is placed in the Non-Critical Buffer(NCB).We make the as-sumption that the next access to the data will be made with a similar processor state.If the data is still in the NCB at the next request,then the fast access may be taken advantage of. However,since the data is(theoretically)latency-tolerant,if it has been replaced in the NCB,little harm should be done.Our second strategy for measuring criticality involves following the dependency graph for each load while it is outstanding.We track the number of dependencies on the load's dependency graph over the course of its time in the Load/Store Queue(LSQ)as well as over the course of the miss.A load is considered critical if more than a given num-ber instructions are attached to the load during the time the miss is being serviced.We consider changes in the depen-dency chain only during the time of the miss since we only have control of the cachefill strategy and not over the LSQ. This strategy tends to perform better than thefirst strategy outlined above,but would require more hardware to imple-ment.More details on the use and implementation of the Non-Critical Buffer are given Section3.3.Experimental methodologyThis section presents our experimental environment.First,the CPU simulator will be briefly introduced and thenwe will describe the Non-Critical Buffer(NCB)in more de-tail,how it is accessed as part of the memory hierarchy and the various schemes we used to determine what is latencytolerant data(and therefore earmarked for the NCB).3.1.Full simulator modelWe use an extension of the S IMPLE S CALAR[5]toolsuite.S IMPLE S CALAR is an execution-driven simulatorthat uses binaries compiled to a MIPS-like target.S IM-PLE S CALAR can accurately model a high-performance, dynamically-scheduled,multi-issue processor.We use anextended version of the simulator that more accurately mod-els all the memory hierarchy,implementing non-blocking caches and more precise modeling of cachefills.The model implements out-of-order execution usinga Register Update Unit(RUU)and a Load/Store Queue(LSQ).The RUU acts as a combined instruction window, array of reservation stations,and reorder buffer.The LSQ holds all pending load and store instructions until they are ready to be sent to the data cache.Among other things,the LSQ must check for load/store dependencies and prevent loads from executing before stores in certain cases.The simulated processor featuresfive pipeline stages:Fetch:Fetch new instructions from the the instruction cache and prepare them for decoding.Dispatch:Decode instructions and allocate RUU and LSQ entries.Issue/Execute:Insert ready instructions into a ready queue,and issue instructions from the queue to avail-able functional units.Writeback:Forward results back to dependent in-structions in the RUU.Commit:Commit results to the registerfile in pro-gram order,and free RUU and LSQ entries.Table1shows the configuration of the processor mod-eled.Note thatfirst level caches are on-chip,while theunified second level cache is off-chip(thus having a muchhigher latency).In addition we have an16-entry fully-associative buffer associated with eachfirst level data cache. Note that the ALU resources listed in Table1may incur different latency and occupancy values depending on the type of operation being performed by the unit.Although an8KB L1cache may seem small by today's standards for a high-performance processor,the SPEC95benchmarks we use for our experiments tend to use a small data set.There-fore,we use a smaller cache to obtain reasonable hit/miss rates.Our baseline processor featured mostly unlimited re-sources,aside from the memory subsystem,in order to try and isolate the effects of the cache on overall performance.Our simulations are executed on SPECint95and SPECfp95benchmarks[6];they were compiled using a re-targeted version of the GNU gcc compiler,with full op-timization.This compiler generates S IMPLE S CALAR ma-chine instructions.Since we are executing a full model on a a very detailed simulator,the benchmarks take several hours to complete;due to time constraints we feed the simula-tor with a small set of inputs.Integer benchmarks(except for go)are executed to completion.Benchmark go and the floating point benchmarks are simulated only for thefirst 600million instructions decoded.Since we want to delay the decision to writefill data to the main data cache or the NCB until after the effects of the miss are known,a method of keeping track of the outstand-ing misses is needed.To provide this service each of the caches may be equipped with a set of“Miss Status Holding Registers”(MSHRs).Upon a miss,the MSHRs are updated with the address that missed.On each cycle,the MSHRs are checked to see if afill has be received from lower-level memory.If so,a cache is chosen(NCB orfirst-level data cache)using the desiredfill strategy and thefill is placed in the appropriate block of that cache.Note that it is now pos-sible for an access to hit a block that has a miss outstanding. While these accesses have a latency greater than the cache access time,in our experiments this is counted as a hit for compatibility with the original S IMPLE S CALAR code.3.2.Non-swapping victim cacheIn order to compare the NCB performance to estab-lished caching strategies,we also implemented a variant of Jouppi's victim cache with some slight changes.First,we access both the main and victim cache in parallel rather than sequentially.Second,our victim buffer is non-swapping, meaning that hits in the victim buffer are not promoted back to the main cache.Prior work[4]has shown that a non-swapping victim buffer performs as well as or better than a swapping victim cache,since the caches are never tied up for extra cycles in order to swap the data.In[10],the data cache of a single issue processor was considered,where a memory access occurs approximately one out of every four cycles;thus the victim cache had ample time to perform swapping.A modern4-issue processor has an average of one data memory access per cycle,and tying up the caches to swap is detrimental to performance.In addition,this scheme should be simpler to implement in hardware than one that implements swapping.Table1.Machine configuration and processor resources.L1Icache8KB direct;32B line;1cycleL1Dcache8KB direct;32B line;1cycleL2Cache256KB4-way;64B line;12cycleMemory128bit-wide;20cycles on hit,50cycles on page missBranch Pred.2k gshare+2k bimodal+2k metaBTB1024entry4-way set assoc.RAS32entry queueITLB32entry fully assoc.DTLB64entry fully assoc.Parameter Units3.3.Implementation of the non-critical bufferSimilar to a victim cache,our Non-Critical Buffer is a small(16-entry),fully-associative buffer that is accessed in parallel with the mainfirst-level data cache.Access time of the NCB is the same as the main cache(i.e.1cycle).Unlike the victim cache,the NCB uses an activefill mechanism to dynamically determine whether to place newfills into the main cache(“critical data”)or the NCB(“non-critical data”)during program execution.Ourfirst scheme for using the NCB tracks processor per-formance over the past few cycles and uses this information for determining criticality.To record the processor perfor-mance,a simple shift register is used.A particular perfor-mance metric is chosen,such as functional unit utilization, or instruction issue rate.In this context“issue rate”repre-sents the number of new instructions ready to be issued to functional units.On each cycle,if the processor is“busy”enough(for example,more than some user-defined thresh-old of functional units are being used),then a value of1 is shifted into the register.Upon a cache miss,when a de-cision needs to be made about where to place thefill,the number of1's in the register is counted and,if it is greater than another user-defined threshold,the data is placed in the NCB.In our experiments we varied the threshold for shift-ing a1into the register,as well as the history length and the number of1's required in the shift register for a load to be considered critical.Our second scheme for using the NCB tracks the number of instructions added to the instruction window that are de-pendent on a given memory operation.The number of data dependencies are referenced at two different points over the lifetime of a memory operation:immediately before a cache access and during a cache miss.These statistics can be tab-ulated separately for hits and misses.In a hardware im-plementation,this scheme might involve a counter for each LSQ entry that is incremented with each new dependency, as well as an identical counter as part of each MSHR(for counting during misses).The dependency-based NCB scheme uses the cache miss dependency information to determine criticality:If the number of dependencies added is greater than a user-defined threshold,the data is deemed critical and placed in the main cache.Otherwise,the data is placed in the NCB. In addition,Srinivasan and Lebeck[13]showed that hav-ing a branch dependent on a load should mark the data as highly latency intolerant,or very critical.If this occurs,the data is marked critical regardless of the number of depen-dencies added during a cache miss(since it is possible that the branch was added before the actual cache access).4.Experimental results4.1.Base caseIn this section we will describe the base case we used for our initial experiments and the baseline results.All other experiments are compared to this one.Table2.Base case results:Results using an8KB direct-mappedfirst-level data cache.18.51810.8614compress 1.95327.44 4.08063.5942 3.3705ijpeg 2.5738 3.36 5.611111.71900.7225mgrid 4.6990 4.93 6.2080Table3.Traditional Techniques:Columns labeled%IPC and refer to percent change from base case.Negative percentages indicate a decrease in IPC or an increase in cache miss rate.Columns labeled,and refer to raw changes in numbers.Test%IPC%IPCapplu0.46820.4360.0130.47318.0900.085-0.666-0.537-0.623-0.434 go 2.08446.030-0.017 1.67136.784-0.090-0.256-0.703-0.305-0.650 li 1.65826.893-0.041 1.51824.8040.024-0.099-0.451-0.089-0.446(),and the average number of added during a load's time in the LSQ on a cache hit().We see from this table that the benchmarks vary widely in cache miss rate,LSQ occupancy and the average number of dependencies.Of particular note is the relatively high number of dependencies added during the time the memory access is in the LSQ(prior to actual cache access),, compared to the average number added during a cache miss, .Note that only represents dependencies added during the time in the LSQ,prior to a cache hit.These val-ues give an indication of the overhead of making a mem-ory access,and indicate that,in general,many dependen-cies are added to a load's dependency chain before the ac-tual cache access is even attempted.Our caching technique has no control over this LSQ behavior,but it still shows an improvement in performance.Further enhancement may better address this LSQ problem for an even greater perfor-mance improvement.4.2.Traditional techniquesTraditional approaches for improving processor perfor-mance(particularly IPC)aim to reduce the number of cache misses.Aside from increasing the size of the cache(which is not examined here),associativity may be added to the cache or a traditional victim buffer may be used.These techniques often offer good performance improvements by reducingfirst-level cache miss rates.As these methods have been actually implemented in industry designs for some time now,any new caching strategy should at least be com-parable with these tried-and-true methods.Table3presents results obtained by either changing the cache associativity to a2-way associative cache,or by adding a16-entry,fully-associative,non-swapping victim buffer to the base case configuration.Each cache retains its one cycle access latency.As expected,IPC improves across all benchmarks,varying from a0.5%improvement for ap-plu to2.5%for compress.Overall DL1miss rates also improve,by up to46%for go using a2-way associative cache and up to37%using a victim cache(note that,for the purpose of computing DL1 miss rate with an extra associative buffer,a“miss”occurs when data misses in both the main cache as well as the as-sociative buffer).Since a load or store remains in the LSQ until the memory access is completely serviced,it is not surprising that the average LSQ occupancy decreases with improved cache hit rate.Changes in dependencies are rel-atively small because these strategies do not attempt to di-rectly address any dependency issues.4.3.Non-critical bufferThe Non-Critical Buffer is used as part of an active cache management strategy that does not necessarily attempt to reduce cache miss rate,but instead makes sure that the most critical data is retained in the cache.Less critical data may miss more often,resulting in higher overall miss rates,but the performance gains from keeping the critical data in the cache outweigh these penalties.Table4shows results when using an NCB with pro-cessor performance history as the criticality metric.We used several different configurations in our experiments;the best-performing configuration is shown in the table.Ta-ble5presents results obtained when using the dependency-counting heuristic for measuring criticality.Several conclusions can be immediately drawn from these results.First,both NCB schemes are improving IPC values over the base case.IPC improvements are better than or comparable to improvements seen when using a2-way associative or victim cache,and substantially better in the case of compress.In general,using the dependency count-ing scheme provides better performance improvements than the history scheme.The best results(shown in Table5)were obtained for a criticality threshold of1or more dependen-cies added during a miss.That is,if any instructions are dependent on the load,it should be considered critical.WeTable4.NCB with History Measurement:Percent improvement compared to the base case when using a Non-Critical Buffer and using recent performance history as a criticality metric.History length=6cycles,Busy Threshold=6,Critical threshold=3or fewer.Test%IPC%IPCapplu0.535-11.558-0.0020.556-5.8630.116-0.605-0.617-0.604-0.599 go 1.42028.744-0.009 1.42028.945-0.016-0.141-0.493-0.132-0.462 li 1.00718.2770.068 1.06618.5380.073-0.0790.001-0.089-0.021Table 5.NCB with Dependency Measure-ment:Percent improvement compared to thebase case when using a Non-Critical Bufferand using number of dependencies addedduring a cache miss as a criticality metric.Threshold for criticality is one or more de-pendencies added during a miss.0.347-0.385compress 4.413 2.554 2.186-0.440-0.177ijpeg 1.671-20.238-0.164-0.341-0.186mgrid 1.594-16.633-0.065stantially reduced in most cases.Coupled with significant cache miss rate improvements,this may suggest that the his-tory algorithm is too random,and the NCB is effectively only adding associativity to the cache.The algorithm can only count1's in the shift register,and cannot distinguish between different patterns of1's and0's.This may be an issue because“111000”has different implications for per-formance trends than“101010”.However,the performance history strategy is almost certainly easier to implement in hardware than tracking dependencies,as it simply consists of a shift register and logic to count the number of high values in the register.The dependency method would re-quire more complex hardware to count new dependencies added during a cache miss.However,the clearer perfor-mance gains using this strategy may make it worthwhile.5.ConclusionThis paper explores several ways to exploit load latency tolerance in a dynamically scheduled processor.We show that dependency information during a cache miss can be used to determine a load's criticality.A small,associative, Non-Critical Buffer in parallel with the main data cache may be used as an insurance policy against a future cache miss if the data is deemed non-critical,rather than bypass-ing the data cache ing the NCB results in a per-formance improvement comparable to or better than tradi-tional caching techniques.A simple shift register containing a local history of pro-cessor performance does not appear to be the best way to determine criticality.Counting the number of instructions dependent on a load is a better metric,and using this infor-mation as a criticality measurement with the NCB scheme may lead to more(but less critical)cache misses.The shift register history method may not perform as well,but is at-tractive due to its comparatively low hardware implementa-tion cost.A more intelligent method for analyzing data in the history register may lead to improved results.There are several areas open to future work.First,more research needs to be done to investigate the growth of the dependency chain during an instruction's lifetime in the LSQ,prior to cache access,and how it may be affecting this NCB technique.Second,there may be further improve-ments to the dependency-based NCB scheme to increase performance.Finally,while the S IMPLE S CALAR simula-tor features a very reasonable approximation of a memory subsystem,implementing the NCB scheme in a simulator with a more robust memory model could yield substantially different results.Acknowledgements:The authors would like to thank Dirk Grunwald for his generosity in donating spare CPU cycles for many of our simulations.We would also like to thank the anonymous reviewers for their valuable com-ments.References[1] A.Agarwal,J.Hennessy,and M.Horowitz.Cache perfor-mance of operating systems and multiprogramming work-loads.ACM Transactions on Computer Systems,6:393–431,November1988.[2] A.Agarwal and S.D.Pudar.Column-associative caches:A technique for reducing the miss rate of direct-mappedcaches.In26th Annual International Symposium on Mi-croarchitecture,pages179–190.IEEE/ACM,December1993.[3]R.I.Bahar,G.Albera,and ing confidence toreduce energy consumption in high-performance micropro-cessors.In Int.Symposium on Low Power Electronics andDesign,pages64–69.IEEE/ACM,August1998.[4]R.I.Bahar,D.Grunwald,and B.Calder.A comparison ofsoftware code reordering and victim buffers.In ComputerArchitecture News.ACM SIGARCH,March1999.[5] D.C.Burger,T.M.Austin,and S.Bennett.Evaluating fu-ture microprocessors–the SIMPLESCALAR toolset.Techni-cal Report1308,University of Wisconsin–Madison,Com-puter Sciences Department,July1996.[6]J.Gee,M.Hill,D.Pnevmatikatos,and A.J.Smith.Cacheperformance of the SPEC benchmark suite.IEEE Micro,13(4):17–27,August1993.[7]L.Gwennap.Digital21264sets new standard.In Micro-processor Report.MicroDesign Resources,October1996./semiconductor/microrep/digital2.htm.[8]L.K.John and S.A.Design and performance evaluationof a cache assist to implement selective caching.In Inter-national Conference on Computer Design,pages510–518.IEEE,October1997.[9]T.L.Johnson and W.-m.W.Hwu.Run-time adaptive cachehierarchy management via reference analysis.In24th An-nual International Symposium on Computer Architecture,pages315–326.IEEE/ACM,June1997.[10]N.P.Jouppi.Improving direct-mapped cache perfor-mance by the addition of a small fully-associative cache andprefetch buffers.In17th Annual International Symposiumon Computer Architecture.IEEE/ACM,June1990.[11]J.A.Rivers and E.S.Davidson.Reducing conflicts in direct-mapped caches with a temporality-based design.In Interna-tional Conference on Parallel Processing,pages154–163,August1996.[12] A.Seznec.A case for two-way skewed-associative caches.In20th Annual International Symposium on Computer Ar-chitecture,pages169–178.IEEE/ACM,May1993.[13]S.T.Srinivasan and A.R.Lebeck.Load latency tolerancein dynamically scheduled processors.In31st Annual Inter-national Symposium on Microarchitecture.IEEE/ACM,De-cember1998.[14]G.Tyson,M.Farrens,J.Matthews,and A.R.Pleszkun.Managing data caches using selective cache line replace-ment.Journal of Parallel Programming,25(3):213–242,June1997.。