1 / 47

Smart Compilers for Reliable and Power-efficient Embedded Computing

PhD Dissertation. Smart Compilers for Reliable and Power-efficient Embedded Computing. Reiley Jeyapaul , PhD Candidate, SCIDSE, ASU . Supervisory Committee : Prof. Aviral Shrivastava (Chair) Prof. Charles Colbourn Prof. Sarma Vrudhula Prof. Lawrence T. Clark. Agenda.

orde
Download Presentation

Smart Compilers for Reliable and Power-efficient Embedded Computing

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. PhD Dissertation Smart Compilers for Reliable and Power-efficient Embedded Computing Reiley Jeyapaul, PhD Candidate, SCIDSE, ASU Supervisory Committee: Prof. Aviral Shrivastava (Chair) Prof. Charles Colbourn Prof. SarmaVrudhula Prof. Lawrence T. Clark

  2. Agenda • Why Embedded Processor Technology? • Key System Requirements • Power Efficiency • Reliability • Why a Compiler Approach ? • Thesis Statement & Supporting Contributions

  3. Embedded processors: A technology to watch SM10000 (SeaMicro) Molecule (SGI) • Growing range of Applications: • Security/Safety • Mobile computing • Automotive • Medical • Even high-end computers now using embedded processors • Molecule • 10,000 Intel Atom dual-core • SM10000 • 512 Atom chips

  4. Power efficiency: A Key System Requirement $4 Billion Electricity charges alone Power-efficient embedded computing is critical to the future • Power consumption in processors follows Moore’s Law too • In servers, power consumption, • Limits performance throughput • Increases cooling cost • Power consumption in processors follows Moore’s Law too • In mobile devices, battery • Life: defines its usability, re-charging freq, etc. • Size: affects its handling.

  5. Soft Errors -an Increasing Concern with Technology Scaling Performance is useless if not correct ! Toyota Prius: SEUs blamed as the probable cause for unintended acceleration. • Charge carrying particles induce Soft Errors • Alpha particles • Neutrons • High energy (100KeV -1GeV) • Low energy (10meV – 1eV) • Soft Error Rate • Is now 1 per year • Exponentially increases with technology scaling • Projected1 per day in a decade

  6. Compilers: At a Unique Interface COMPILER Pros • Flexibility, and portability across machines • Detailed hardware knowledge and interaction • Detailed Application analysis • Limited (to No) hardware cost Cons • Implementation and analysis is difficult • Huge compiler source code • Flexibility of C programs introduce interdependencies • Development cost and time is high

  7. Thesis Statement Smart compilers, with detailed knowledge of hardware and deeper program analysis can achieve power-efficient and reliable computing. Demonstrated through: Pure compiler techniques, Hybrid compiler and micro-architecture techniques, Compiler techniques to enable compiler-directed architectures. Program Info Application Compiler Smart Compiler Smart Analysis Processor H/w Details

  8. Our Contributions Hybrid Compiler & Micro-architecture Techniques • Power reduction • D-TLB [VLSID’09], ITLB [SCOPES’10], [IJPP’10] • Reliable Computing • Smart Cache Cleaning [CASES’11] Compiler-directed Architectures • Coarse Grained Reconfigurable Architectures • Application Mapping onto CGRAs [ASP-DAC’08] Pure Compiler Techniques • Static reliability estimation • Cache Vulnerability Equations [LCTES’10]

  9. List of Publications • Pure Compiler Techniques • [LCTES 2010] Cache Vulnerability Equations • [TACO*] Static Estimation of Cache Vulnerability (Submitted) • Hybrid Compiler & Micro-architecture Techniques • [VLSI-D 2009] D-TLB Power Reduction • [SCOPES 2010] I-TLB Power Reduction • [IJPP 2010]TLB Power Reduction Techniques • [CASES 2011] Smart Cache Cleaning • [TECS] Cache Cleaning for Reliable Computing (Planned) • [ICPP 2011] UnSync Error Resilient CMP Architecture • [TECS] Redundant Multicore Architecture (Planned) • Compiler-directed Architectures • [ICPP 2011] EnablingMultithreading in CGRA • [TCAD]Multithreading in CGRA (Planned) • [ASP-DAC 2008] SPKM CGRA Mapping • Papers accepted: 7, Journals accepted: 1, Journals planned and in-submission: 4

  10. Our Contributions Hybrid Compiler & Micro-architecture Techniques • Power reduction • D-TLB [VLSID’09], ITLB [SCOPES’10], [IJPP’10] • Reliable Computing • Smart Cache Cleaning [CASES’11] Compiler-directed Architectures • Coarse Grained Reconfigurable Architectures • Application Mapping onto CGRAs [ASP-DAC’08] Pure Compiler Techniques • Static reliability estimation • Cache Vulnerability Equations [LCTES’10]

  11. Smart Program Analysis Reveals Vulnerability Reduction Potential Loop Interchange on Matrix Multiplication Vulnerability trend not same as performance Interesting configurations exist, with either low vulnerability or low runtime. • 52X variation in vulnerability for • 1% variation in runtime Opportunities may exist to trade off little runtime for large savings in vulnerability

  12. CVE Toolset for Vulnerability – Performance Trade-off Analysis Cache Parameters Program Using Cache Vulnerability Equations (CVE) Using Cache Miss Equations (CME) CVE Toolset Cache Vulnerability Equations Cache Misses Cache Vulnerability

  13. Our Contributions Hybrid Compiler & Microarchitecture Techniques • Power reduction • D-TLB [VLSID’09], ITLB [SCOPES’10], [IJPP’10] • Reliable Computing • Smart Cache Cleaning [CASES’11] Compiler-directed architectures • Coarse Grained Reconfigurable Architectures • Application Mapping onto CGRAs [ASP-DAC’08] Pure Compiler techniques • Static reliability estimation • Cache Vulnerability Equations [LCTES’10]

  14. Compiler & Microarchitecture Solution: TLB Power Reduction • The TLB • Composed of dynamic circuitry • Accessed on every cache lookup • Consumes 20-25% of cache power • Has power density ~ 2.7 nW/mm2 Knowing that the TLB architecture is modified, a smart compiler can modify the program accordingly. • Compiler optimizations to modify data cache accesses • Instruction scheduling • Operand re-ordering • Loop unrolling & Array interleaving • 39% additional power reduction • Code placement to modify instruction cache accesses • 76% additional power reduction The Use-last TLB architecture • Triggers CAM lookup iff successive accesses are to different cache pages. • Achieves power saving of: • 25% in D-TLB • 75% in I-TLB

  15. Our Contributions Hybrid Compiler & Microarchitecture Techniques • Power reduction • D-TLB [VLSID’09], ITLB [SCOPES’10], [IJPP’10] • Reliable Computing • Smart Cache Cleaning [CASES’11] Compiler-directed architectures • Coarse Grained Reconfigurable Architectures • Application Mapping onto CGRAs [ASP-DAC’08] Pure Compiler techniques • Static reliability estimation • Cache Vulnerability Equations [LCTES’10]

  16. Agenda - SCC Why cache vulnerability? Cache Cleaning to Improve Reliability Smart Cache Cleaning Methodology Experimental Evaluation and Results

  17. Caches are most vulnerable • Caches occupy majority of chip-area • Much higher % of transistors • More than 80% of the transistors in Itanium 2 are in caches. • Low operating voltages • Frequent accesses • Small and tight SRAM cell layout • Majority contributor to the total soft errors in a system With cheap Error detection, cache still the most susceptible architecture block. Cache (split I/D) = 32KB I-TLB = 48 entries D-TLB = 64 entries LSQ = 64 entries Register File = 32 entries

  18. How to protect L1 Cache ? To Detect + Correct: Consequences render it impractical. Practical Method: Needs supporting method to correct errors.

  19. Cache Vulnerability CE CE R R R R W W Time How to protect dirty L1 cache data ? • Assume: Parity based error detection to detect 1-bit errors. • Non-dirty data is not vulnerable • Can always re-read non-dirty data from lower level of memory • Parity based error detection can correct soft errors on non-dirty data • Dirty data cannot be reloaded (recovered) from errors. • Data in the cache is vulnerable if • It will be read by the processor, or it will be committed to memory • AND it is dirty

  20. Agenda - SCC • Why cache vulnerability? • Cache Cleaning to Improve Reliability • Write-through cache • Early Write-back cache • Proposed Smart Cache Cleaning • Smart Cache Cleaning Methodology • Experimental Evaluation and Results

  21. Possible Solution 1: Write-Through Cache Data Accessed for(i:1~3){ for(j:1~3){ A[i]+=B[j] } } A[1] A[1] A[2] A[2] A[2] A[3] A[3] A[3] A[1] RW RW RW RW RW RW RW RW RW Program Timeline (cycles) End of Loop Memory Write-back or Cache Cleaning E Error Recovery: Data reloaded from memory A copy of cache-data is written into the memory If error detected on subsequent access, can reload from memory to recover. NO dirty data in cache NO vulnerability HIGH L1-M traffic Vulnerability = 0 # write-backs = 9

  22. Possible Solution 2: Early Write-back Cache Data Accessed for(i:1~3){ for(j:1~3){ A[i]+=B[j] } } A[1] A[1] A[2] A[2] A[2] A[3] A[3] A[3] A[1] RW RW RW RW RW RW RW RW RW Program Timeline (cycles) End of Loop Periodic Write-back E 4 Cycles Vulnerability A[1] A[1] A[2] A[2] A[3] A[3] Vulnerability ≠ 0 What went wrong? Data unused butvulnerable Unnecessary cleaning while data is being reused Hardware-only cleaning has no knowledge of the program’s data access pattern. Vulnerability = 48 # write-backs = 0 Vulnerability = 13 # write-backs = 8

  23. Proposed Solution: Smart Cache Cleaning Data Accessed for(i:1~3){ for(j:1~3){ A[i]+=B[j] } } A[1] A[1] A[2] A[2] A[2] A[3] A[3] A[3] A[1] RW RW RW RW RW RW RW RW RW Program Timeline (cycles) End of Loop Smart Cache Cleaning E Vulnerability A[1] A[2] A[3] Vulnerability = 0 for unused data. Data is vulnerable while being reused by the program Smart program analysis can help perform Cache Cleaning only when required. For this program, Cleandata, ONLY when not in use by the program. Vulnerability = 18 # write-backs = 3

  24. Agenda - SCC • Why cache vulnerability? • Cache Cleaning to Improve Reliability • Smart Cache Cleaning Methodology • When to clean data ? • SCC Hardware Architecture • How to clean data ? • Which data to clean ? • Experimental Evaluation and Results

  25. How to do Smart Cache Cleaning IF ID M WB Program EX Memory Profile data R/W Cache Accesses LSQ Store InsnAddr SCC Analysis Which data to clean ? L1 Cache Controller: Issue clean signal when required Cache Cleaning SCC InsnAddr SCC Pattern Memory Write-backs clean When to clean ? Memory Targeted cache cleaning architecture How to clean ?

  26. When to clean data ? Data Accessed for(i:1~3){ for(j:1~3){ A[i]+=B[j] } } A[1] A[1] A[2] A[2] A[2] A[3] A[3] A[3] A[1] RW RW RW RW RW RW RW RW RW Program Timeline (cycles) End of Loop 0 1 0 0 0 1 1 0 0 SCC_Pattern E 3 3 Instantaneous Vulnerability (per access) 19 A[1] If end of loop execution is not end of program, then instantaneous vulnerability of last access extends till subsequent cache eviction. Execute: store + clean If Instantaneous Vulnerability of access >SCC_Threshold Execute: store + clean  assign 1 to SCC_Pattern Else Execute: store only  assign 0 to SCC_Pattern SCC_Threshold = 4

  27. How to do Smart Cache Cleaning IF ID M WB Program EX Memory Profile data R/W Cache Accesses LSQ Store InsnAddr SCC Analysis Which data to clean ? L1 Cache Controller: Issue clean signal when required Cache Cleaning SCC InsnAddr SCC Pattern Memory Write-backs clean When to clean ? Memory Targeted cache cleaning architecture How to clean ?

  28. How to clean data ? Instruction Pipeline Cycle count : 6 9 12 3 LSQ SCC_Pattern 0 1 0 0 0 1 0 0 1 0 0 1 Controller L1 Cache clean No Cleaning Cache Cleaning Targeted cache cleaning architecture Memory Program Execution for(i:1~3){ for(j:1~3){ A[i]+=B[j] } } A[1] A[1] A[2] A[2] A[2] A[3] A[3] A[3] A[1] RW RW RW RW RW RW RW RW RW Program Timeline (cycles) 0 1 0 0 0 1 1 0 0 End of Loop E SCC Pattern

  29. SCC Achieves Energy-efficient Vulnerability Reduction Hardware-only cache cleaning trades-off energy for vulnerability Smart Cache Cleaning can achieve ≈0 Vulnerability, at ≈0 Energy cost

  30. SCC_Pattern Generation: Weighted k-bit Compression SCC Cleaning sequence: 1 1 0 1 1 0 0 1 1 0 0 0 0 1 0 1 0 1 0 1 0 0 0 1 1 1 SCC Pattern: - - - - - - - - - - - - - - - 1 Sliding window of 8 bits K = 8 if ( cost_of_1 ≤ cost_of_0 ) Bit value [0] = 1 To determine matching bit value for position 0 Choose bit value = 1, iff # of 1s > 2X # of 0s Cost of not cleaning clean when required. Bit count in position 0 Num of 1s = 3 Num of 0s = 1 Cost for placing0in pos [0] of SCC Pattern: cost_of_0 = Num of 1s X 1 = 3 X 1 = 3 Cost for placing 1 in pos 0 of SCC Pattern: cost_of_1 = Num of 0s X 2 = 1 X 2 = 2 Cost of cleaning when notrequired.

  31. SCC_Pattern Generation: Weighted k-bit Compression SCC Cleaning sequence: 1 1 0 1 1 0 0 1 1 0 0 0 0 1 0 1 0 1 0 1 0 0 0 1 1 1 0 0 0 0 0 0 if ( cost_of_1[i] ≤ cost_of_0[i] ) Bit value [i] = 1 else Bit value [i] = 0 Remaining 6 bits are 0-padded SCC Pattern: - - - - 0111 - - - - - 111 - - 0 0 0111 - - - 0 0111 - 00 0 0111 000 0 0111 - - - - - - 11 0 0 0 0 0 1 1 1 - - - - - - - 1 K = 8 Greater # of 1s Greater # of 1s Greater # of 0s Position [1] : cost_of_1[1] = 2 cost_of_0[1] = 3 Position [4] : cost_of_1[4] = 6 cost_of_0[4] = 1 Position [2] : cost_of_1[2] = 2 cost_of_0[2] = 3 Equal # of 0s and 1s Position [6] : cost_of_1[6] = 4 cost_of_0[6] = 2 All 0s  Bit value = 0

  32. Accuracy of the Weighted Pattern-Matching Algorithm Weights used in the algorithm define the accuracy. Size of k affects accuracy

  33. How to do Smart Cache Cleaning IF ID M WB Program EX Memory Profile data R/W Cache Accesses LSQ Store InsnAddr SCC Analysis Which data to clean ? L1 Cache Controller: Issue clean signal when required Cache Cleaning SCC InsnAddr SCC Pattern Memory Write-backs clean When to clean ? Memory Targeted cache cleaning architecture How to clean ?

  34. Which data to clean ? 30 2 20 1 A1 10 Profit (V/A) 15 20 Instantaneous Vulnerability(IV) by each access of reference A A2 20 Average Vulnerability per access B1 20 Overlapping accesses: Choosing B, precludes the choice of A One SCC InsnAddrRegister How to choose one over anther ?

  35. Energy Efficient Vulnerability Reduction with SCC

  36. SCC: Better results with more hardware registers With more SCC registers, vulnerability is reduced further, at the cost of hardware overhead

  37. Smart Cache Cleaning : H/w IF ID M WB Program EX Registers + Counter like h/w logic implementation Memory Profile data R/W Cache Accesses LSQ A smart compiler can eliminate such hardware overheads Store InsnAddr SCC Analysis Which data to clean ? L1 Cache Controller: Issue clean signal when required Cache Cleaning SCC InsnAddr SCC Pattern Memory Write-backs clean When to clean ? Memory Targeted cache cleaning architecture How to clean ?

  38. Compiler Directed SCC for(i=0; i<10; i++){ for(j=0;j<9;j+=2){ A[j] += B[i]; C[j] += D[i]; A[j+1] += B[i]; C[j+1] += D[i]; } } for(i=0; i<10; i++){ for(j=0;j<10;j++){ A[j] += B[i]; C[j] += D[i]; } } Procedure • Generate k-bit SCC Pattern • Unroll the loop k times • Instrument marked instructions as csw csw sw sw csw RA RC 1 0 0 1 Final List of H/w Requirements • ISA modification to include csw instruction • Which performs : store+cleanon a cache block

  39. Unrolling + SCC Achieves Low EVP and also Improved Performance EVP for these loops ≈0 Unrolling delivers improved performance

  40. Compiler Directed SCC has Interesting Advantages

  41. Smart Cache Cleaning • We develop a Hybrid Compiler & Micro-architecture technique for Reliability – SCC • Soft Errors are a major concern, and Caches are most vulnerable to transient errors by radiation particles • Cache Cleaningcan reduce vulnerability, at the possible cost of power overhead • ECC gains 0 vulnerability, but 70X power overhead • EWB gains 47% vulnerability reduction, with 6X power overhead • Our Smart Cache Cleaning technique: • performs Cleaning on the rightcache blocks at the right time • achieves energy-efficient reliability in embedded systems

  42. Our Contributions Hybrid Compiler & Micro-architecture Techniques • Power reduction • D-TLB [VLSID’09], ITLB [SCOPES’10], [IJPP’10] Compiler-directed Architectures • Coarse Grained Reconfigurable Architectures • Application Mapping onto CGRAs [ASP-DAC’08] Pure Compiler Techniques • Static reliability estimation • Cache Vulnerability Equations [LCTES’10]

  43. Compiler-Directed Architectures: CGRA We develop SPKM – A mapping technique to provide efficient compiler support to improve CGRA usability. • Compiler-directed power efficient architecture: CGRA • Each core contains an ALU with limited data storage capabilities. • Mesh based inter-connected cores • Data and PE operation governed by static mapping • Usability of CGRAs is limited by compiler support • Application instructions and data have to be mapped • to execute on the right PE with right data • at right time

  44. Summary Smart compilers, with detailed knowledge of hardware and deeper program analysis can achieve power-efficient and reliable computing. Hybrid Compiler & Micro-architecture Techniques • Power reduction • D-TLB [VLSID’09], ITLB [SCOPES’10], [IJPP’10] • Reliable Computing • Smart Cache Cleaning [CASES’11] Compiler-directed Architectures • Coarse Grained Reconfigurable Architectures • Application Mapping onto CGRAs [ASP-DAC’08] Pure Compiler Techniques • Static reliability estimation • Cache Vulnerability Equations [LCTES’10]

  45. List of Publications • Pure Compiler Techniques • [LCTES 2010] Cache Vulnerability Equations • [TACO*] Static Estimation of Cache Vulnerability (Submitted) • Hybrid Compiler & Micro-architecture Techniques • [VLSI-D 2009] D-TLB Power Reduction • [SCOPES 2010] I-TLB Power Reduction • [IJPP 2010]TLB Power Reduction Techniques • [CASES 2011] Smart Cache Cleaning • [TECS] Cache Cleaning for Reliable Computing (Planned) • [ICPP 2011] UnSync Error Resilient CMP Architecture • [TECS] Redundant Multicore Architecture (Planned) • Compiler-directed Architectures • [ICPP 2011] EnablingMultithreading in CGRA • [TCAD]Multithreading in CGRA (Planned) • [ASP-DAC 2008] SPKM CGRA Mapping • Papers accepted: 7, Journals accepted: 1, Journals planned and in-submission: 4

  46. Thank you !

  47. References [1] Vasudevan et al, FAWNdamentally Power-efficient Clusters, HOTOS 2009 [2] http://www.electronics-cooling.com/2009/02/when-moore-is-less-exploring-the-3rd-dimension-in-ic-packaging/ [3] http://www.treehugger.com/files/2008/08/radically-efficient-profitable-data-centers.php

More Related