Download Compiler Optimization: Utilizing New Architectural Features for Programmer Productivity - and more Study notes Computer Science in PDF only on Docsity!
Compiler Optimization
Research
Chau-Wen Tseng
(Based on talk by Prof. Bill Pugh, UMD)
Department of Computer Science
University of Maryland, College Park
CMSC 430, Lecture 18 2
Compiler Optimizations
u Question
0 Why study compiler optimization?
u Reasons compiler optimizations not needed
0 Hardware improving at much faster rate 0 Compiler optimizations are not implemented in commercial compilers, anyway
1) Most Progress is in Hardware
u Progress by computer industry (hardware) is exciting
u Software research is not
C++
Java Perl
C
C++
Cobol Fortran LISP
Unix Windows NT
Unix Windows 3.
Unix DOS
1 Ghz Pentium 256 Mb DRAM 100 Mb Ethernet WWW
33 Mhz x 32 Mb DRAM 10 Mb Ethernet Internet
8 Mhz 8088 4 Mb DRAM Modem USENET
Hardware
Operating Systems
Programming Languages
2) Impact of Economics on Compiler Opts.
u Assertion
0 Few new optimizations implemented in commercial compilers
u Commercial compilers
0 Expensive to build & maintain
u Compiler optimizations
0 Many interesting 0 Most narrowly applicable 0 General purpose compilers l Cannot justify expense 0 Custom compilers l Too expensive to write
CMSC 430, Lecture 18 5
3) Proebsting’s Law
u Moore’s law
0 Chip density doubles every 18 months 0 Often reflected in CPU power doubling every 18 months
u Proebsting’s Law
0 Compiler technology doubles CPU power every 18 years
u Corollary
0 1 year of code optimization research = 1 month of hardware improvement 0 No further need for compiler optimization research 0 Just wait a few months… CMSC 430, Lecture 18 6
Todd’s Justification for Proebsting’s Law
u Assumptions
0 4x performance improvement from optimizations 0 Compiler technology represents 36 years of progress
u Results in
0 Compiler technology doubles CPU power every 18 years 0 Improvement = 4% a year
Checking Justification for Proebsting’s Law
u Measure actual benefits from compiler optimization
u SPEC 95 benchmarks [Scott 2001]
0 Numeric Fortran code DEC SPEC results (optimized) vs GNU f77 –O0 (unoptimized) 0 Integer C code DEC SPEC results (optimized) vs DEC cc –O0 (unoptimized)
u Java benchmarks [Arnold+ 2000]
0 Jalapeno (optimized) vs Jalapeno (unoptimized)
Optimizations for SPECfp Benchmarks
su2corhydro2dtomcatvfpppp
swimapsiturb3dmgridapplu
Avg
Speedup
Scott 2001
CMSC 430, Lecture 18 13
Compiler Optimization Research
u What won’t work
0 Take existing C / Fortran benchmarks (e.g., SPEC 95) 0 Apply complex, expensive program analyses / transformations l Automatic parallelization for multithreaded processors using interprocedural context-sensitive whole-path alias analysis of complex pointer-based data structures 0 Targeting existing RISC / x86 microprocessors
u Optimizations reaching point of diminishing returns
0 For current languages / applications / architectures 0 Too much work, not enough improvement
u So what is left?
CMSC 430, Lecture 18 14
Importance of Performance
u For general software, many issues dominate
0 Time to market 0 Maintainability 0 Reliability 0 Safety / security
u Much more important than another 4% / year speedup
Compiler Optimization Research
u So what compiler optimization research is relevant?
u Some suggestions
- Targeting high-performance computing (HPC) applications
- Exploiting new architectural features
- Improving programmer productivity
u But only if performance improvement is significant
0 I.e., closer to 4% / month (processor) than 4% / year (compiler)
Overview
u Motivation
u High-performance computing (HPC)
u Exploiting new architectural features
u Improving programmer productivity
CMSC 430, Lecture 18 17
1) Targeting HPC Applications
u High performance computing applications
0 Computational science 0 Simulation using numerical models (molecules to galaxies) 0 Precision depends on computation power
u Unlike general applications, performance is important
u Compiler optimization research is worthwhile
u Caveat
0 Techniques may not be economical for general compiler 0 May produce programming tool instead of compiler
CMSC 430, Lecture 18 18
2) Exploiting New Architectural Features
u Moore’s law
0 Chip density doubles every 18 months
u Chip density improves performance
0 Smaller gate size = faster switching speed 0 Smaller chip = less wire delay
u But performance does not automatically double
0 2x chip density ≠ 2x clock speed increase
0 2x clock speed increase ≠ 2x performance improvement
Exploiting New Architectural Features
u Source of additional improvement
0 Extra transistors = more processor features
u Uses for extra transistors
0 Larger on-chip caches 0 Vector operations 0 Long instruction words (VLIW) 0 Out-of-order execution 0 Branch prediction 0 Value prediction 0 Predicated instructions 0 Multithreading 0 Speculative threads 0 Prefetching
Exploiting New Architectural Features
u Many features require compiler optimizations
0 On-chip caches → locality optimizations 0 Vector operations → automatic vectorization 0 Long instruction words (VLIW) → instruction scheduling 0 Out-of-order execution → instruction scheduling 0 Predicated instructions → control dependence analysis 0 Multithreading → automatic parallelization 0 Speculative threads → dependence analysis 0 Prefetching → software prefetching
u Otherwise limited benefit from new features
CMSC 430, Lecture 18 25
0
500
1000
1500
2000
2500
3000
3500
198819891990199119921993199419951996199719981999200020012002 Year
Speed (Mhz)
Processor Clock Memory Bus Clock
Processor vs. Memory Speed (Latency)
x386x486 x486 DX2Pentiumx486 DX4Pentium ProPentium IIP II MMXP IIIP 4 P 4 FPM DRAM (420 ns) EDO DRAM (300 ns)SDRAM (200 ns)DDR-DRAM (200 ns)
CMSC 430, Lecture 18 26
1
10
100
1000
10000
198819891990199119921993199419951996199719981999200020012002 Year
Speed (Mhz)
Processor Clock Memory Bus Clock
Processor vs. Memory Speed (log scale)
x386x486 x486 DX2Pentiumx486 DX4Pentium ProPentium IIP II MMXP IIIP 4 P 4 FPM DRAM EDO DRAMSDRAM DDR-DRAM
3) Improving Programmer Productivity
u Improving programmer productivity is probably most
important problem facing computer science today
0 How can compiler optimization research help?
u Areas
0 Discourage manual optimizations 0 Encourage high-level languages 0 Reduce cost of l High-level language constructs l Error-checking / security 0 Provide / exploit user feedback
u Goal is higher productivity
Improving Productivity – Reduce Manual Opts.
u People tweak their code for performance
0 “Register” variable declarations 0 Write compact, dense code 0 Unroll loops by hand
u Problem
0 Code hard to understand and maintain 0 More difficult to optimize 0 May even introduce errors
u Compiler optimizations help
0 Handle simple cases, remove temptation
u Result → less hand-optimized code, easier to maintain
CMSC 430, Lecture 18 29
Improving Productivity – High-Level Languages
u People use low-level languages for performance
0 Use assembly code instead of C 0 Use C instead of C++ 0 Use C++ instead of Java 0 Use MPI instead of HPF
u Problem
0 Low-level programming generally less productive 0 May even introduce errors l Malloc / free vs. garbage collection l Arbitrary pointer arithmetic vs. multidimensional arrays l Arbitrary type casting vs. safe types l Message deadlock in message-passing programs
CMSC 430, Lecture 18 30
Improving Productivity – High-Level Languages
u Compiler optimizations help
0 Reduce penalty for high-level language constructs l Type safety l Objects l Inheritance l Abstract data types l Parametric polymorphism 0 Many of these features are already in Java compilers
u Result → cleaner, high-level code
l Exceptions l Tagged unions l Garbage collection l Higher-order functions l Parameterized typedefs
CMSC 430, Lecture 18 31
High-Level Languages – Intel cc vs GNU gcc
Avg
C++
SPECint 2000, 2.2 Ghz Intel Xeon [Mehis+ 2002] (^) CMSC 430, Lecture 18 32
Summary
u Compiler optimization research can be relevant
0 But not by doing the same thing for the next 18 years
u Some relevant research areas
0 High performance computing applications 0 Exploiting new processor architectural features 0 Improving programmer productivity
u Caveats
0 Only care about performance if improvement >> 4% / year 0 If narrowly applicable, may produce programming tool instead of compiler
