Korey Sewell*, Trevor Mudge*, Steven K. Reinhardt* † *Advanced Computer Architecture Labaratory (ACAL) University of Michigan, Ann Arbor † Advanced Micro Devices (AMD) XVP e X treme V irtual P ipelining (XVP): Moving Towards Scalable Multithreaded Processors ASPLOS – WACI ‘09

2 Many-Core Mansion (~32-64P, ~2-4T) Multicore-Estates (2-4P, ~2-4T) Multithreading-Ville (1P, ~2-4T) The Comp. Arch. Research Train Did we miss a stop on the way???? What about “Many”-Threading?!!! Uniprocessor-Place (1P, 1T) P = Processor(s) T =Thread(s)

ASPLOS - WACI ’09 3 CHANGES the way we think about architecture… even –Moving from 2-4 threads per core to 16, 32 or even 64 threads per core –Threads aren’t just Parallel…They’re Adjacent! What would you create if you had “threads to throw away”? –Hmmmmmmm….. Why “Many-Threading”?

ASPLOS - WACI ’09 4 (1)“Coherence-Free” Synchronization & Communication  Why Suffer from Non-Deterministic Memory Latency when so many threads are adjacent (on same core)? Memory System CPU … T0TNT2T1 CPU … T0 TNT2T1 WACI,“Many”-Threading Possibilities

ASPLOS - WACI ’09 5 Branch Misprediction T … (2)Extremely Speculative Multithreading  Use extra threads during speculative events (e.g. branch misprediction, cache miss)  Fast forward execution by traversing speculation tree and then switching threads. WACI,“Many”-Threading Possibilities F F F T T

ASPLOS - WACI ’09 6 (3)Super Virtual Machines  Security: Every application given it’s own VM? (4)Many-Many Systems!  Many Threads, Many Cores  1000 thread system = 64 cores, 16 threads per core (5)Redundant Multithreading (6)This list keeps going….and going…and going!!! WACI,“Many”-Threading Possibilities

ASPLOS - WACI ’09 7 A design that avoids non-scalable, conventional multithreading pitfalls such as… –Replication of per-thread resources –Extensive size increases of shared resources –Complex resource distribution methods amongst threads How do we get to Many- Threading?

ASPLOS - WACI ’09 8 Provide each thread the illusion that it has all the processor resources to itself Traditionally, simultaneous executing threads have a shared pipeline view XVP XVP WACI Solution: e X treme V irtual P ipelining (XVP) DRF LSQ IQ ROB EXE RF = T 0 - T N DRF LSQ IQ ROB EXE RF = T 1 DRF LSQ IQ ROB EXE RF = T 0 DRF LSQ IQ ROB EXE RF = T N …

ASPLOS - WACI ’09 9 Pipeline Virtualization: Resource entries are mapped into each thread’s address space XVP XVP WACI Solution: e X treme V irtual P ipelining (XVP): CPU MEMORY 0 7 T0 Base T0 +0 … 7 Resource “X” T1 Base T1 +0 … 7 TN Base TN +0 … 7

ASPLOS - WACI ’09 10 Virtualize all stalling processor resources to memory –Fetch Buffer, Instruction Queue, Load/Store Queue, Register File, Reorder Buffer XVPXVP extends the notion of a hardware context to include pipeline resources –Add a C-Cache (Context) to avoid D-Cache thrashing and potentially reduce memory footprint in workloads Each stallable resource matched with it’s own “on-demand” Fill-Spill-Unit (FSU) –Ex:Spill IQ on dep. load miss / Fill when miss resolves –FSU allows resources to dynamically partition themselves for arbitrary workloads XVP XVP WACI Solution: e X treme V irtual P ipelining (XVP): DRF LSQ IQ ROB EXE RF FSU C-Cache

ASPLOS - WACI ’09 11 XVP XVP WACI Conclusion: e X treme V irtual P ipelining (XVP) A high # of threads per core opens up interesting multithreading research angles XVP’sXVP’s pipeline virtualization moves toward scalable many-threads per core –Each thread has illusion that it has it’s own pipeline XVPXVP can also benefit single-thread processors… –Because XVP’s virtualization provides more resources than traditionally available.

ASPLOS - WACI ’09 12 Thanks for Listening!