DOCSLIB.ORG

Copyright by Onur Mutlu 2006 the Dissertation Committee for Onur Mutlu Certifies That This Is the Approved Version of the Following Dissertation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Copyright by Onur Mutlu 2006 the Dissertation Committee for Onur Mutlu Certifies That This Is the Approved Version of the Following Dissertation Copyright by Onur Mutlu 2006 The Dissertation Committee for Onur Mutlu certifies that this is the approved version of the following dissertation: Efficient Runahead Execution Processors Committee: Yale N. Patt, Supervisor Craig M. Chase Nur A. Touba Derek Chiou Michael C. Shebanow Efficient Runahead Execution Processors by Onur Mutlu, B.S.; B.S.E.; M.S.E. DISSERTATION Presented to the Faculty of the Graduate School of The University of Texas at Austin in Partial Fulfillment of the Requirements for the Degree of DOCTOR OF PHILOSOPHY THE UNIVERSITY OF TEXAS AT AUSTIN August 2006 Dedicated to my loving parents, Hikmet and Nevzat Mutlu, and my sister Miray Mutlu Acknowledgments Many people and organizations have contributed to this dissertation, intellectually, motivationally, or otherwise financially. This is my attempt to acknowledge their contribu- tions. First of all, I thank my advisor, Yale Patt, for providing me with the freedom and resources to do high-quality research, for being a caring teacher, and also for teaching me the fundamentals of computing in EECS 100 as well as valuable lessons in real-life areas beyond computing. My life as a graduate student life would have been very short and unproductive, had it not been for Hyesoon Kim. Her technical insights and creativity, analytical and questioning skills, high standards for research, and continuous encouragement made the contents of this dissertation much stronger and clearer. Her presence and support made even the Central Texas climate feel refreshing. Very special thanks to David Armstrong, who provided me with the inspiration to write and publish, both technically and otherwise, at a time when it was difficult for me to do so. To me, he is an example of fairness, tolerance, and open-mindedness in an all-too- unfair world. Many members of the HPS Research Group have contributed to this dissertation and my life in the past six years. I especially thank: • Jose´ Joao and Angel´ es Juarans Font, for our memorable trips and delicious barbe- cues, for their hearty friendship, and for proofreading this dissertation. v • Chang Joo Lee, for always being a source of fun and optimism, and for bearing with my humor and complaints. • Moinuddin Qureshi, for many interesting technical discussions and being my room- mate during the last year. • Santhosh Srinath, for being a very good and cheerful friend. • Francis Tseng, for his helpfulness and hard work in maintaining our group's network and simulation infrastructure. • Danny Lynch, Aater Suleman, Mary Brown, Sangwook Peter Kim, Kameswar Sub- ramaniam, David Thompson, Robert Chappell, and Paul Racunas for their contribu- tions to our group's simulation infrastructure and for their friendship. Many people in computer industry have helped shape my career and provided in- valuable feedback on my research. I especially thank Jared Stark and Eric Sprangle for their mentorship and assistance in developing research ideas. They strongly influenced my first years as a researcher and I am honored to have them as co-authors in my first schol- arly paper and patent. Stephan Meier, Chris Wilkerson, Konrad Lai, Mike Butler, Nhon Quach, Mike Fertig, and Chuck Moore provided valuable comments and suggestions on my research activities and directions. I would like to thank Derek Chiou, Nur Touba, Michael Shebanow, and Craig Chase for serving on my dissertation committee. Special thanks to Derek for he has always been accessible, encouraging, and supportive. Throughout graduate school, I have had generous financial support from several organizations. I would like to thank the University of Texas Graduate School for the Uni- versity Continuing Fellowship, and Intel Corporation for the Intel Foundation PhD Fellow- ship. I also thank the University Co-op for awarding me the George H. Mitchell Award for vi Excellence in Graduate Research. Many thanks to Intel Corporation and Advanced Micro Devices for providing me with summer internships, which were invaluable for my research career. Finally, I cannot express with words my indebtedness to my parents, and Hikmet and Nevzat Mutlu, and my little sister Miray Mutlu, for giving me their unconditional love and support at every step I have taken in my life. Even though they will likely not understand much of it, this dissertation would be meaningless without them. Onur Mutlu May 2006, Austin, TX vii Efficient Runahead Execution Processors Publication No. Onur Mutlu, Ph.D. The University of Texas at Austin, 2006 Supervisor: Yale N. Patt High-performance processors tolerate latency using out-of-order execution. Unfor- tunately, today's processors are facing memory latencies in the order of hundreds of cycles. To tolerate such long latencies, out-of-order execution requires an instruction window that is unreasonably large, in terms of design complexity, hardware cost, and power consump- tion. Therefore, current processors spend most of their execution time stalling and waiting for long-latency cache misses to return from main memory. And, the problem is getting worse because memory latencies are increasing in terms of processor cycles. The runahead execution paradigm improves the memory latency tolerance of an out-of-order execution processor by performing potentially useful execution while a long- latency cache miss is in progress. Runahead execution unblocks the instruction window blocked by a long-latency cache miss allowing the processor to execute far ahead in the program path. This results in other long-latency cache misses to be discovered and their data to be prefetched into caches long before it is needed. This dissertation presents the runahead execution paradigm and its implementation on an out-of-order execution processor that employs state-of-the-art hardware prefetching viii techniques. It is shown that runahead execution on a 128-entry instruction window achieves the performance of a processor with three times the instruction window size for a current, 500-cycle memory latency. For a near-future 1000-cycle memory latency, it is shown that runahead execution on a 128-entry window achieves the performance of a conventional pro- cessor with eight times the instruction window size, without requiring a significant increase in hardware cost and complexity. This dissertation also examines and provides solutions to two major limitations of runahead execution: its energy inefficiency and its inability to parallelize dependent cache misses. Simple and effective techniques are proposed to increase the efficiency of runahead execution by reducing the extra instructions executed without affecting the performance improvement. An efficient runahead execution processor employing these techniques ex- ecutes only 6.2% more instructions than a conventional out-of-order execution processor but achieves 22.1% higher Instructions Per Cycle (IPC) performance. Finally, this dissertation proposes a new technique, called address-value delta (AVD) prediction, that predicts the values of pointer load instructions encountered in runahead ex- ecution in order to enable the parallelization of dependent cache misses using runahead execution. It is shown that a simple 16-entry AVD predictor improves the performance of a baseline runahead execution processor by 14.3% on a set of pointer-intensive applications, while it also reduces the executed instructions by 15.5%. An analysis of the high-level pro- gramming constructs that result in AVD-predictable load instructions is provided. Based on this analysis, hardware and software optimizations are proposed to increase the benefits of AVD prediction. ix Table of Contents Acknowledgments vi Abstract ix List of Tables xvii List of Figures xviii Chapter 1. Introduction 1 1.1 The Problem: Tolerating Long Main Memory Latencies . 1 1.2 The Solution: Efficient Runahead Execution . 3 1.3 Thesis Statement . 5 1.4 Contributions . 5 1.5 Dissertation Organization . 6 Chapter 2. The Runahead Execution Paradigm 8 2.1 The Basic Idea . 8 2.2 Out-of-Order Execution and Memory Latency Tolerance . 9 2.2.1 Instruction and Scheduling Windows . 9 2.2.2 Main-Memory Latency Tolerance of Out-of-Order Execution . 10 2.2.3 Why Runahead Execution: Providing Useful Work to the Processor During an L2 Cache Miss . 12 2.3 Operation of Runahead Execution . 13 2.4 Advantages, Disadvantages and Limitations of the Runahead Execution Paradigm . 15 2.4.1 Advantages . 16 2.4.2 Disadvantages . 18 2.4.3 Limitations . 19 2.5 Implementation of Runahead Execution in a State-of-the-art High Perfor- mance Out-of-order Processor . 20 x 2.5.1 Overview of the Baseline Microarchitecture . 21 2.5.2 Requirements for Runahead Execution . 22 2.5.3 Entering Runahead Mode . 23 2.5.3.1 When to Enter Runahead Mode . 23 2.5.3.2 Processor Actions for Runahead Mode Entry . 26 2.5.3.3 Hardware Requirements for Runahead Mode Entry . 26 2.5.4 Instruction Execution in Runahead Mode . 28 2.5.4.1 INV Bits and Instructions . 28 2.5.4.2 Propagation of INV Values . 29 2.5.4.3 Hardware Requirements to Support INV Bits and Their Prop- agation . 30 2.5.4.4 Runahead Store Operations and Runahead Cache . 30 2.5.4.5 Runahead Load Operations . 34 2.5.4.6 Hardware Requirements to Support Runahead Store and Load Operations . 35 2.5.4.7 Prediction and Execution of Runahead Branches . 36 2.5.4.8 Instruction Pseudo-Retirement in Runahead Mode . 38 2.5.4.9 Exceptions and Input/Output Operations in Runahead Mode 39 2.5.5 Exiting Runahead Mode . 40 2.5.5.1 When to Exit Runahead Mode . 40 2.5.5.2 Processor Actions for Runahead Mode Exit . 42 2.5.5.3 Hardware Requirements for Runahead Mode Exit . 43 2.5.6 Multiprocessor Issues . 44 2.5.6.1 Lock Operations . 44 2.5.6.2 Serializing Instructions . 45 Chapter 3. Background and Related Work 47 3.1 Related Research in Caching . 47 3.2 Related Research in Prefetching .
Load more

