Software & the Concurrency Revolution by Sutter & Larus ACM Queue Magazine, Sept For CMPS Halverson 1

In a Nutshell “The concurrency revolution is primarily a software revolution. The difficult problem is not building multicore hardware, but programming it in a way that lets mainstream applications benefit from the continued exponential growth in CPU performance.” 2

A look back at computing history ENIAC* – 1949 UNIVAC – US Census Bureau –1952 – 2 installations –1953 – 3 installations –1954 – 13 installations IBM – –Punch Card Systems (tabulations) –1951 – IBM : Fortran & Cobol established 3

Software Crisis Rapid growth in hardware Little development in software Consider Apple Computer in 1970’s –vs. IBM in the 1980’s 4

Current State of Parallel HW Distributed systems Multicore chips Graphics processing units (GPU) Etc. Software? Severely Lacking –Similar to 1940’s to 1950’s –Programs may run slower now 5

Turning Point Performance of programs will not increase due to HW improvements Need for asynchronous processing Barriers –It’s hard; new way of thinking –Inadequate tools & languages –Difficult to find concurrency in some applications 6

Concurrency a disruption? Concurrency = high performance –hw, sw, systems, languages w/ will survive Concurrent programming is difficult –Context-sensitivity & Synchronization analysis These are provably undecidable People don’t tend to think concurrently about programming 7

Programming Models Granularity (fine – coarse*) –Extent to which a problem is broken in to smaller parts –Relative measure of the size of a task Degree of Coupling (loosely* – tightly) –Relative measure of dependence of tasks Communication Synchronization Regularity –Regular vs. Irregular parallelism 8

3 Parallel Models Independent Parallelism Inherently, Embarassingly Operations applied independently to each data item Fine grained, uncoupled –E.G. A PU is assigned to each element of a 100 X 100 element array to double the value Coarse grained, uncoupled –E.G. web-based apps, multi-simulations 9

3 Parallel Models (cont’d) Regular Parallelism Apply same operation to collection of data when computations are dependent –Synchronization or dependent results Fine grained –E.G. Array value becomes sum of 4 nhbrs. Coarse grained –E.G. Web apps with access to common DB 10

3 Parallel Models Unstructured Parallelism Most general, least disciplined –Threads w/ synchronization Unpredictable access to shared data Requires explicit synchronization –Messages Via shared memory Via message passing 11

Locks Mechanism for protecting data/code from conflicting or concurrent access (SW) –E.G. Semaphore, Monitor Standard locks don’t work in parallel –Not composable – deadlock –Standard libraries may quit working –Programmers MUST follow all rules! –Global vs. Local procedures –Local synchronization difficult 12

Lock Alternatives Lock-free programming –Use knowledge of memory to design d.s. not needing locking –Difficult, fragile, still publishable Transactional memory –Language – ability to write atomic blocks –Still in research 13

Goal for Programming Languages “Higher-level language abstractions, including evolutionary extensions to current imperative languages, so that existing applications can incrementally become concurrent.” Make concurrency easy to understand –During development –During maintenance 14

3 Methods for Realizing Parallelism Explicit Programming Implicit Programming Automatic Parallelism 15

Explicit Programming for Parallelization Programmer states exactly where concurrency can occur ADV: Programmer can fully exploit concurrent potential DIS: Need higher-level language features & higher level of programming skill 16

Implicit Programming for Parallelization Concurrency hides in libraries or API’s; programmer maintains sequential view ADV: Inexperienced programmers can use concurrency DIS: Cannot realize all concurrency & difficult to design 17

Automatic Parallelization Compiler extracts parallelism in sequential program. ADV: Does the work for us DIS: Has not worked well in practice –Hard for simple languages –Nearly impossible for complex languages (pointers) –Sequential algorithms have little concurrency 18

Imperative vs. Functional Languages Pascal, C, C++, C#, Java Scheme, ML, Haskell Still many issues to be resolved to see if Functional Languages can provide needed features. 19

Abstraction Low-level: Thread & Lock level –Not a good building block, viewpoint High-level: express tasks with inherent concurrency, system schedules on HW –Easier transition to new HW –Easier for programmer 20

High-Level Abstraction Asynchronous call: non-blocking; call made but caller keeps working Future: mechanism for returning result from an asynchronous call; a placeholder for the value Active object: non-standard; each object runs own thread; outside method calls are asynchronous 21

4 Needed Programming Tools Defect detection Debugger Bottleneck detection Testing aids 22

Defect (Error) Detection New types of errors Race conditions & Livelocks –Difficult to reproduce, non-deterministic Modularity & High-level abstraction help Cannot test modules independently –You can, but… Too many possible paths Active research 23

Debuggers Loggers –Track Messages –Causality Trails –Reverse execution 24

Bottleneck Detection Lock Contention Cache Coherence Overheads Lock Convoys 25

Testing Aids Extend Coverage metrics –Not just of statement is executed, but with what other concurrent statements Stress testing –Need extending –Needs determinism 26

REPEAT: In a Nutshell “The concurrency revolution is primarily a software revolution. The difficult problem is not building multicore hardware, but programming it in a way that lets mainstream applications benefit from the continued exponential growth in CPU performance.” 27

Conclusion – Goals Parallel Apps will (again) run faster on new HW New Interfaces Systems designers: focus on concurrency –Operating systems –Languages –Abstractions 28