Date post: | 17-Dec-2015 |
Category: |
Documents |
Upload: | dina-chase |
View: | 227 times |
Download: | 1 times |
Revolver: Processor Architecture for Power Efficient Loop ExecutionMitchell Haygena, Vignayan Reddy and Mikko H. Lipasti
-Padmini Gaur( 13IS15F) Sanchi (13IS20F)
Contents• The Need• Approaches and Isssues• Revolver: Some basics• Loop Handling
▫ Loop Detection Detection and Training Finite State Machine
• Loop Execution• Scheduler
▫ Units▫ Tag Propagation Unit
• Loop pre-execution• Conclusion• References
The Need
•Per-transistor energy benefit improvement
•Increasing computational efficiency▫Power efficient mobile, server▫Increasing energy contraints
•Elimination of unnecessary pipeline activity
•Managing energy utilization▫Small energy requirements of instruction
execution but Large control overheads
So far: Approaches and Issues
•Pipeline centric instruction caching▫Emphasizing temporal instruction locality
•Capturing loop instruction in buffer▫Inexpensive retrieval for future iterations
•Out-of-order processors: Issues?▫Resource allocation▫Program ordering▫Operand dependency
Revolver: An enhanced approach•Out-of-order back-end•Overall design similar to normal
processor•Non-loop instructions
▫Follow normal conventional pipeline•No Register Allocation Table on front-end
instead Tag propagation unit at back-end•Loop mode:
▫Detection and dispatching loop to back-end
The promises
•No additional resource allocation•Energy consumption at front-end
managed•Pre-execution of future iterations•Operand dependence linking moved to
back-end
Loop handling
•Loop detection•Training feedback•Loop execution
▫Wakeup logic▫Tag Propagation Unit
•Load Pre-execution
Loop Detection
•Detection (at) stages:▫Post-execution▫At decode stage
•Enabling loop mode at decode•Calculation of:
▫Start address▫Required resources
Detection and Training
•Key mechanisms:▫Detection logic at front-end -> dispatched▫Feedback by back-end: Profitability of loops
•Profitability▫Disabling future loop-mode
•Detection control▫Loop Detection Finite State Machine
FSM states
•Idle: Through decode until valid/profitable loop or PC-relative backward branch/jump detection
•Profitability logged in Loop Address Table•LAT records:
▫Composition and profitability•Profitable loop dispatched•Backward jump/ branch and No loop
▫Train State
•Train state: ▫Records start address▫End address▫Allowable unroll factor
•Resources required added to LAT•Loop ends -> Idle state•In dispatch state the decode logic guides
the dispatch of loop instructions into the out of order backend.
Training Feedback• Profitability
▫4-bit counter▫Default value =8▫Loop mode enabling if value>=8▫Dispatched loop unrolled more than twice, +2▫Else, -2▫Mis-prediction other than fall-through,
profitability set = 0• Disabled loops:
▫Front-end increments by 1 for 2 sequential successful dispatch
Loop: Basic idea•Unrolling loop:
▫Depending on back-end resources▫As much as possible▫Eliminating additional resource use after
dispatch•Loop instruction stays in issue queue,
executes till completion of iteration•Maintaining provided resources across
multiple executions•Load-store queues modified maintaining
program order
Contd..
•Proper access of destination and source register
•Loop exit:▫Removing instructions from back-end▫Loop fall-trough path dispatch
Loop execution: Let’s follow• Green: Odd numbered• Blue: Even numbered• Pointers:
▫ Program order maintenance: loop_start, loop_end
▫ Oldest uncommitted entry: commit
Loop execution, contd..
•Commiting:▫Start to end▫Wrapping to start: next loop iteration▫Resetting issue queue entries for next loop
iteration▫Load queue entries invalidated▫Store queue entries:
Passed to write-buffer Immediate reuse in next iteration Cannot write to buffer -> stall (very rare)
Scheduler: Units
•Wake-up array▫Identifying Ready instructions
•Select logic▫Arbitration between reading instructions
•Silo instruction▫Producing the opcode and physical
identifiers of selected instruction
Scheduler: The concept
•Managed as queue•Maintains program order among entries•Wakeup array
▫Utilizes logical register identifiers▫Position dependence
•Tag Propagation Unit (TPU)▫Physical register mapping
Wakeup Logic: Overview
•Observes generated results:▫Identifying new instructions capable of
being executed•Program based ordering•Broadcast of logical register identifier
▫No need for renaming▫No physical register identifier in use
Wakeup operation
•Allocation into wake up array▫Marking logical source and destination
registers•Unscheduled instruction
▫Deassert downstream register column▫Preventing younger, dependent instructions
from waking up•Request sent when:
▫Receiving all necessary source register broadcasts
▫Ready source registers
•Select grants the request:▫Asserting downstream ready▫Waking up younger dependent instructions
•Wakeup logic cell:▫2 state bits: sourcing/producing logical
register
Tag Propagation Unit (TPU)
•No renaming!•Maps physical register identifier to logical
registers•Enables reuse of physical register
▫As no additional resources▫Physical register management
•Possible speculative execution of next loop iterations
Next loop iteration??
•Impossible if: Instruction only has access to single physical
destination register•Speculative execution:
▫Alternative physical register identifier needed
•Solution: 2 physical destination registers▫Alternative writing between 2
With 2 destination registers
•Double Buffering▫Maintaining previous state while
speculative computation▫N+1 commits, reusing destination register
of iteration N on iteration N+2▫No instruction dependence in N and N+2▫Speculative writing in output register
allowed
With Double buffering
•Dynamic linkage between dependent instructions and source registers
•Changing logical register mapping▫Overwriting output register column
•Instruction stored in program order:▫Downstream instructions obtain proper
source mapping
Register reclamation
•Any instruction misprediction:▫Flushing downstream instructions▫Propagation of mappings to all newly
scheduled instructions•Better than RAT:
▫Complexities reduced
Queue entries: Lifetime
•Received prior to dispatch•Retained till instruction exit from backend•Reused to execute multiple loop iterations
▫Immediate freeing of LSQ upon commit▫Position based age logic in LSQ
•Load queue entries:▫Simply reset for future
Store Queue entries: An extra effort
•Need to write back•Drained into write buffer immediately
between L1 Cache and queue•If cannot write stall
▫Very rare•Wrapping around of commit pointer
Loop pre-execution
•Pre-execution of future loads:▫Parallelization▫Enabling zero-latency loads
No L1 cache access latency•Repeated execution of load till completion
of all iterations•Exploiting recurrent nature of loop:
▫Highly predictable address patterns
Learning from example: String copy
•Copying source array to destination array•Predictable load address•Accessing consecutive bytes from memory•Primary addressing access patterns:
▫Stride▫Constant▫Pointer-based
•Placing simple pattern identification hardware alongside pre-executed load buffers
Stride based addressing
•Most common • Iterating over data array
▫Computing address Δ between 2 consecutive loads
▫Third load matches predicted stride: Stride verification
▫Pre-execution of next load•Constant: A special case of zero-sized stride
▫Reading from same address▫Stack allocated variables/ Pointer aliasing
Pointer based addressing
•Value returned by current load -> next address
•E.g. Linked list traversals
Pre-execution: more..
•Pre-executed load buffer placed between load queue and L1 Cache interface
•Store clashes with pre-executed load▫Invalidating entry▫Coherency maintenance
•Pre-executed loads:▫Speculatively waking up dependent
operations on next cycle•Incorrect address prediction:
▫Scheduler cancels and re-issues operation
Conclusion
•Minimizing energy during loop execution•Elimination of front-end overheads
originating from pipeline activity and resource allocation
•Benefits achieved better than in loop buffers and μop caches
•Pre-execution increases performance during loop execution by hiding L1 cache latencies
•According to research, 5.3-18.3% energy-delay benefit
References•Scheduling Reusable Instructions for Power
Reduction (J. Hu, N. Vijaykrishnan, S. Kim, M. Kandemir, M. Irwin),2004
•Matrix Scheduler Reloaded (P. G. Sassone, J. Rupley, E. Breckelbaum, G. H. Loh, B. Black)
• Instruction Fetch Energy Reduction Using Loop Caches for Embedded Applications with Small Tight Loops (L. H. Lee, B. Moyer, J. Arends)
•Power Efficient Loop Execution Techniques (Mitchell Bryan Hayenga)