DOCSLIB.ORG

Configurable Simultaneously Single-Threaded (Multi-)Engine Processor

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. These processors effectively improve the throughput and utilization of a core, however often at the expense of single-thread performance as threads per core scale. Accordingly, applications which require higher single-thread performance must often resort to single-thread core multi-processor systems which incur additional area overhead and power dissipation. In attempts to improve single- and multi-thread core efficiency, this work introduces the concept of a Configurable Simultaneously Single-Threaded (Multi-)Engine Processor (ConSSTEP). ConSSTEP is a nuanced approach to multi- threaded processors, achieving performance gains and energy efficiency by invoking low overhead reconfigurable properties with full software compatibility. Experimen- tal results demonstrate that ConSSTEP is able to increase single-thread Instruc- tions Per Cycle (IPC) up to 1.39x and 2.4x for 2-thread and 4-thread workloads, respectively, improving throughput and providing up to 2x energy efficiency when compared to a conventional SMT processor. iii iv Acknowledgements I would like to express my gratitude to my supervisor, Dr. Kaamran Raahemifar, for his guidance and support of unconventional approaches and ideas throughout my PhD studies. I am truly grateful for the sincere trust and patience he has placed in me to develop the work presented in this thesis. I would like to thank the Ontario Graduate Scholarship (OGS) program and the Faculty of Engineering, Architec- ture, and Science (FEAS) for their financial support throughout my PhD studies. A special thanks to my thesis defense committee - Dr. Lev Kirischian, Dr. Ebrahim Bagheri, Dr. Issaac Woungang, and Dr. George Stamoulis, for their valuable feed- back and comments which have greatly enhanced the quality of this thesis. I would also like to thank Dr. Gul N. Khan for his advice and support through- out my graduate studies, and especially for granting me with opportunities that have truly enhanced my experience at Ryerson. To Ryerson's faculty and staff, I would like to thank them for sharing their wisdom and knowledge throughout the years, making my Ryerson experience memorable. Also a special thanks to Jason, Luis, Dan, and Nipin for all their guidance, assistance, and laughs throughout the years. Sincere thanks to Luis for his help on the development of this written thesis. Finally to those closest to me: To my mom, sister Cassandra, my loving grand- parents and family, I would like to sincerely thank them for their constant support and encouragement to pursue my studies, and especially for tolerating my never ending university workload. I am truly blessed to have such a supportive and lov- ing family, and would not be where I am today without them. To my best friend Cristina who has been nothing but supportive, encouraging, and loving since day one and especially throughout my graduate studies - words cannot express how truly grateful I am. And finally to Matthew - we've developed an exponential closeness throughout the past years. You push me to be the best I can be with endless love and encouragement, and I am sincerely thankful to have you in my life. v vi Contents Author's Declaration ii Abstract iii Acknowledgements v List of Figures xiii List of Tables xv 1 Introduction 1 1.1 Motivation . 1 1.1.1 Processor Performance Plateau . 1 1.1.2 Computing Model Classifications . 3 1.1.3 Limitations of ISAs and Compilers . 5 1.1.4 Single Core Bottlenecks . 7 1.1.5 Multi-Threaded Processors . 9 1.2 Research Objectives . 13 1.3 Thesis Contributions . 14 1.4 Thesis Statement . 16 1.5 Dissertation Outline . 16 2 Background 18 2.1 Introduction . 18 2.2 In-order, Single (Scalar) Issue Processors . 18 2.3 Instruction Set Architectures (ISA) . 20 2.4 Superscalar/Out-of-Order Models . 23 2.4.1 Architectural Design . 24 2.4.2 Speculative Execution . 25 vii 2.4.3 Limitations of OoO Superscalar Processors . 30 2.5 Parallelism Granularity and Application Flow . 31 2.5.1 Instruction-Level Parallelism (ILP) . 31 2.5.2 Thread-Level Parallelism (TLP) . 32 2.5.3 Data-Level Parallelism (DLP) . 32 2.5.4 Control-Flow vs Dataflow . 33 2.6 Single-Thread vs Multi-Threading . 34 2.6.1 Fine-Grained Multi-Threading . 35 2.6.2 Coarse-Grained Multi-Threading . 35 2.6.3 Simultaneous Multi-Threading (SMT) . 35 2.7 Multi-Core Models . 36 2.7.1 Motivation . 37 2.7.2 Limitations . 38 2.8 Very Long Instruction Word (VLIW) . 39 2.9 Explicitly Parallel Instruction Processors (EPIC) . 40 2.10 Digital Signal Processors (DSP) . 41 2.11 Co-Designed Virtual Machines . 41 2.12 Summary . 42 3 ConSSTEP Overview 44 3.1 Introduction . 44 3.2 General Overview . 44 3.3 Assumptions . 46 3.4 Compilation Process . 47 3.5 Architectural Flow and Pipeline . 49 3.6 Execution Example . 53 3.7 ConSSTEP vs Conventional CPUs . 54 3.7.1 Execution . 54 3.7.2 Storage & Interconnect . 55 3.7.3 ConSSTEP vs VLIWs . 56 3.8 Tradeoffs of ConSSTEP . 57 3.9 Summary . 59 4 Related Work 60 4.1 Introduction . 60 4.2 Hybrid Data-flow Architectures . 61 4.3 Distributed and Coarse-Grained Architectures . 64 viii 4.4 Reconfigurable Architectures and CGRAs . 67 4.5 Other Architecture Models . 71 4.5.1 Stream Processors . 71 4.5.2 Transport Triggered Architectures . 71 4.6 Summary . 72 5 Architecture 73 5.1 Introduction . 73 5.2 rS Interconnect . 73 5.3 Read Register Buffer (RRB) . 76 5.4 Write Register Buffer (WRB) . 76 5.5 Functional Units . 77 5.6 External Register File . 78 5.7 Configuration & Setup . 79 5.7.1 Setup Mitigation Techniques . 79 5.7.2 Floating Point (FP) Execution . 81 5.7.3 Branch Prediction & Loop Acceleration . 82 5.8 Exception Handling . 83 5.9 Scheduler . 85 5.10 Data Memory Accesses . 87 6 Compilation 89 6.1 Introduction . 89 6.2 Logical Compiler . 89 6.3 Physical Compiler (PhysC) . 90 6.3.1 Bundle Formation . 90 6.3.2 Data Dependency Analysis . 92 6.3.3 Instruction Analysis . 92 6.3.4 Engine Mapping . 93 6.3.5 Instruction-to-FU Mapping . 93 6.3.6 rS & Unit Mapping . 95 6.3.7 Configuration Data Generation . 98 6.4 Summary . 98 7 Experimental Methodology 99 7.1 Introduction . 99 7.2 Architectural Framework . 99 ix 7.2.1 Simulators . 99 7.2.2 Benchmarks . 104 7.3 Physical Modelling . 105 7.3.1 Area Estimates . 105 7.3.2 Wire Delays . 105 7.3.3 Cycle Time Determination . 108 7.4 Summary . 109 8 Sensitivity Studies 110 8.1 Introduction . 110 8.2 Intra-Scheduling Algorithm Efficiency . 111 8.2.1 rS Latch Utilization . 112 8.2.2 rS Utilization during Propagation . 114 8.2.3 IPC . 117 8.2.4 Hop Count . 119 8.2.5 Summary - Intra-Scheduling . 119 8.3 Inter-Scheduling: Bundle to Engine Mapping . 122 8.4 Summary . 123 9 Experimental Results and Analysis 124 9.1 Introduction . 124 9.2 Two-Thread Comparison . 126 9.2.1 Configuration Overhead Concealment Techniques . 126 9.2.2 Area . ..
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]
  • 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.
    [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]
  • 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]