1 / 27

The Vector-Thread Architecture

The Vector-Thread Architecture. Ronny Krashinsky, Christopher Batten, Mark Hampton, Steve Gerding, Brian Pharris, Jared Casper, Krste Asanović MIT Computer Science and Artificial Intelligence Laboratory, Cambridge, MA, USA ISCA 2004. Goals For Vector-Thread Architecture.

raven
Download Presentation

The Vector-Thread Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Vector-Thread Architecture Ronny Krashinsky, Christopher Batten, Mark Hampton, Steve Gerding, Brian Pharris, Jared Casper, Krste Asanović MIT Computer Science and Artificial Intelligence Laboratory, Cambridge, MA, USA ISCA 2004

  2. Goals For Vector-Thread Architecture • Primary goal is efficiency • High performance with low energy and small area • Take advantage of whatever parallelism and locality is available: DLP, TLP, ILP • Allow intermixing of multiple levels of parallelism • Programming model is key • Encode parallelism and locality in a way that enables a complexity-effective implementation • Provide clean abstractions to simplify coding and compilation

  3. Vector and Multithreaded Architectures vector control Control Processor • Vector processors provide efficient DLP execution • Amortize instruction control • Amortize loop bookkeeping overhead • Exploit structured memory accesses • Unable to execute loops with loop-carried dependencies or complex internal control flow thread control PE0 PE1 PE2 PEN PE0 PE1 PE2 PEN Memory Memory • Multithreaded processors can flexibly exploit TLP • Unable to amortize common control overhead across threads • Unable to exploit structured memory accesses across threads • Costly memory-based synchronization and communication between threads

  4. Vector-Thread Architecture • VT unifies the vector and multithreaded compute models • A control processor interacts with a vector of virtual processors (VPs) • Vector-fetch: control processor fetches instructions for all VPs in parallel • Thread-fetch: a VP fetches its own instructions • VT allows a seamless intermixing of vector and thread control vector-fetch Control Processor thread- fetch VP0 VP1 VP2 VP3 VPN Memory

  5. Outline • Vector-Thread Architectural Paradigm • Abstract model • Physical Model • SCALE VT Processor • Evaluation • Related Work

  6. Virtual Processor Abstraction Registers ALUs vector-fetch • VPs contain a set of registers • VPs execute RISC-like instructions grouped into atomic instruction blocks (AIBs) • VPs have no automatic program counter, AIBs must be explicitly fetched • VPs contain pending vector-fetch and thread-fetch addresses • Afetch instruction allows a VP to fetch its own AIB • May be predicated for conditional branch • If an AIB does not execute a fetch, the VP thread stops VP thread- fetch VP thread execution AIB instruction fetch thread-fetch fetch thread-fetch

  7. Virtual Processor Vector Registers Registers Registers ALUs ALUs ALUs • A VT architecture includes a control processor and a virtual processor vector • Two interacting instruction sets • A vector-fetch command allows the control processor to fetch an AIB for all the VPs in parallel • Vector-load and vector-store commands transfer blocks of data between memory and the VP registers vector-fetch Control Processor VP0 VP1 VPN vector-load vector-store Vector Memory Unit Memory

  8. Cross-VP Data Transfers Registers Registers Registers ALUs ALUs ALUs • Cross-VP connections provide fine-grain data operand communication and synchronization • VP instructions may target nextVP as destination or use prevVP as a source • CrossVP queue holds wrap-around data, control processor can push and pop • Restricted ring communication pattern is cheap to implement, scalable, and matches the software usage model for VPs vector-fetch Control Processor VP0 VP1 VPN crossVP-pop crossVP-push crossVP queue

  9. Mapping Loops to VT • A broad class of loops map naturally to VT • Vectorizable loops • Loops with loop-carried dependencies • Loops with internal control flow • Each VP executes one loop iteration • Control processor manages the execution • Stripmining enables implementation-dependent vector lengths • Programmer or compiler only schedules one loop iteration on one VP • No cross-iteration scheduling

  10. Vectorizable Loops vector-load ld ld ld ld ld vector-load ld ld ld ld ld vector-fetch ld ld • Data-parallel loops with no internal control flow mapped using vector commands • predication for small conditionals x << + operation st loop iteration DAG Control Processor VP1 VP0 VP2 VP3 VPN vector-load ld ld ld ld ld vector-load ld ld ld ld ld vector-fetch x << x x x x << << << << + + + + + vector-store st st st st st

  11. Loop-Carried Dependencies ld ld • Loops with cross-iteration dependencies mapped using vector commands with cross-VP data transfers • Vector-fetch introduces chain of prevVP receives and nextVP sends • Vector-memory commands with non-vectorizable compute x << + st Control Processor VP1 VP0 VP2 VP3 VPN vector-load ld ld ld ld ld vector-load ld ld ld ld ld vector-fetch x << x x x x << << << << + + + + + vector-store st st st st st

  12. Loops with Internal Control Flow ld • Data-parallel loops with large conditionals or inner-loops mapped using thread-fetches • Vector-commands and thread-fetches freely intermixed • Once launched, the VP threads execute to completion before the next control processor command ld == br st Control Processor VP1 VP0 VP2 VP3 VPN vector-load ld ld ld ld ld vector-fetch ld ld ld ld ld == == == == == br br br br br ld ld ld == == == br br br vector-store st st st st st

  13. VT Physical Model Control Processor Vector-Thread Unit Lane 0 Lane 1 Lane 2 Lane 3 VP12 VP13 VP14 VP15 VP8 VP9 VP10 VP11 VP4 VP5 VP6 VP7 VP0 VP1 VP2 VP3 Vector Memory Unit ALU ALU ALU ALU Memory • A Vector-Thread Unit contains an array of lanes with physical register files and execution units • VPs map to lanes and share physical resources, VP execution is time-multiplexed on the lanes • Independent parallel lanes exploit parallelism across VPs and data operand locality within VPs

  14. Lane Execution • Lanes execute decoupled from each other • Command management unit handles vector-fetch and thread-fetch commands • Execution cluster executes instructions in-order from small AIB cache (e.g. 32 instructions) • AIB caches exploit locality to reduce instruction fetch energy (on par with register read) • Execute directives point to AIBs and indicate which VP(s) the AIB should be executed for • For a thread-fetch command, the lane executes the AIB for the requesting VP • For a vector-fetch command, the lane executes the AIB for every VP • AIBs and vector-fetch commands reduce control overhead • 10s—100s of instructions executed per fetch address tag-check, even for non-vectorizable loops Lane 0 vector-fetch vector-fetch thread-fetch miss addr AIB address miss AIB tags VP12 execute directive VP8 VP4 VP0 VP AIB cache ALU AIB fill instr. AIB

  15. VP Execution Interleaving vector-fetch AIB vector-fetch thread- fetch time vector-fetch • Hardware provides the benefits of loop unrolling by interleaving VPs • Time-multiplexing can hide thread-fetch, memory, and functional unit latencies time-multiplexing Lane 0 Lane 1 Lane 2 Lane 3 VP0 VP4 VP8 VP12 VP1 VP5 VP9 VP13 VP2 VP6 VP10 VP14 VP3 VP7 VP11 VP15

  16. VP Execution Interleaving AIB • Dynamic scheduling of cross-VP data transfers automatically adapts to software critical path (in contrast to static software pipelining) • No static cross-iteration scheduling • Tolerant to variable dynamic latencies time-multiplexing Lane 0 Lane 1 Lane 2 Lane 3 VP0 VP4 VP8 VP12 VP1 VP5 VP9 VP13 VP2 VP6 VP10 VP14 VP3 VP7 VP11 VP15 vector-fetch time

  17. SCALE Vector-Thread Processor • SCALE is designed to be a complexity-effective all-purpose embedded processor • Exploit all available forms of parallelism and locality to achieve high performance and low energy • Constrained to small area (estimated 10 mm2 in 0.18 μm) • Reduce wire delay and complexity • Support tiling of multiple SCALE processors for increased throughput • Careful balance between software and hardware for code mapping and scheduling • Optimize runtime energy, area efficiency, and performance while maintaining a clean scalable programming model

  18. SCALE Clusters • VPs partitioned into four clusters to exploit ILP and allow lane implementations to optimize area, energy, and circuit delay • Clusters are heterogeneous – c0 can execute loads and stores, c1 can execute fetches, c3 has integer mult/div • Clusters execute decoupled from each other Lane 0 Lane 1 Lane 2 Lane 3 Control Processor SCALE VP AIB Fill Unit c3 c3 c3 c3 c3 c2 c2 c2 c2 c2 c1 c1 c1 c1 c1 c0 c0 c0 c0 c0 L1 Cache

  19. SCALE Registers and VP Configuration c0 • Atomic instruction blocks allow VPs to share temporary state – only valid within the AIB • VP general registers divided into private and shared • Chain registers at ALU inputs – avoid reading and writing general register file to save energy shared • Number of VP registers in each cluster is configurable • The hardware can support more VPs when they each have fewer private registers • Low overhead: Control processor instruction configures VPs before entering stripmine loop, VP state undefined across reconfigurations VP8 VP4 VP0 cr0 cr1 4 VPs with 0 shared regs 8 private regs 7 VPs with 4 shared regs 4 private regs 25 VPs with 7 shared regs 1 private reg VP12 shared shared VP24 VP20 VP8 VP16 VP4 VP12 VP8 VP0 VP4 VP0

  20. SCALE Micro-Ops • Assembler translates portable software ISA into hardware micro-ops • Per-cluster micro-op bundles access local registers only • Inter-cluster data transfers broken into transports and writebacks Software VP code: Hardware micro-ops: cluster micro-op bundle Cluster 3 not shown

  21. SCALE Cluster Decoupling Cluster 3 • Cluster execution is decoupled • Cluster AIB caches hold micro-op bundles • Each cluster has its own execute-directive queue, and local control • Inter-cluster data transfers synchronize with handshake signals • Memory Access Decoupling (see paper) • Load-data-queue enables continued execution after a cache miss • Decoupled-store-queue enables loads to slip ahead of stores VP writeback compute AIB cache Regs ALU transport Cluster 2 writeback compute AIBs transport Cluster 1 writeback compute AIBs transport Cluster 0 writeback compute AIBs transport

  22. SCALE Prototype and Simulator ctrl L/S byp ALU shftr PC CP0 RF MD 4 mm Cache Bank (8KB) Cache Bank (8KB) Memory Interface / Cache Control Cache Tags Cache Bank (8KB) Control Processor Crossbar Mult Div 2.5 mm ctrl IQC ctrl IQC ctrl IQC ctrl IQC ctrl LDQ shftr shftr shftr shftr RF RF RF RF ALU ALU ALU ALU latch latch latch latch mux/ mux/ mux/ mux/ ctrl IQC ctrl ctrl IQC ctrl IQC ctrl IQC Cluster Cache Bank (8KB) Memory Unit LDQ shftr shftr shftr shftr ALU ALU ALU ALU RF RF RF RF latch latch latch latch mux/ mux/ mux/ mux/ ctrl IQC ctrl IQC ctrl IQC ctrl IQC ctrl LDQ shftr shftr shftr shftr RF RF RF RF ALU ALU ALU ALU latch latch latch latch mux/ mux/ mux/ mux/ ctrl IQC ctrl IQC ctrl IQC ctrl IQC ctrl Lane LDQ shftr shftr shftr shftr latch ALU RF latch ALU RF latch ALU RF latch ALU RF mux/ mux/ mux/ mux/ • Prototype SCALE processor in development • Control processor: MIPS, 1 instr/cycle • VTU: 4 lanes, 4 clusters/lane, 32 registers/cluster, 128 VPs max • Primary I/D cache: 32 KB, 4x128b per cycle, non-blocking • DRAM: 64b, 200 MHz DDR2 (64b at 400Mb/s: 3.2GB/s) • Estimated 10 mm2 in 0.18μm, 400 MHz (25 FO4) • Cycle-level execution-driven microarchitectural simulator • Detailed VTU and memory system model

  23. Benchmarks • Diverse set of 22 benchmarks chosen to evaluate a range of applications with different types of parallelism • 16 from EEMBC, 6 from MiBench, Mediabench, and SpecInt • Hand-written VP assembly code linked with C code compiled for control processor using gcc • Reflects typical usage model for embedded processors • EEMBC enables comparison to other processors running hand-optimized code, but it is not an ideal comparison • Performance depends greatly on programmer effort, algorithmic changes are allowed for some benchmarks, these are often unpublished • Performance depends greatly on special compute instructions or sub-word SIMD operations (for the current evaluation, SCALE does not provide these) • Processors use unequal silicon area, process technologies, and circuit styles • Overall results: SCALE is competitive with larger and more complex processors on a wide range of codes from different domains • See paper for detailed results • Results are a snapshot, SCALE microarchitecture and benchmark mappings continue to improve

  24. Mapping Parallelism to SCALE • Data-parallel loops with no complex control flow • Use vector-fetch and vector-memory commands • EEMBC rgbcmy, rgbyiq, and hpg execute 6-10 ops/cycle for 12x-32x speedup over control processor, performance scales with number of lanes • Loops with loop-carried dependencies • Use vector-fetched AIBs with cross-VP data transfers • Mediabench adpcm.dec: two loop-carried dependencies propagate in parallel, on average 7 loop iterations execute in parallel, 8x speedup • MiBench sha has 5 loop-carried dependencies, exploits ILP prototype 70 9 1 Lane 8 60 2 Lanes 4 Lanes 7 50 8 Lanes 6 Speedup vs. Control Processor 40 5 4 30 3 20 2 10 1 0 0 rgbcmy rgbyiq hpg adpcm.dec sha

  25. Mapping Parallelism to SCALE • Data-parallel loops with large conditionals • Use vector-fetched AIBs with conditional thread-fetches • EEMBC dither: special-case for white pixels (18 ops vs. 49) • Data-parallel loops with inner loops • Use vector-fetched AIBs with thread-fetches for inner loop • EEMBC lookup: VPs execute pointer-chaising IP address lookups in routing table • Free-running threads • No control processor interaction • VP worker threads get tasks from shared queue using atomic memory ops • EEMBC pntrch and MiBench qsort achieve significant speedups 10 1 Lane 2 Lanes 8 4 Lanes 8 Lanes 6 Speedup vs. Control Processor 4 2 0 dither lookup pntrch qsort

  26. Comparison to Related Work • TRIPS and Smart Memories can also exploit multiple types of parallelism, but must explicitly switch modes • Raw’s tiled processors provide much lower compute density than SCALE’s clusters which factor out instruction and data overheads and use direct communication instead of programmed switches • Multiscalar passes loop-carried register dependencies around a ring network, but it focuses on speculative execution and memory, whereas VT uses simple logic to support common loop types • Imagine organizes computation into kernels to improve register file locality, but it exposes machine details with a low-level VLIW ISA, in contrast to VT’s VP abstraction and AIBs • CODE uses register-renaming to hide its decoupled clusters from software, whereas SCALE simplifies hardware by exposing clusters and statically partitioning inter-cluster transport and writeback ops • Jesshope’s micro-threading is similar in spirit to VT, but its threads are dynamically scheduled and cross-iteration synchronization uses full/empty bits on global registers

  27. Summary • The vector-thread architectural paradigm unifies the vector and multithreaded compute models • VT abstraction introduces a small set of primitives to allow software to succinctly encode parallelism and locality and seamlessly intermingle DLP, TLP, and ILP • Virtual processors, AIBs, vector-fetch and vector-memory commands, thread-fetches, cross-VP data transfers • SCALE VT processor efficiently achieves high-performance on a wide range of embedded applications

More Related