core fusion: accommodating software diversity in chip ...cavazos/cisc879-spring... · cisc 879 :...

CISC 879 : Software Support for Multicore Architectures

Navreet VirkDept of Computer & Information Sciences

University of Delaware

Core Fusion: Accommodating SoftwareDiversity in Chip Multiprocessors

Authors: Engin Ipek, Meyrem Kırman, Nevin Kırman, andJose´ F. Martinez


Outline

• Motivation for Core Fusion• Architecture• Dynamic Reconfiguration• Experimental Setup• Evaluation• Conclusion


Introduction

• When running sequential workloads, fewpowerful cores yield high utilization

• Sequential codes not sufficient to sustainlong-term performance scalability

• To fully exploit Chip Multiprocessors(CMPs), parallel programming is necessary


Motivation

• Programmers parallelize code incrementally• Diverse array of software is likely• Applications exert different demands on

hardware across phases of same run• Composition of CMP is unchangeable after

they are fabricated• Solution?


Motivation

• A CMP which can dynamically synthesizeright composition

• Core-fusion – reconfigurable CMParchitecture groups of fundamentally independent cores can

dynamically morph into a larger CPU, Still can be used as distinct processing elements, as

needed at run time by applications


Why Core Fusion

Benefits to CMP design• Support for software diversity

Fine-grain parallelism – many lean cores Coarse-grain parallelism – fusing many cores into fewer,

powerful CPUs Sequential code – by executing on one fused core

• Support for smoother software evolution Support incremental parallelization – dynamically provide

optimal configuration for sequential and parallel


Why Core Fusion

• Single-design solution Multiple modular structures can be tiled

• Optimized for parallel code Good isolation across threads in parallel runs

• Design-bug and hard-fault resilience Bug/hard fault in one core still allows operation of 3 fault-

free cores


Challenges for Core Fusion

• Should not increase software complexity• Should work around independent nature of

base cores• Dynamic reconfiguration should be efficient


Architecture

• Builds on top of substrate comprisingidentical, two-issue out-of-order cores

• A bus connects private L1 i-cache and d-cache

• Other side of bus has L2 cache and memorycontroller


Architecture

• 8 core CMP– 2 independent cores– two-core fused group– four-core fused group.


Architecture – Front End• Collective Fetch - Fetch Management Unit (FMU)

receives and re-sends fetch information across cores

Fetch Mechanism and Instruction Cache• Each core fetches 2 instructions from its own i-

cache• Fetch is aligned with core zero• In case of taken branch, lower-order cores skip

fetch• In case of i-cache miss, 8 word block is delivered

To requesting cores if operating independently To all 4 cores if fused together


Architecture – Front End

(a) 4 sub blocks and one tag within each i-cache constitute a cache block.(b) cache block spans 4 i-caches, each i-cache has a

sub block and a tag replica



Branches and subroutine calls• Prediction – Each core accesses its own branch predictor and

Branch Target Buffer (BTB)• To maximize utilization, branch predictor and BTB are indexed

i bits are used forindexingt bits for tagging(only meaningful inthe BTB)



Cores squashoverfetched instructionsNew target starts atCore 1Core 0 skips the firstfetch cycle


Architecture – Front End• Collective Decode/Rename

• Instruction in fetch group need to be renamedand steered

• Co-ordinated by Steering Management Unit(SMU)

• SMU consists of :• Global steering table to track the mapping of

architectural registers to any core• 4 free-lists for register allocation• four rename maps• steering/renaming logic



SMU Organization


Architecture – Back End

• Operand Crossbar Supports operand communication

• Wake-up and Selection copy instructions are placed in a FIFO queue Once issued, wakes up dependent instructions, update registers

• Reroder Buffer and Commit Support 4 ROBs commit in lockstep up to 8 instructions per cycle

• Load/Store Queue banked-by-address load-store queue (LSQ) implementation

allows to keep data coherent Doesn’t require cache flushes after dynamic reconfiguration


Dynamic Reconfiguration

• How do cores dynamically fuse or separate?• Dynamic run-time reconfiguration enabled through

simple application interface• Application requests core fusion/split actions

through a pair of FUSE and SPLIT ISA instructions• FUSE and SPLIT instructions are executed

conditionally by hardware:• based on the value of an OS-visible control register

indicative of eligible cores for fusion


Dynamic Reconfiguration• FUSE Operation

Application may request cores to be fused to executesequential region

Instructions following FUSE and i-cache are flushed FMU, SMU, i-caches are reconfigured

• SPLIT Operation Application advises fused group of parallel region using

SPLIT In-flight instructions are allowed to drain, FMU and SMU are reconfigured Core zero starts fetching from the instruction that follows

the SPLIT in program order.


Experimental Setup• Compared Core Fusion against 5 static

homogeneous and asymmetric CMP architectures• Asymmetric chip multiprocessors (ACMPs)

• comprise cores of varying sizes and computationalcapabilities

• two-, four-, and six-issue out-of-order cores wereused as building blocks

• Estimated the area overhead, latency of cross-corewiring for experiment


Configuration of two-issue core


Experimental SetupNumber and type of cores used


Experimental Setup

• Applications – parallel, evolving parallel and sequentialworkloads


Evaluation

• Sequential Application Performance

Speedup over FineGrain-2i when executingSPECINT


Evaluation - Sequential ApplicationPerformance

Speedup over FineGrain-2i when executing SPECFP6 issue monolithic core obtain average speedups of73% and 47% on floating-point and integerbenchmarks


Evaluation - Parallel ApplicationPerformance

Speedup over single-thread run onFineGrain-2i when executing parallel applications


Evaluation – Evolving ParallelApplication Performance

Speedup over stage zero run on FineGrain-2i


Evaluation – Evolving ParallelApplication Performance

Performance differences between the best andworst architectures are high.CoreFusion consistently performs the best orrides close to the best configuration.


Conclusion

• Core Fusion allows relatively simple CMP cores todynamically fuse into larger, more powerfulprocessors

• Goal is to accommodate software diversity and todynamically adapt to changing demands ofworkloads

• Result is a flexible CMP architecture that adapts todiverse software applications

• Rewards incremental parallelization with higherperformance along the development curve

• No specialized compiler support, a customized ISAor higher software complexity required

core fusion: accommodating software diversity in chip ...cavazos/cisc879-spring... · cisc 879 :...

Documents