Recommended publications
  • Precise Runahead Execution
    2020 IEEE International Symposium on High Performance Computer Architecture (HPCA) Precise Runahead Execution Ajeya Naithani∗ Josue´ Feliu†‡ Almutaz Adileh∗ Lieven Eeckhout∗ ∗Ghent University, Belgium †Universitat Politecnica` de Valencia,` Spain Abstract—Runahead execution improves processor perfor- runahead mode, the higher the performance benefit of runahead mance by accurately prefetching long-latency memory accesses. execution. On the other hand, speculative code execution When a long-latency load causes the instruction window to fill up imposes overheads for saving and restoring state, and rolling and halt the pipeline, the processor enters runahead mode and keeps speculatively executing code to trigger accurate prefetches. the pipeline back to a proper state to resume normal operation A recent improvement tracks the chain of instructions that leads after runahead execution. The lower the performance penalty of to the long-latency load, stores it in a runahead buffer, and exe- these overheads, the higher the performance gain. Consequently, cutes only this chain during runahead execution, with the purpose maximizing the performance benefits of runahead execution of generating more prefetch requests. Unfortunately, all prior requires (1) maximizing the number of useful prefetches per runahead proposals have shortcomings that limit performance and energy efficiency because they release processor state when runahead interval, and (2) limiting the switching overhead entering runahead mode and then need to re-fill the pipeline between runahead mode and normal execution. We find to restart normal operation. Moreover, runahead buffer limits that prior attempts to optimize the performance of runahead prefetch coverage by tracking only a single chain of instructions execution have shortcomings that impede them from adequately that leads to the same long-latency load.
    [Show full text]
  • Runahead Execution
    18-447 Computer Architecture Lecture 26: Runahead Execution Prof. Onur Mutlu Carnegie Mellon University Spring 2014, 4/7/2014 Today Start Memory Latency Tolerance Runahead Execution Prefetching 2 Readings Required Mutlu et al., “Runahead execution”, HPCA 2003. Srinath et al., “Feedback directed prefetching”, HPCA 2007. Optional Mutlu et al., “Efficient Runahead Execution: Power-Efficient Memory Latency Tolerance,” ISCA 2005, IEEE Micro Top Picks 2006. Mutlu et al., “Address-Value Delta (AVD) Prediction,” MICRO 2005. Armstrong et al., “Wrong Path Events,” MICRO 2004. 3 Tolerating Memory Latency Latency Tolerance An out-of-order execution processor tolerates latency of multi-cycle operations by executing independent instructions concurrently It does so by buffering instructions in reservation stations and reorder buffer Instruction window: Hardware resources needed to buffer all decoded but not yet retired/committed instructions What if an instruction takes 500 cycles? How large of an instruction window do we need to continue decoding? How many cycles of latency can OoO tolerate? 5 Stalls due to Long-Latency Instructions When a long-latency instruction is not complete, it blocks instruction retirement. Because we need to maintain precise exceptions Incoming instructions fill the instruction window (reorder buffer, reservation stations). Once the window is full, processor cannot place new instructions into the window. This is called a full-window stall. A full-window stall prevents the processor from making progress in the execution of the program. 6 Full-window Stall Example 8-entry instruction window: Oldest LOAD R1 mem[R5] L2 Miss! Takes 100s of cycles. BEQ R1, R0, target ADD R2 R2, 8 LOAD R3 mem[R2] Independent of the L2 miss, MUL R4 R4, R3 executed out of program order, ADD R4 R4, R5 but cannot be retired.
    [Show full text]
  • Rock:Ahigh-Performance Sparc Cmt Processor
    ......................................................................................................................................................................................................................... ROCK:AHIGH-PERFORMANCE SPARC CMT PROCESSOR ......................................................................................................................................................................................................................... ROCK,SUN’S THIRD-GENERATION CHIP-MULTITHREADING PROCESSOR, CONTAINS 16 HIGH-PERFORMANCE CORES, EACH OF WHICH CAN SUPPORT TWO SOFTWARE THREADS. ROCK USES A NOVEL CHECKPOINT-BASED ARCHITECTURE TO SUPPORT AUTOMATIC HARDWARE SCOUTING UNDER A LOAD MISS, SPECULATIVE OUT-OF-ORDER RETIREMENT OF INSTRUCTIONS, AND AGGRESSIVE DYNAMIC HARDWARE PARALLELIZATION OF A SEQUENTIAL INSTRUCTION STREAM.IT IS ALSO THE FIRST PROCESSOR TO SUPPORT TRANSACTIONAL MEMORY IN HARDWARE. ......Designing an aggressive chip- even more aggressive simultaneous speculative Shailender Chaudhry multithreaded (CMT) processor1 involves threading (SST), which uses two checkpoints. many tradeoffs. To maximize throughput EA is an area-efficient way of creating a large Robert Cypher performance, each processor core must be virtual issue window without the large asso- highly area and power efficient, so that ciative structures. SST dynamically extracts Magnus Ekman many cores can coexist on a single die. Simi- parallelism, letting execution proceed in par- larly, if the processor is to perform well on a allel at
    [Show full text]
  • Vector Runahead
    Vector Runahead Ajeya Naithaniy Sam Ainsworthz Timothy M. Joneso Lieven Eeckhouty yGhent University zUniversity of Edinburgh oUniversity of Cambridge Abstract—The memory wall places a significant limit on stride patterns, such techniques are endemic in today’s cache performance for many modern workloads. These applications systems [19]. For more complex indirection patterns, the feature complex chains of dependent, indirect memory accesses, inability at the cache-system level to identify complex load which cannot be picked up by even the most advanced microar- chitectural prefetchers. The result is that current out-of-order chains and generate their addresses limits existing techniques superscalar processors spend the majority of their time stalled. to simple array-indirect [88] and pointer-chasing [23] codes. While it is possible to build special-purpose architectures to To achieve the instruction-level visibility necessary to cal- exploit the fundamental memory-level parallelism, a microarchi- culate the addresses of complex access patterns seen in to- tectural technique to automatically improve their performance day’s workloads [3], we conclude that this ideal technique in conventional processors has remained elusive. Runahead execution is a tempting proposition for hiding must operate within the core, instead of within the cache. latency in program execution. However, to achieve high memory- Runahead execution [25, 32, 34, 57, 58, 64] is the most level parallelism, a standard runahead execution skips ahead of promising technique to date, where upon a memory stall cache misses. In modern workloads, this means it only prefetches at the head of the reorder buffer (ROB), execution enters the first cache-missing load in each dependent chain.
    [Show full text]
  • Efficient Runahead Execution: Power-Efficient Memory Latency Tolerance
    EFFICIENT RUNAHEAD EXECUTION: POWER-EFFICIENT MEMORY LATENCY TOLERANCE SEVERAL SIMPLE TECHNIQUES CAN MAKE RUNAHEAD EXECUTION MORE EFFICIENT BY REDUCING THE NUMBER OF INSTRUCTIONS EXECUTED AND THEREBY REDUCING THE ADDITIONAL ENERGY CONSUMPTION TYPICALLY ASSOCIATED WITH RUNAHEAD EXECUTION. Today’s high-performance processors ulatively processed (executed) instructions, face main-memory latencies on the order of sometimes without enhancing performance. hundreds of processor clock cycles. As a result, For runahead execution to be efficiently even the most aggressive processors spend a sig- implemented in current or future high-per- nificant portion of their execution time stalling formance processors which will be energy- and waiting for main-memory accesses to constrained, processor designers must develop return data to the execution core. Previous techniques to reduce these extra instructions. research has shown that runahead execution Our solution to this problem includes both significantly increases a high-performance hardware and software mechanisms that are processor’s ability to tolerate long main-mem- simple, implementable, and effective. Onur Mutlu ory latencies.1, 2 Runahead execution improves a processor’s performance by speculatively pre- Background on runahead execution Hyesoon Kim executing the application program while the Conventional out-of-order execution processor services a long-latency (L2) data processors use instruction windows to buffer Yale N. Patt cache miss, instead of stalling the processor for instructions so they can tolerate long latencies. the duration of the L2 miss. Thus, runahead Because a cache miss to main memory takes University of Texas at execution lets a processor execute instructions hundreds of processor cycles to service, a that it otherwise couldn’t execute under an L2 processor needs to buffer an unreasonably large Austin cache miss.
    [Show full text]
  • Onur-447-Spring12-Lecture23
    18-447: Computer Architecture Lecture 23: Tolerating Memory Latency II Prof. Onur Mutlu Carnegie Mellon University Spring 2012, 4/18/2012 Reminder: Lab Assignments Lab Assignment 6 Implementing a more realistic memory hierarchy L2 cache model DRAM, memory controller models MSHRs, multiple outstanding misses Due April 23 Extra credit: Prefetching 2 Last Lecture Memory latency tolerance/reduction Stalls Four fundamental techniques Software and hardware prefetching Prefetcher throttling 3 Today More prefetching Runahead execution 4 Readings Srinath et al., “Feedback directed prefetching ”, HPCA 2007. Mutlu et al., “Runahead execution ”, HPCA 2003. 5 Tolerating Memory Latency How Do We Tolerate Stalls Due to Memory? Two major approaches Reduce/eliminate stalls Tolerate the effect of a stall when it happens Four fundamental techniques to achieve these Caching Prefetching Multithreading Out-of-order execution Many techniques have been developed to make these four fundamental techniques more effective in tolerating memory latency 7 Prefetching Review: Prefetching: The Four Questions What What addresses to prefetch When When to initiate a prefetch request Where Where to place the prefetched data How Software, hardware, execution-based, cooperative 9 Review: Challenges in Prefetching: How Software prefetching ISA provides prefetch instructions Programmer or compiler inserts prefetch instructions (effort) Usually works well only for “regular access patterns ” Hardware prefetching Hardware monitors processor
    [Show full text]
  • Runahead Execution
    15-740/18-740 Computer Architecture Lecture 14: Runahead Execution Prof. Onur Mutlu Carnegie Mellon University Fall 2011, 10/12/2011 Reviews Due Today Chrysos and Emer, “Memory Dependence Prediction Using Store Sets ,” ISCA 1998. 2 Announcements Milestone I Due this Friday (Oct 14) Format: 2-pages Include results from your initial evaluations. We need to see good progress. Of course, the results need to make sense (i.e., you should be able to explain them) Midterm I Postponed to October 24 Milestone II Will be postponed. Stay tuned. 3 Course Checkpoint Homeworks Look at solutions These are not for grades. These are for you to test your understanding of the concepts and prepare for exams. Provide succinct and clear answers. Review sets Concise reviews Projects Most important part of the course Focus on this If you are struggling, talk with the TAs 4 Course Feedback Fill out the forms and return 5 Last Lecture Tag broadcast, wakeup+select loop Pentium Pro vs. Pentium 4 designs: buffer decoupling Consolidated physical register files in Pentium 4 and Alpha 21264 Centralized vs. distributed reservation stations Which instruction to select? 6 Today Load related instruction scheduling Runahead execution 7 Review: Centralized vs. Distributed Reservation Stations Centralized (monolithic): + Reservation stations not statically partitioned (can adapt to changes in instruction mix, e.g., 100% adds) -- All entries need to have all fields even though some fields might not be needed for some instructions (e.g. branches,
    [Show full text]
  • Configurable Simultaneously Single-Threaded (Multi-)Engine Processor
    Configurable Simultaneously Single-Threaded (Multi-)Engine Processor by Anita Tino Bachelor of Engineering (B.Eng), Ryerson University, 2009 Master of Applied Science (M.A.Sc), Ryerson University, 2011 A dissertation presented to Ryerson University in partial fulfilment of the requirements for the degree of Doctor of Philosophy in the program of Electrical and Computer Engineering Toronto, Ontario, Canada, 2017 c Anita Tino, 2017 AUTHOR'S DECLARATION FOR ELECTRONIC SUBMISSION OF A DISSERTATION I hereby declare that I am the sole author of this thesis dissertation. This is a true copy of the dissertation, including any required final revi- sions, as accepted by my examiners. I authorize Ryerson University to lend this dissertation to other institu- tions or individuals for the purpose of scholarly research. I further authorize Ryerson University to reproduce this dissertation by photocopying or by other means, in total or in part, at the request of other institutions or individuals for the purpose of scholarly research. I understand that my dissertation may be made electronically available to the public. -Anita Tino ii Configurable Simultaneously Single-Threaded (Multi-)Engine Processor Anita Tino Doctor of Philosophy, 2017, Electrical and Computer Engineering, Ryerson University Abstract As the multi-core computing era continues to progress, the need to increase single- thread performance, throughput, and seemingly adapt to thread-level parallelism (TLP) remain important issues. Though the number of cores on each processor continues to increase, expected performance gains have lagged. Accordingly, com- puting systems often include Simultaneously Multi-Threaded (SMT) processors as a compromise between sequential and parallel performance on a single core.
    [Show full text]
  • Runahead Execution a Short Retrospective
    Runahead Execution A Short Retrospective Onur Mutlu, Jared Stark, Chris Wilkerson, Yale Patt HPCA 2021 ToT Award Talk 2 March 2021 Agenda n Thanks n Runahead Execution n Looking to the Past n Looking to the Future Runahead Execution [HPCA 2003] n Onur Mutlu, Jared Stark, Chris Wilkerson, and Yale N. Patt, "Runahead Execution: An Alternative to Very Large Instruction Windows for Out-of-order Processors" Proceedings of the 9th International Symposium on High-Performance Computer Architecture (HPCA), Anaheim, CA, February 2003. Slides (pdf) One of the 15 computer architecture papers of 2003 selected as Top PicKs by IEEE Micro. 3 Small Windows: Full-Window Stalls 8-entry instruction window: Oldest LOAD R1 ß mem[R5] L2 Miss! Takes 100s oF cycles. BEQ R1, R0, target ADD R2 ß R2, 8 LOAD R3 ß mem[R2] Independent oF the L2 miss, MUL R4 ß R4, R3 executed out oF program order, ADD R4 ß R4, R5 but cannot be retired. STOR mem[R2] ß R4 ADD R2 ß R2, 64 Younger instructions cannot be executed LOAD R3 ß mem[R2] because there is no space in the instruction window. The processor stalls until the L2 Miss is serviced. n Long-latency cache misses are responsible for most full-window stalls. 4 Impact of Long-Latency Cache Misses 100 95 Non-stall (compute) time 90 85 80 Full-window stall time 75 70 65 60 55 50 45 40 35 30 25 L2 Misses 20 Normalized Execution Time Normalized Execution 15 10 5 0 128-entry window 512KB L2 cache, 500-cycle DRAM latency, aggressive stream-based prefetcher Data averaged over 147 memory-intensive benchmarks on a high-end x86 processor model 5 Impact of Long-Latency Cache Misses 100 95 Non-stall (compute) time 90 85 80 Full-window stall time 75 70 65 60 55 50 45 40 35 30 25 L2 Misses 20 Normalized Execution Time Normalized Execution 15 10 5 0 128-entry window 2048-entry window 512KB L2 cache, 500-cycle DRAM latency, aggressive stream-based prefetcher Data averaged over 147 memory-intensive benchmarks on a high-end x86 processor model 6 The Problem n Out-of-order execution requires large instruction windows to tolerate today’s main memory latencies.
    [Show full text]
  • Runahead Execution: an Alternative to Very Large Instruction Windows for Out-Of-Order Processors
    Runahead Execution: An Alternative to Very Large Instruction Windows for Out-of-order Processors Onur Mutlu § Jared Stark † Chris Wilkerson ‡ Yale N. Patt § §ECE Department †Microprocessor Research ‡Desktop Platforms Group The University ofTexas at Austin Intel Labs Intel Corporation {onur,patt}@ece.utexas.edu [email protected] [email protected] Abstract the processor buffers the operations in an instruction win- dow, the size ofwhich determines the amount oflatency the Today’s high performance processors tolerate long la- out-of-order engine can tolerate. tency operations by means of out-of-order execution. How- Today’s processors are facing increasingly larger laten- ever, as latencies increase, the size of the instruction win- cies. With the growing disparity between processor and dow must increase even faster if we are to continue to tol- memory speeds, operations that cause cache misses out to erate these latencies. We have already reached the point main memory take hundreds ofprocessor cycles to com- where the size of an instruction window that can handle plete execution [25]. Tolerating these latencies solely with these latencies is prohibitively large, in terms of both de- out-of-order execution has become difficult, as it requires sign complexity and power consumption. And, the problem ever-larger instruction windows, which increases design is getting worse. This paper proposes runahead execution complexity and power consumption. For this reason, com- as an effective way to increase memory latency tolerance puter architects developed software and hardware prefetch- in an out-of-order processor, without requiring an unrea- ing methods to tolerate these long memory latencies.
    [Show full text]
  • Vector Runahead
    Vector Runahead Ajeya Naithaniy Sam Ainsworthz Timothy M. Joneso Lieven Eeckhouty yGhent University zUniversity of Edinburgh oUniversity of Cambridge Abstract—The memory wall places a significant limit on stride patterns, such techniques are endemic in today’s cache performance for many modern workloads. These applications systems [19]. For more complex indirection patterns, the feature complex chains of dependent, indirect memory accesses, inability at the cache-system level to identify complex load which cannot be picked up by even the most advanced microar- chitectural prefetchers. The result is that current out-of-order chains and generate their addresses limits existing techniques superscalar processors spend the majority of their time stalled. to simple array-indirect [88] and pointer-chasing [23] codes. While it is possible to build special-purpose architectures to To achieve the instruction-level visibility necessary to cal- exploit the fundamental memory-level parallelism, a microarchi- culate the addresses of complex access patterns seen in to- tectural technique to automatically improve their performance day’s workloads [3], we conclude that this ideal technique in conventional processors has remained elusive. Runahead execution is a tempting proposition for hiding must operate within the core, instead of within the cache. latency in program execution. However, to achieve high memory- Runahead execution [25, 32, 34, 57, 58, 64] is the most level parallelism, a standard runahead execution skips ahead of promising technique to date, where upon a memory stall cache misses. In modern workloads, this means it only prefetches at the head of the reorder buffer (ROB), execution enters the first cache-missing load in each dependent chain.
    [Show full text]
  • Runahead Threads
    ADVERTIMENT . La consulta d’aquesta tesi queda condicionada a l’acceptació de les següents condicions d'ús: La difusió d’aquesta tesi per mitjà del servei TDX ( www.tesisenxarxa.net ) ha estat autoritzada pels titulars dels drets de propietat intel·lectual únicament per a usos privats emmarcats en activitats d’investigació i docència. No s’autoritza la seva reproducció amb finalitats de lucre ni la seva difusió i posada a disposició des d’un lloc aliè al servei TDX. No s’autoritza la presentació del seu contingut en una finestra o marc aliè a TDX (framing). Aquesta reserva de drets afecta tant al resum de presentació de la tesi com als seus continguts. En la utilització o cita de parts de la tesi és obligat indicar el nom de la persona autora. ADVERTENCIA . La consulta de esta tesis queda condicionada a la aceptación de las siguientes condiciones de uso: La difusión de esta tesis por medio del servicio TDR ( www.tesisenred.net ) ha sido autorizada por los titulares de los derechos de propiedad intelectual únicamente para usos privados enmarcados en actividades de investigación y docencia. No se autoriza su reproducción con finalidades de lucro ni su difusión y puesta a disposición desde un sitio ajeno al servicio TDR. No se autoriza la presentación de su contenido en una ventana o marco ajeno a TDR (framing). Esta reserva de derechos afecta tanto al resumen de presentación de la tesis como a sus contenidos. En la utilización o cita de partes de la tesis es obligado indicar el nombre de la persona autora.
    [Show full text]